Search the Community

Зашел я сегодня посмотреть свежую ленту форума и увидел очередное хамство нашего героя: Это ужасно, ужасно ужасно в рамках поддержки платного дополнения, которое только разводит и не делает результат! Но мы же с вами грамотные красавчики. И мы понимаем что волшебной таблетки не может быть! Но нам гуглпейдж спид кажить все эти FCP CLS и весь этот бред типа. Друзья. ни один модуль не решит ваши проблемы. Потому как вот эта вся модель оценки вашего ресурса, она очень сложная, ее сложно обмануть, она учитывает пользовательскую статистику хрома, кроме того что вам любые модули могут обмануть бота, и все это уже не актуально. И у вас там может быть сложнейшая верстка, куча лишнего контента, да все что угодно. Но ок, что же нам делать, у нас есть рабочий интернет-магазин. мы хотим подтянуть позиции по выдаче и стоим на распутье, хотим быстрый First contetn paintfull и отсутствие Cumulative Layout Shift. Наверное в формате магазина невозможно достичь идеальных показателей, но мы можем к ним попробовать постремиться. Итак, что я вам советую сделать, чтобы у вас улучшились показатели, без хамства авторов дешевых бесполезных поделок и при этом своими руками и легко: 1. Все изображения во всех модулях, списках, баннерах и так далее идут в Lazy, просто берете и делаете нативное Lazy https://developer.mozilla.org/ru/docs/Web/Performance/Lazy_loading Просто добавляете к изображениям свойство loading="lazy" 2. все изображения переводите в webp, для этого не надо бежать к сайткиратору и покупать платный модуль, просто пользуете это: 3. В большинстве шаблонов у нас по умолчанию в верстке list, который потом через js переводится в grid, сделайте grid в верстке по умолчанию и это отличн вам решит CLS показатель, так как у вас не будет сдвига макета при рендере, если не знаете что это и не знаете как сделать - долбите авторов шаблонов. 4. Новые хотелки page speed хотят, чтобы skeleton разметки страницы был сразу с установленными параметрами размеров изображений. Если у вас единый размер, задайте во всех выводах изображений width и height принудительно. 5. Используйте современные шаблоны. Да я верю, что вы все положили много денег и ресурсов в то что у вас есть, но или Криво косо, но содержат в себе какие-то built in механизмы отпимизации-сжатия скриптов стилей и дадут вам меньше запросов на вебсервер. Несмотря на кривость реализации, это лучше чем ничего! А еще шаблон от @29aleksey все таки прилично выглядит по сравнению со всеми остальными поделками за полтосик. Мне бы в 2012 году такой, для моих магазинов. Реально Леха-кравачик и душу вложил! 6. Если вам вот прямо необходим JivoChat, Вот вам отличный мануал, как решить с ним проблему; https://habr.com/ru/post/447262/ 7. Да я молчу про TTFB, который тоже влияет на оценку pagespeed, да я знаю как это сделать, да, я с удовольствием сделал бы бесплатную таблетку, которая решала проблему быстрой загрузки HTML контента, но это не возможно к сожалению, Минимум что я вам могу рекомендовать, едьте на быстрые хостинги, пользуйте пхп 7+, следите за включенным opcache. 8. Если у вас там метрики и аналитика от гугла - снести все в футер, это плохой совет, возможно вы лишитесь 3-5% каких то показателей, но зато внешние скрипты не затупят. 9. если у вас модуль доставки типа сдэка - посмотрите, чтобы он не пытался грузить яндекс карты на все страницы магазина. 10. Если вы пользуете метрику, отключите в ней вебвизор, вы им вряд ли будете пользоваться и смотреть в него, если нужен - никто не мешает включить! 11. Счетчики, аналитики и т.д. Ни в коем случае не делайте их подгрузку по пользовательскому событию или в отложенную загрузку. Уж если сильно вам мозолит глаза 10-15 баллов, которые они навешивают, снесите их в футер. 12. Вывод и скрытие контента в зависимости от типа устройства. Используйте с умом. Пользуйтесь не js библиотеками а mobiledetect, от того что вы спрячете в display none какой либо элемент, он все равно будет опубликован в DOM страницы, если что-то хотите убрать для мобильных устройств, просто не выводите этот контент фактически при генерации html кода! Но даже если вы реализуете большую часть моих советов, у вас будут отличные оценки pagespeed, и вас не придется выслушивать блевотный бред от авторов которые не смогли, или пытаются нажиться на трех строчках кода на ваших болях, как тот же ситикриатор со своим вебп компрессором, не замечая, что рядом есть отличные бесплатные решения! upd: ну и еще банальшина, но проверяйте настройки кеширования сжатия статики, и если у вас webp то и для него добавляйте правильные заголовки. К примеру, если у вас ISP то должно выглядеть так: Если у вас странные шаред хостинги или нестандартные панели сервером - гуглите, как настроить кеширование сжатие для статики - в зависимости от вашего веб-сервера. Опять же возвращаясь к ISP менеджеру, который заполонил все, попросите вашего вебмастера или саппорт хостинга проверить, чтобы nginx отдавал вот для этого всего правильные заголовки: location ~* ^.+\.(webp|jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|flv|swf|woff2?|ico)$ { access_log off; expires max; break; } Вот прямо можете давать ссыль на статью и говорить - хочу вот так для вебп!

C разрешения владельца магазина, позволю себе, рассказать вам чудесную историю, про то какие бывают модулепейсатели, оптимизаторы, почему они кровососы, и что с ними делать, думаю, что растянем на несколько частей, потому что в рамках одного поста не вместится. Так исторически сложилось, что я дружу с владельцами и инженерами некоторых хостеров. Неделю назад, ко мне обратился ведущий инженер крупного белорусского хостера с вопросом, у нас тут у клиента перегруз по всем лимитам 600%, как ему помочь? Ответ был - никак. Просто при первом же осмотре, в магазине обнаружился filter biber и вот эти все его недосео посадочные страницы. Как говорят создатели сериала "настоящий детектив" по просьбе выживших мы не приводим домен магазина. Но когда проект перенесли на хороший VPS с 5 гигагерцовыми процессорами, магазин показывал вот такую нагрузку: После того, как ваш покорный слуга сделал волшебные магические пассы, у нас стало так: Мы снизили потребление процессорных ресурсов в десять раз. А потребление памяти в текущей конфигурации - величина постоянная, так как ее в основном жрет php-fpm и в режиме ondemand делает это не больше и не меньше. И самое главное. Ну у нас две самых главных вещи. Во первых мы пустили ботов не на псевдосеомусорстраницы, а на нормальный контент, и уменьшили экстремально время ответа сервера на холодную без кешей, джет кешей, а для простого обычного пользователя в три-четыре раза. Как это происходило, что мы сделали, почему фильтр бибер, джет кеши и лайтнинги - это дикое зло. В следующей серии. В дополнение, хочу заметить, между этими двумя графиками два дня и семь лет. Два дня мы это сделали. Семь лет, приходило понимание как это сделать!

После предыдущего поста, меня закидали тапками, мол ты же сам имеешь отношение к turbo модулю. И бла бла бла.. А вот все остальное поливаешь грязью. И так далее. Мол кто-то где-то мздит. Давайте расставим все точки над i. Турбо разрабатывался в формате решения вопросов с дефолтным опенкарт и на момент его создания решал очень много вопросов. Сегодня, с появлением быстрых хостингов, с тем, что разрабы стали меньше тупить, возможно делать на холодную быстрые магазины, которые в целом не намного медленнее работают без каких-бы то не было глобальных кешей html-контента. Вот например ответ сервера у хорошего магаза, у которого все страницы работают быстрее чем 99% покупателей джект кеша. Чем меньше у нас кешей -тем более актуальные данные. Чем более актуальные данные - тем лучше мы торгуем. Но... есть два момента, давайте разберем каждый отдельно Требования google pagespeed. Уже с год, гугл поменял алгоритм оценки качества страниц, и вес оценки времени генерации страниц несколько нивелировался, и начали учитываться такие факторы, как-то количество внешних скриптов, размер контента на странице, количество элементов DOM и вот это все что вы видите в результатах оценки на странице pageSpeedInsights. Есть у нас известные в узких кругах фантастичесие бизнесмены от бога, которые решили, что они ща вот напишут скрипты автоматизации, обьединения, сжатия, откладывания загрузки контента на странице и заработают свой первый ярд. Ну и да.. Показывают клиенту богатую зеленую пузомерку в pagespeed, а то что весь контент развален, аналитикс и метрика работают как попало, пользовательские метрики через одно место. Их не волнует - главное что вы им заплатили за их уникальные поделки, и вам показали красивую картинку. С таким же успехом, можно каждому сделать вот так, как у господина @spectre и начать лечить геморрой огурцом! https://developers.google.com/speed/pagespeed/insights/?hl=ru&url=https%3A%2F%2Ffreelancer.od.ua%2F А еще специалисты делают инлайн скриптов-стилей в тело HTML, я своими глазами видел 5Мегбайт код HTML на странице! 5 Мегайбайт КЭП! А еще, рассказывают с пеной у рта, что изображения webp ничего не дают. Ну да ну да. Экономия в 30-40% на статике - ничего не дает! А еще вставляют пауков, которые обходят в фоне страницы сайта генерируют кеш(ага ага, на какие нить 20 000 страниц, сутки ходим), все уже десять раз протухло. Воруют друг у друга решения (типа как маркукша у ситикриатора webp компрессор). И бесконечно несут какую-то дичь. Лишь бы с очередной жертвы маркетинга купить себе бутлочку коньяка. К сожалению это данность и эксперность нашего сообщества хоть и растет по чуть-чуть, но все еще находится в зачаточном состоянии. Но есть новая надежда, что таки когда пейсателей идиотики будут закидывать мокрыми тряпочками, они будут внимательнее в своих решениях. Так что к сожалению или к счастью для избранных, автоматизация повышения качества страниц для оценки GooglePageSpeed - это миф из Нью Васюков. А вот второй процесс, от которого есть действительно толк называется: Большие магазины и сглаживание пиковой нагрузки. Представьте себе, у вас 20-30 к посетителей в день. В пик к веб-серверу приходит несколько десятков запросов в секунду на генерацию динамического контента. И у вас может быть мега быстрый сайт, но для того чтобы такое держать стабильно - необходим запас мощности и быстрый сервер и это дорого. Представьте, что у вас основной трафик идет на 10-15 страниц от всего сайта. И вот для того чтобы не тратить лишние деньги на серванты, мы совершенно спокойно, можем приземлить весь активнй трафик на готовые закешированные HTML страницы и надолго отсрочить миграцию на более жирные ресурсы. И вот в таком случае. Нормальный html full кеш мастхев. И только в таком случае!!! Во всех остальных стоит озаботиться сперва быстрой генерацией на холодную! Потому что краулинговый бюджет, быстродействие для залогиненных пользователей и вот это вот все! Но как правило если у вас магазин на холодную туп, хоть десять кешей поставьте, когда появляется активная пользовательская сессия (например добавленный товар в корзину) золушка превращается в тыкву, и если магаз тупой - он сразу становится тупой. И ваш покупатель остается один на один с белым экраном. Так что господа, пользуйте нормальные хостинги, не покупайте кривые хламушники 9999 в 1, и да пребудет с вами трафик и бабло! p.s. И да.. Господа писатели кешеров. Если вы захотите тут похоливарить, и рассказать что я в очередной раз несу бред. Я готов обсудить... Если вы мне покажите хоть кто-то, подобную динамику роста трафика от ваших решений:

Обратите внимание, если у вас используется Jet Cache от @markimax - начиная с 15-й версии в нем добавлен свой механизм очистки корзин для их совместной работы с CartKeeper используйте патч из архива модуля (подробно все указано в файле readme внутри архива)