куда уж минимальнее - сервисов для генерации sitemap в интернете валом, прогоните ваш сайт через него. Заодно посмотрите, какие ссылки в него попадают, какие нет.
SorokinWS: другой вариант
считать только на сервере, сохранять, результат расчета отправлять аякосм пользователю, и вешать ему куку с ид или хэшем ид сохраненного результата на сервере.
при отправке корзины отправлять этот хэш.
но это сложнее, и минусы там свои так же будут.
как сделано сейчас у вас, самый оптимальный вариант.
если не хотите дублировать логику, допишите скрипт, который бы строил логику подсчета на стороне сервера, и рендерил js скрипт с такой же логикой для фронтенда.
такое сделать просто.
позже при изменении логики подсчета, править нужно будет только одно место.
SorokinWS: ну и, судя по вашей задаче - "после отправки формы на сервер, нам нужно снова, используя такую же формулу, подсчитать стоимость", стоимость на сервере вам считать таки нужно.
и считать ее вам все равно нужно будет для проверки не подменил ли хитрый пользователь ваши формулы своими
тк, если делать все расчеты на стороне клиента, то он запросто может подделать ответ скрипта и получить товар с скидкой или бесплатно.
поэтому, либо дублировать, либо запрашивать через ajax/сокет, но это не так "отзывчиво" и потом все равно на стороне сервера нужно будет еще раз проверять полученные данные
WP Panda: то есть, время и желание прийти, рассказать про "Святую Веру в Непогрешимость и Истиность", про "Сайт за Жувачку" и тп, найти получилось, а как что-то техническое обосновать нужно, так сразу нет?
Но таки да, думаю, стоит дискуссию как-то закруглить или продолжить позже, после завершения весеннего обострения. А то у одних https - зло, у других "Завод по Сжиганию") Вообще не по теме топика.
WP Panda:
>только мое мнение, оно же по счастливому совпадению единственное правильное
ну, про упоротость, не я первый начал, да?)
>Везде, перечитайте свою писанину
Прикрепите, пожалуйста, цитату? Оптимально, да, писал. По соотношению цена/качество/время.
>Опять же не надо приписывать мне такое, я такого не писал.
ну ок, вы писали "Непогрешимость и Истиность ... 100/100 гугло цифирь".
На мой взгляд, советы теста гугла вполне адекватны и корректное следование этим советам сайт ускорит. Если у сайта результаты были в красной зоне, после оптимизации поднялись до зеленой, результат работы часто виден будет даже на глаз (хоть такой способ тестирования сайтов я бы не рекомендовал)).
Ну и, не стоит забывать, что даже если б эти тесты показывали полную фигню, то это один из факторов ранжирования. На мой взгляд, оправданно потерять 200-300ms в скорости и получить более высокую позицию в выдаче.
>А вот вы да
Ну да, писал такое. И да, предлагаю поднять до 100.
Но я же и вот такое писал "доводить до 100/100 действительно может в некоторых случаях быть не оправданно".
WP Panda: объектом насмешек WP делают упоротые адепты, полностью согласен.
Вас так сильно задело, что я раскритиковал ваше высказывание про зло вижуал компзеров, что вы обращаете внимание только на то, что вам интересно, остальные куски комментариев упускаете?
Где я писал, что установка плагина - идеальное решение? И с чего вы взяли, что 100/100 в гугле - это обязательно?
Вася Петров: аналогично - пока такие как вы есть, я без денег тоже не останусь)
На мой взгляд, глупо упускать клиента, если он готов заплатить. Правильнее, как Игорь Воротнёв пишет, предложить варианты, обрисовать перспективу, выбор пускай сам делает.
Кстати, Вася Петров, почему https - зло? Не получилось сертификат подключить?)
Игорь Воротнёв:
>Short term или long term? Это ключевой момент.
Да что ж вы такой упертый)
Отвлекитесь от нормальных проектов, от крупных сайтов и прочего подобного.
Основная масса сайтов - это "сайты за 5 тысяч" (ну или за $300, если для иностранцев). Где скачали шаблон, через композер накидали блоков, понатыкали плагинов и пустили туда пользователей. Все.
К чему на такой проект настраивать кэширование на стороне сервера через, к примеру, varnish?
>Время/стоимость такая как за настройку плагина
Поставить и включить WP Super Cache - дело 5-10 минут. И дальше оно тупо работает.
Найти узкое место, исправить, протестировать, и все за 10 минут - это насколько реально?
>Во-первых, как я уже устал пытаться донести, проблему это не решит, а только замаскирует частично
Есть лишние деньги перелопатить код, купить сервер, нанять человека его админить - вперед, никто не запрещает.
Вы попробуйте свой бизнес вести? Замечательно отбивает излишнюю тягу к перфекционизму.
И, ак я уже устал пытаться донести (с), попробуйте быть ближе к народу?)
Возьмем любой сайт-визитку на WordPress, скажем цветы продают. С говняной темой, лажевым хостингом и зоопарком плагинов.
И перед праздником собираются устроить рекламу, планируется наплыв посетителей на сайт и тд и тп, а он грузится почему-то долго. Ну или заказал продвижение у сеошников, а те ему порекомендовали хоть как-то повысить скорость загрузки сайта.
И че клиент будет делать по вашим советам?
Мелкому бизнесу, нафик не нужен красивый код (ну, вернее, он им нужен, но они не готовы за него адекватно платить), поэтому вполне устроит чтоб хоть как-то, но работало. Поэтому и WordPress так распространен, при всех его недостатках.
Выгоднее заплатить сейчас копейки за настройку плагина, оставшиеся деньги вбухать в рекламу, а потом целый год на сайт вообще не заходить. Какой ему longterm?
Игорь Воротнёв: Вася Петров: господа плюсующие, вы не забывайте, что мы в реальном мире живем. И решать нужно реальные проблемы.
Да, все так, все именно как вы пишите, делать и нужно. Но на сколько это сделает разработку и поддержку дороже и дольше? И, да, клиент сам не должен в коде копаться, все должны делать специально обученные люди. Но в жизни так не бывает. Этот вопрос - яркий пример. Пользователь не умеет, но проблему решить ему нужно и делать это он будет сам.
>Коллеги, а особенно привыкшие затыкать дыры кеш-плагинами (и плагинам безопасности - ещё одно зло) наверняка ж вы слышали про серверное кеширование?
Почитайте внимательнее мои комментарии выше?
>Клиенту необходимо предоставить аудит и варианты.
Ну и 90% клиентов выберет установку плагина, так как это дешевле на порядок.
Вон, мой текущий клиент - у него свой сервер, на нем WordPress Multisite. Полный доступ к всем настройкам, можно сервер как угодно крутить. Объяснил, оценил, что сколько займет, что и почему лучше/хуже. В итоге - плагин, небольшие правки кода, чистка базы. Потому как это дешевле.
>Приведу аналогию. У человека болит голова
О, я тоже аналогии люблю приводить. Тут уместнее будет такая:
Ребенок получил двойку, привели к психологу, спрашивают, что делать. Он советует этого выкинуть, сделать нового и его воспитать по его программе. Тогда будут только пятерки.
Хотя достаточно б было дать ремня или лишить компьютера на неделю - дешевле, быстрее, и будет работать в основной массе случаев не хуже.
>Нет, в 90% случаев плагин кеширования создаст видимость решения проблемы.
Это как?) Сайт работает, но удовольствие не приносит?)
Да, код внутри останется такой же фиговый (но у заказчика нет денег/времени на профилирование). Да, будут проблемы при перестройке кэша (хотя некоторые плагины умеют перестраивать кэш в фоне) и будет у администратора страница напрямую грузится.
Но за счет кэширования и раздачи статики основной массе пользователей мы снижаем нагрузку на хостинг. И вполне может быть ситуация, что освободившихся ресурсов хватит для обслуживания одного единственного администратора.
>Все эти тесты и числа - только как ориентир для разработчика
Тот же тест гугла вполне нагляден и понятен для не-разработчика. Доводить до 100/100 действительно может в некоторых случаях быть не оправданно.
Но как еще простому пользователю понять, что у него сайт действительно стал грузится быстрее? На глаз?) perceived может быть очень perceived и варьироваться в широких пределах в зависимости от настроения пользователя, скорости его интернета, наличия на компьютера торрентов и прочего.
>К примеру, я обслуживаю один крупный проект
Вот я про что и говорю. Надо быть ближе к народу. То, что оправданно для больших проектов, мелким может быть вообще не по карману.
А то, посмотрел другие советы. Пишут то все в теории правильное, но на практике такую хрень)
"Отказ от вижуал компзеров они - зло" - ну да, зло. Но человек только только выложил деньги, чтоб ему на таком композере сайт собрали, а теперь надо платить, чтоб ему его по другому, без композера, пересобрали?
Сколько будет стоить разработка сайта с точно таким же функционалом, но без такого плагина? Чтоб можно было легко все в админке самому править и блоки перетягивать?
"HTTPS - зло" - с хрена ли?
Ну да, сайт по https будет помедленнее. Но это жеж один из факторов ранжирования в поисковиках. Или это, типо, чтоб он был ниже в выдаче, по нему меньше пользователей ходило, поэтому меньше нагрузка на сервер и он быстрее работает?)
"полный рефакторинг кода" - спасибо, капитан) кто это оплатит?
и прочие, безусловно, полезные советы.
Повторюсь, сайт мы не видели. Единственная проблема, про которую известно точно - долго отдает первый байт.
Не имея никаких других данных (где сайт, какой хостинг, что там за код, умеет ли человек с кодом работать и тп), единственное, что может решить проблему с такими вводными - установить плагин кэширования.
Игорь Воротнёв: повторюсь, работать надо с тем, что есть у клиента, или с тем, что действительно он может сделать.
Вот что, из вышеперечисленного он осилит самостоятельно сделать качественно?
На мой взгляд, если он задает такие вопросы, то только поменять хостинг или поставить плагин.
Из опыта, некоторые заказчики пробуют самостоятельно ставить плагины кэширования. Выбирают тот же W3TC, но настроить его не могут. В таком случае, советую им ставить WP Super Cache, он значительно проще в настройке.
Я не знаю, что у него за сайт. в каждом конкретном случае стратегия оптимизации может быть разной. может у него там вообще на init висит какой-нить wp_remote_get и погоду каждый раз проверяет? Но в 95% случаев плагин кэширования поможет поднять TTFB без изменения логики работы сайта.
>Я тоже когда-то это делал. И да, это реально делать средствами плагинов
не соглашусь. живой сайт средствами плагинов до 100/100 догнать проблематично. обычно приходится код руками под конкретный сайт писать.
>отому что учитывать в первую очередь надо perceived speed, а не числа.
тоже не согласен, но к теме вопроса это уже не относится.
Игорь Воротнёв:
>Вы не совсем правильно себе представляете работу плагинов кеширования
забавно)
Вообще, я своим клиентам услугу поднять результаты в тесте гугла до 100/100 продвигаю. И вполне успешно.
Интересно б было узнать, в каком именно месте я неправильно представляю работу плагинов?)
У него TTFB 2 секунды. Значит ему нужно либо переписывать тему/плагины, либо покупать дорогой сервер (причем, не факт, что это поможет), либо кэшировать все в статику и отдавать статику.
Перегнать все в статику плагином - самое простое. Работает на любом хостинге.
Да, кэшировать средствами сервера, всякие там varnish, nginx и тп, - круче и эффективнее. Но основная масса клиентов такое себе позволить не может.
Работать надо не с сферическим high-load, а с тем, что есть у заказчика).
Ну и, к вопросу топик стартера.
Сделать асинхронную загрузку css можно. Самое простое, использовать плагин. В гугле по 'wordpress css async' они есть.
например https://ru.wordpress.org/plugins/wp-async-css/
Я такими не пользуюсь, своим кодом инлайню кусок critical css в шапку, а все остальные css гружу только после загрузки страницы. Но делать так советовать не буду, тк это сложнее
