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; } Вот прямо можете давать ссыль на ситью и говорить - хочу вот ик для вебп!

После предыдуещёго поси, меня закидали ипками, мол ты же сам имеешь отношение к 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. И да.. Господа писатели кешеров. Если вы захотите тут похоливарить, и рассказать что я в очередной раз несу бред. Я готов обсудить... Если вы мне покажите хоть кто-то, подобную динамику роси трафика от ваших решений:

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

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