21.09.2021 21:01:02 |
Автор: admin
Приветствую, уважаемые читатели. Мой очередной раунд борьбы за скорость работы сайта начался примерно год назад (где-то в мае 2020 года). Там был большой апдейт Гугла и у моего блога здорово порезало трафик (графики не хочу приводить, поверьте уж на слово).
К сожалению, у меня в тот период не было особо много свободного времени, чтобы искать причины и исправлять что-то прямо по горячим следам. Начал работать над сайтом только летом, да и то урывками. Причина была в том, что мы переехали жить из города в деревню, а это повлекло много работы по дому (ее и сейчас еще очень много осталось не переделанной).
Что мне тогда бросилось в глаза, так это очень плохие показатели PageSpeed (кто не знает, это такая оценочная система Гугла, которая выдает не только синтетические тесты скорости и удобства пользования сайтов, но и реальные данные из браузера Гугл Хром). Особенно просели показатели для мобильной версии сайта (почти все страницы были в красной зоне).
На тот момент скоростью работы сайта я не занимался несколько лет и даже не открывал PageSpeed. Когда же открыл, то был сильно обескуражен. Мне показалось, что именно это явилось причиной проседания трафика. В любом случае, за это можно было зацепиться и попытаться что-то улучшить.
Собственно, улучшения я проводил урывками и не особо записывал, что именно делал. Многое уже, наверное, позабылось. Пользовался информацией из рунета, буржунета, ютуба. Появлялись какие-то идеи, находил способ их реализации, применял и либо оставлял, либо откатывал назад.
Собственно, скриншот приведен в начале статьи. Иногда вместо 100 вылазит 97, 98 или 99 для мобильных устройств. Для компьютеров обычно всегда 100, но я далеко не все страницы проверял, а посему может где и меньше.
Да, я понимаю, что это синтетика (на данный момент используется Lighthouse 7.1.0). Зачастую 100 баллов в синтетике не дают реальной картины и со скоростью загрузки может быть все плохо. Однако, современный PageSpeed это не только Lighthouse, но и Core Web Vitals (вот эти четыре зелено-желто-красных полоски сразу под цифровой оценкой).
А вот Core Web Vitals говорит о многом, ибо это реальные данные полученные из реальных браузеров пользователей, посещающих мой сайт (само собой, что только из Хрома и Хромиума). На них можно ориентироваться и именно их значения нужно брать за основу, ибо синтетика часто не видит реальных проблем.
Тут главное — слово «ОТВЕЧАЕТ», написанное зеленными буквами. Собственно, это и есть общая оценка сайта. Противоположный вариант слово «НЕ ОТВЕЧАЕТ», написанное красными буквами. У меня такое наблюдается пока в результатах для компьютера, но проблема уже решена и описана ниже. Осталось подождать недельки три, когда обновятся данные.
Более детально можно посмотреть по цвету точек рядом с каждой строкой параметров. Про них мы поговорим чуть ниже, а пока о том, что лично я сделал для получения такого результата.
Из того, что сделал и что осталось в памяти (если нужно будет подробнее, то пишите в комментах — попробую вспомнить):
Эффект от использования этой связки ощутил сразу. Реально выросла скорость загрузки (еще раза в два, наверное). Кстати, использовал для измерения скорости загрузки эти сервисы. Сразу оговорюсь, прежде чем вы стали кидаться в меня палками — ПингДом не показывает реальной картины (сильно в лучшую сторону дает результаты), но относительно предыдущих измерений и у него скорость выросла в два раза. А вот ВебПейджТест и ДжиТиМетрикс вполне себе адекватную картину формируют, на мой взгляд.
У меня это реализовано с помощью плагина BJ Lazy Load. Вариант не идеальный, ибо для того, чтобы происходила индексация картинок поисковиками используются костыли (урлы картинок прописываются в теге noscript). Но, к сожалению, правильный вариант лези лоуда пока не реализован в виде плагина для Вордпресс (во всяком случае бесплатного и проверенного временем).
Вы мне скажите, что я дурак и уже давно есть атрибут Lazy Load для тега IMG (так называемый, нативный лези лоуд). Да есть, но прямое его применение не дает ровно никакого результата (даже наоборот, на мобильных устройствах все картинки будут грузиться при открытии первого экрана). Есть способ это побороть с помощью CSS свойства content-visibility, но у меня не получилось это реализовать на своем сайте (да и ютуб ролики, как я понимаю, в этом случае не будут работать с отложенной загрузкой).
Суть такая. После загрузки страницы на ней ничего не должно дергаться и смещаться в какую-либо сторону. Сами знаете, открылась страница, вы только хотели нажать на кнопку, а она раз и ускакала после подгрузки какого-то припозднившегося элемента (картинки, для которой не было заранее зарезервировано место, виджета соцсети, рекламного баннера). Если таких сдвигов не будет, то CLS будет равен нулю.
Сначала я прописал для всех картинок высоту и ширину (через функшион.пхп) и поменял метод прикрепления верхнего меню (ранее было через джава-скрипт, а стало через css позиционирование). Потом в настройках автоматических объявлений Адсенса (они у меня все автоматом расставляются) исключил все места на первом экране. Делается это через меню Объявления — настройки вашего сайта — удаление нежелательного места размещения.
Это решило проблему с большим CLS (более 0.3 был). Но в начале этого года опять начал расти CLS, но только «для компьютеров». Вот честно, сломал голову, ибо не мог понять в чем дело. Визуально никаких сдвигов на первом экране не наблюдалось. Хоть тресни.
Спасибо ребятам, которые выпустили размещенный ниже ролик.
Оказывается, с начала этого года Гугл стал считать CLS не только на первом экране, а на всем протяжении общения пользователя со страницей.
К тому же они привели ссылку на отличный плагин для Хрома, который позволяет в реальном времени отследить изменения Cumulative Layout Shift при прокрутке страницы.
Причиной стал так называемый плавающий сайдбар (реклама в блоке внизу сайдабара, которая остается зафиксированной при прокрутке страницы ниже сайдбара). Она фиксировалась с помощью джаваскрипта (подменой позиционирования relative на fixed при прокрутке страницы ниже сайдбара).
Пришлось потратить пару часов и заменить джава логику относительно новым CSS способом позиционирования через position sticky. Время ушло на то, чтобы понять, почему это не работает. Оказалось, что мешает overflow:hidden родительского элемента (это недокументированая фича). Пришлось заменить overflow:hidden новым CSS свойством display: flow-root, как посоветовал один замечательный товарищ в этой ветке.
Пока CLS для компьютеров у меня достаточно высокий, но этот показатель обновляется долго (сбор идет из реальных браузеров посетителей сайта), поэтому будем подождать. Рад, что нашлась причина, ибо начинал уже биться головой об стену в ее поисках.
Конечно же, моих куцых мозгов на это бы не хватило. Поэтому пришлось обратиться к специалисту. Сайт у меня размещен в облаке Инфобокса (в принципе, все очень и очень устраивает, кроме невозможности заказать у них сейчас проведение работ на сервере, ибо сильно загружены они работой).
Обратился через Кворк к спецу с хорошими (отличными) отзывами. Прикольно, что когда указал ему сайт, то оказалось, что мы уже сотрудничали. В 2009 году мой блог размещался на бесплатном хостинге окснул.нет и этот товарищ был там администратором. Много мне помогал и даже запомнил мой сайт. Работу он сделал очень быстро и недорого. Классный специалист, рекомендую.
Из того, что еще не реализовано. Хотелось бы прикрутить нативный лези лоуд к сайту и отказаться от подгрузки джиквери. Не знаю, получится ли. Но пока это поставил на паузу. Вдруг что-то появится по теме и можно будет самому не ломать голову.
Ну, по идее, это то, что уже должно было сейчас учитываться в полной мере при ранжировании сайтов в Гугле, но из-за пандемии было перенесено на первую половину этого года. Хотя, еще не факт что это будет что-то грандиозное и переворачивающее всю выдачу Гугла с ног на голову.
Однако, вокруг этих относительно новых метрик идут оживленные дискуссии и, думаю, что соответствовать новым требования должны стремиться любые сайты. Почему? Ну, потому что этот тренд будет активно продвигаться и лобироваться Гуглом до тех пор, пока все не очухаются от спячки.
Примерно так было с переходом на Https (собственно, Page Experience включает в себя этот фактор) — сначала рекомендовали, а сейчас без Https ранжироваться высоко стало сложнее.
Все дело в том, что число сайтов в сети растет в геометрической прогрессии. Однако пропускные возможности оборудования сети интернет выросли не столь значительно. Уже реально сложно становится Гуглу индексировать такое количество сайтов, тем более, когда они еще и тормозят по-страшному. Гугл не Яндекс, его индекс на пару порядков побольше будет, и играться с ПФ, как наш поисковик, мировой гигант не может.
По этой же причине Гугл начал активно продвигать семантическую верстку (во многих выступлениях представителей поиска это звучит). Поиск уже не может тратить время на выявления значимых областей контента (содержания), ибо на это не хватает времени и мощностей. Будьте любезны сами с помощью семантических тегов указать ему, что и как учитывать. Иначе будут проблемы с ранжированием и даже индексацией.
Точно так же и с Page Experience, Core Web Vitals. Новые факторы ранжирования позволят провести быстрый и несложный анализ, чтобы понять какие сайты ориентированы на удовлетворение пользователей (сделать им «быстро и удобно»), а какие нет (жрите, что дают). Отсеев тех, кто не с нами, будет проще формировать релевантную выдачу из быстрых и удобных ресурсов.
Может быть это будут накручивать. Может быть значимость этих факторов будет низкой. Но... Все это можно привести в порядок самому или с ограниченным привлечением сторонних специалистов за несравнимо меньшие суммы, чем тратятся на внешнюю и внутреннюю оптимизации.
Что входит в Page Experience (анализ удобства страницы):
Как видите, тут и удобство просмотра сайта на мобильных (кто еще об этом не задумался — самое время, ибо около 70% пользователей заходят в сеть с мобилок), и безопасность для пользователей (отдельно от Https), и, собственно, Https.
Первый пункт (Основные интернет-показатели) — это и есть пресловутый Core Web Vitals. Состоит он из трех составляющих:
Этот параметр отражает скорость
загрузки. Чтобы страницей было удобно пользоваться, значение LCP
должно по возможности составлять менее 2,5 с с момента начала ее
загрузки. Грубо говоря, это скорость загрузки первого экрана, а
точнее самого большого его фрагмента (можно посмотреть чего именно
в Пейдж Спид).
Этот параметр отражает интерактивность. Чтобы ей
было удобно пользоваться, значение FID должно по возможности
составлять менее 100 мс. Грубо говоря, это скорость реакции на
нажатие кнопки на сайте. Как быстро начнет все меняться. Но это
сильно утрировано.
Чтобы страницей было удобно пользоваться,
значение CLS должно по возможности составлять менее 0,1.
Высчитывается это по специально фиг кому понятной формуле. Но суть
простая — чем меньше чего-то сдвигается уже после загрузки
страницы, тем ниже будет этот показатель (идеально —
ноль).В PageSpeed отображается еще и параметр First Contentful Paint (FCP). Это время до первой отрисовки контента – показатель, который определяет интервал времени между началом загрузки страницы и появлением первого изображения или блока текста. Штука важная (15% по калькулятору). Хотя все эти веса, да и сами параметры входящие в Core Web Vitals еще не раз поменяются.
В формате видео все эти аббревиатуры будет, наверное, проще осознать и понять их суть. Это гости Михаила Шакина (хороший у него канал) и один из них весьма и весьма подкован в теме, при этом может пояснять в доступной форме (другой не подкован, но говорлив):
Еще раз подчеркну главное.
Core Web Vitals — это не расчетные (не синтетические), а вполне себе реальные данные, собранные в Хроме пользователей, которые заходили на ваш сайт. Это самая что ни на есть реальность. Если тут все плохо, то звоните во все колокола и бегите все исправлять, даже если PageSpeed показывает 100 баллов для мобильных и компьютеров.
Еще очень важно. Не для каждой страницы вашего сайта будут отображаться отдельные показатели Core Web Vitals. Скорее всего у вас будет написано, что:
Данные наблюдений. В отчете об удобстве пользования браузером Chrome недостаточно данных о фактической скорости загрузки этой страницы.
У меня отдельные данные по Core Web Vitals отображаются только для самых посещаемых страниц, например, этой. Чтобы увидеть средний показатель по сайту надо будет там нажать на «Показать данные об источнике».
Важно. Данные по Core Web Vitals обновляются в масштабах сайта весьма медленно. Поэтому не ждите мгновенных изменений. Запасайтесь попкорном и посидите месяцок у экрана. Для страниц, где Core Web Vitals считается отдельно, скорость обновления будет намного выше.
Еще важно. Где еще можно посмотреть реальные данные по Page Experience для вашего сайта. Конечно же, в панели для Вебмастеров. Там данные тоже обновляются не в реальном времени, но зато можно принудительно заставить поисковик их пересчитать, чтобы ускорить процесс.
К сожалению, у меня там пока еще не все красиво (последние настройки CLS сделал буквально вчера), но скриншот просто чтобы вы понимали, где именно смотреть:
Ну, не знаю. Просто мне пока не помогло (положительного результата в ранжировании от увеличения скорости не видно). Начал оптимизацию скорости я давно. Правда, через пень-колоду и много косяков было по ходу преобразования (даже пришлось проверить все страницы сайта на Html валидаторе, и не зря — нашел десятка два критических ошибок).
Возможно, что сделанное сейчас аукнется в будущем. А пока я получаю чисто эстетическое удовольствие от осознания, что все что мог в области ускорения сайта на сегодняшний день я реализовал. Можно поставить галочку и заняться чем-то другим (не менее интересным).
Повторять ли вам мой путь, тратить ли на это время или деньги — вопрос риторический. Однако, буду признателен вашим замечаниям и, возможно, советам (например, по реализации на практике работающего нативного лези лоуда).
За сим разрешите откланяться.
Удачи вам! До скорых встреч на страницах блога7j.ru
Подробнее..
Категории: Ускоряем сайт
