Русский
Русский
English
Статистика
Реклама

Ускоряем сайт

Page Experience, Core Web Vitals (LCP, FID, CLS) — что это, как набрать 100 баллов в PageSpeed и почему это вам не поможет

21.09.2021 21:01:02 | Автор: admin

Приветствую, уважаемые читатели. Мой очередной раунд борьбы за скорость работы сайта начался примерно год назад (где-то в мае 2020 года). Там был большой апдейт Гугла и у моего блога здорово порезало трафик (графики не хочу приводить, поверьте уж на слово).

К сожалению, у меня в тот период не было особо много свободного времени, чтобы искать причины и исправлять что-то прямо по горячим следам. Начал работать над сайтом только летом, да и то урывками. Причина была в том, что мы переехали жить из города в деревню, а это повлекло много работы по дому (ее и сейчас еще очень много осталось не переделанной).

100 балов в PageSpeed для мобильных и компьютера

Что мне тогда бросилось в глаза, так это очень плохие показатели PageSpeed (кто не знает, это такая оценочная система Гугла, которая выдает не только синтетические тесты скорости и удобства пользования сайтов, но и реальные данные из браузера Гугл Хром). Особенно просели показатели для мобильной версии сайта (почти все страницы были в красной зоне).

На тот момент скоростью работы сайта я не занимался несколько лет и даже не открывал PageSpeed. Когда же открыл, то был сильно обескуражен. Мне показалось, что именно это явилось причиной проседания трафика. В любом случае, за это можно было зацепиться и попытаться что-то улучшить.

Собственно, улучшения я проводил урывками и не особо записывал, что именно делал. Многое уже, наверное, позабылось. Пользовался информацией из рунета, буржунета, ютуба. Появлялись какие-то идеи, находил способ их реализации, применял и либо оставлял, либо откатывал назад.

Как набрать 100 баллов в PageSpeed для мобильных и компьютеров

Собственно, скриншот приведен в начале статьи. Иногда вместо 100 вылазит 97, 98 или 99 для мобильных устройств. Для компьютеров обычно всегда 100, но я далеко не все страницы проверял, а посему может где и меньше.

Да, я понимаю, что это синтетика (на данный момент используется Lighthouse 7.1.0). Зачастую 100 баллов в синтетике не дают реальной картины и со скоростью загрузки может быть все плохо. Однако, современный PageSpeed это не только Lighthouse, но и Core Web Vitals (вот эти четыре зелено-желто-красных полоски сразу под цифровой оценкой).

А вот Core Web Vitals говорит о многом, ибо это реальные данные полученные из реальных браузеров пользователей, посещающих мой сайт (само собой, что только из Хрома и Хромиума). На них можно ориентироваться и именно их значения нужно брать за основу, ибо синтетика часто не видит реальных проблем.

Core Web Vitals в Гугл Пейдж Спид

Тут главное — слово «ОТВЕЧАЕТ», написанное зеленными буквами. Собственно, это и есть общая оценка сайта. Противоположный вариант слово «НЕ ОТВЕЧАЕТ», написанное красными буквами. У меня такое наблюдается пока в результатах для компьютера, но проблема уже решена и описана ниже. Осталось подождать недельки три, когда обновятся данные.

Более детально можно посмотреть по цвету точек рядом с каждой строкой параметров. Про них мы поговорим чуть ниже, а пока о том, что лично я сделал для получения такого результата.

Из того, что сделал и что осталось в памяти (если нужно будет подробнее, то пишите в комментах — попробую вспомнить):

  1. Сократил размер структуры DOM с 2500 до 1400 на самых больших по объему содержимого страницах (основное количество блоков там создавали комментарии). Как это сделал? Ну, например, посмотрел структуру комментариев и убрал лишнюю вложенность блоков (если комментов сотни, то и снижение DOM структуры происходит на сотни). То же проделал с сайдбаром.
  2. Сделал постзагрузку счетчиков и прочего обвеса с задержкой относительно основного контента страницы. Это дало самый ощутимый эффект. Реальное время загрузки стало меньше на секунды. Как это сделать? В сети описаны разные способы с разными тригерами (по времени, по первому скролу и т.п.). Для разных вещей я использовал разные способы, но конкретики уже, к сожалению, не помню. Надо было записывать, но я как-то не верил, что это сработает.
  3. Применил описанный в сети способ настройки четырех популярных плагинов для Вордпресса (LiteSpeed Cache + Hyper Cache Extended + Autoptimize + Speed Up — по ссылке найдете описание нужных настроек для каждого из них), использование которых в связке решило сразу несколько проблем:
    1. Полностью убралась подгрузка внешнего файла CSS стилей. Эти стили интегрировались в Html код (в область Head с помощью тела Style). К сожалению, по умолчанию туда набилось много лишнего CSS кода (например, из админки Вордпресса, который во фронтэнде без надобности). Но путем внесения исключений в плагин, который за это отвечал, удалось от этих огрехов избавиться. Потом еще несколько дней ушло на то, чтобы проверить все строки CSS кода на актуальность, что позволило сократить его более чем в два раза.
    2. Джава скрипт файлы тоже были объединены в один файл. Но мне особо ничего не дало.
    3. Что-то еще там улучшилось, но что не помню.

    Эффект от использования этой связки ощутил сразу. Реально выросла скорость загрузки (еще раза в два, наверное). Кстати, использовал для измерения скорости загрузки эти сервисы. Сразу оговорюсь, прежде чем вы стали кидаться в меня палками — ПингДом не показывает реальной картины (сильно в лучшую сторону дает результаты), но относительно предыдущих измерений и у него скорость выросла в два раза. А вот ВебПейджТест и ДжиТиМетрикс вполне себе адекватную картину формируют, на мой взгляд.

  4. Отложенная загрузка картинок (так называемый Лези Лоуд). Штука необходимая. Дело в том, что измеряется, по сути, скорость загрузки первого экрана, но сама по себе страница может быть очень длинной и с множеством изображений. Если применить Лези Лоуд, то подгрузится только первая картинка (или несколько), попадающая на первый экран, а остальные будут подгружаться по мере прокрутки страницы.

    У меня это реализовано с помощью плагина BJ Lazy Load. Вариант не идеальный, ибо для того, чтобы происходила индексация картинок поисковиками используются костыли (урлы картинок прописываются в теге noscript). Но, к сожалению, правильный вариант лези лоуда пока не реализован в виде плагина для Вордпресс (во всяком случае бесплатного и проверенного временем).

    Вы мне скажите, что я дурак и уже давно есть атрибут Lazy Load для тега IMG (так называемый, нативный лези лоуд). Да есть, но прямое его применение не дает ровно никакого результата (даже наоборот, на мобильных устройствах все картинки будут грузиться при открытии первого экрана). Есть способ это побороть с помощью CSS свойства content-visibility, но у меня не получилось это реализовать на своем сайте (да и ютуб ролики, как я понимаю, в этом случае не будут работать с отложенной загрузкой).

  5. Добавил ко всем изображениям атрибут decoding="async". Что он делает? Если кратко, то помогает ускорить сайт за счет асинхронной загрузки изображений. Стоит ли его добавлять, если об этом никто не пишет? Стоит, ибо реально есть прибавка в скорости. Как добавил? Через файл функшион.пхп, но деталей не помню. Если кто сам не найдет способ — попробую покопаться в этом файле, чтобы вспомнить.
  6. Убрал все изображения из шаблона. Дело в том, что каждое из изображений прописанных в CSS (например, фоновые картинки, значки соцсетей, галочки, полочки, линии и тп.) создает отдельный запрос при загрузке страницы, что влияет на общую скорость. Причем Лези Лоуд на них не действует. Изначально (несколько лет назад) у меня формировалось около семи десятков запросов при загрузке страницы. Сейчас их только несколько (html страница, заглавная картинка, фавикон, объединенный джаваскрипт-файл и джиквери)
    Запросы при загрузке страницы
  7. Убрал CLS (Cumulative Layout Shift). Не сразу обратил внимание и разобрался что такое CLS. Оказалось, что под этой аббревиатурой скрывает так называемый суммарный сдвиг шаблона. Он напрямую говорит об удобстве пользования сайтом, хотя его вес в калькуляторе Core Web Vitals весьма скромен на сегодняшний день (5 процентов).

    Суть такая. После загрузки страницы на ней ничего не должно дергаться и смещаться в какую-либо сторону. Сами знаете, открылась страница, вы только хотели нажать на кнопку, а она раз и ускакала после подгрузки какого-то припозднившегося элемента (картинки, для которой не было заранее зарезервировано место, виджета соцсети, рекламного баннера). Если таких сдвигов не будет, то CLS будет равен нулю.

    Сначала я прописал для всех картинок высоту и ширину (через функшион.пхп) и поменял метод прикрепления верхнего меню (ранее было через джава-скрипт, а стало через css позиционирование). Потом в настройках автоматических объявлений Адсенса (они у меня все автоматом расставляются) исключил все места на первом экране. Делается это через меню Объявления — настройки вашего сайта — удаление нежелательного места размещения.

    Это решило проблему с большим CLS (более 0.3 был). Но в начале этого года опять начал расти CLS, но только «для компьютеров». Вот честно, сломал голову, ибо не мог понять в чем дело. Визуально никаких сдвигов на первом экране не наблюдалось. Хоть тресни.

    Спасибо ребятам, которые выпустили размещенный ниже ролик.

    Оказывается, с начала этого года Гугл стал считать CLS не только на первом экране, а на всем протяжении общения пользователя со страницей.

    К тому же они привели ссылку на отличный плагин для Хрома, который позволяет в реальном времени отследить изменения Cumulative Layout Shift при прокрутке страницы.

    Плагин Core Web Vitals для Хрома

    Причиной стал так называемый плавающий сайдбар (реклама в блоке внизу сайдабара, которая остается зафиксированной при прокрутке страницы ниже сайдбара). Она фиксировалась с помощью джаваскрипта (подменой позиционирования relative на fixed при прокрутке страницы ниже сайдбара).

    Пришлось потратить пару часов и заменить джава логику относительно новым CSS способом позиционирования через position sticky. Время ушло на то, чтобы понять, почему это не работает. Оказалось, что мешает overflow:hidden родительского элемента (это недокументированая фича). Пришлось заменить overflow:hidden новым CSS свойством display: flow-root, как посоветовал один замечательный товарищ в этой ветке.

    Пока CLS для компьютеров у меня достаточно высокий, но этот показатель обновляется долго (сбор идет из реальных браузеров посетителей сайта), поэтому будем подождать. Рад, что нашлась причина, ибо начинал уже биться головой об стену в ее поисках.

  8. Обновил компоненты сервера (ОС, Php, веб-сервер) и исправил ошибки. Все это вкупе дало малую прибавочку в скорости (особенно при формировании страниц еще не закешированных плагином, для которых на лету производится рендеринг) и повысило безопасность сайта (HSTS, убрал версии некоторых компонентов сервера из общего доступа), что тоже может быть оценено поисковиками.

    Конечно же, моих куцых мозгов на это бы не хватило. Поэтому пришлось обратиться к специалисту. Сайт у меня размещен в облаке Инфобокса (в принципе, все очень и очень устраивает, кроме невозможности заказать у них сейчас проведение работ на сервере, ибо сильно загружены они работой).

    Обратился через Кворк к спецу с хорошими (отличными) отзывами. Прикольно, что когда указал ему сайт, то оказалось, что мы уже сотрудничали. В 2009 году мой блог размещался на бесплатном хостинге окснул.нет и этот товарищ был там администратором. Много мне помогал и даже запомнил мой сайт. Работу он сделал очень быстро и недорого. Классный специалист, рекомендую.

Из того, что еще не реализовано. Хотелось бы прикрутить нативный лези лоуд к сайту и отказаться от подгрузки джиквери. Не знаю, получится ли. Но пока это поставил на паузу. Вдруг что-то появится по теме и можно будет самому не ломать голову.

Что такое Page Experience, Core Web Vitals (LCP, FID, CLS) и зачем это все нужно

Ну, по идее, это то, что уже должно было сейчас учитываться в полной мере при ранжировании сайтов в Гугле, но из-за пандемии было перенесено на первую половину этого года. Хотя, еще не факт что это будет что-то грандиозное и переворачивающее всю выдачу Гугла с ног на голову.

Однако, вокруг этих относительно новых метрик идут оживленные дискуссии и, думаю, что соответствовать новым требования должны стремиться любые сайты. Почему? Ну, потому что этот тренд будет активно продвигаться и лобироваться Гуглом до тех пор, пока все не очухаются от спячки.

Примерно так было с переходом на Https (собственно, Page Experience включает в себя этот фактор) — сначала рекомендовали, а сейчас без Https ранжироваться высоко стало сложнее.

Все дело в том, что число сайтов в сети растет в геометрической прогрессии. Однако пропускные возможности оборудования сети интернет выросли не столь значительно. Уже реально сложно становится Гуглу индексировать такое количество сайтов, тем более, когда они еще и тормозят по-страшному. Гугл не Яндекс, его индекс на пару порядков побольше будет, и играться с ПФ, как наш поисковик, мировой гигант не может.

По этой же причине Гугл начал активно продвигать семантическую верстку (во многих выступлениях представителей поиска это звучит). Поиск уже не может тратить время на выявления значимых областей контента (содержания), ибо на это не хватает времени и мощностей. Будьте любезны сами с помощью семантических тегов указать ему, что и как учитывать. Иначе будут проблемы с ранжированием и даже индексацией.

Точно так же и с Page Experience, Core Web Vitals. Новые факторы ранжирования позволят провести быстрый и несложный анализ, чтобы понять какие сайты ориентированы на удовлетворение пользователей (сделать им «быстро и удобно»), а какие нет (жрите, что дают). Отсеев тех, кто не с нами, будет проще формировать релевантную выдачу из быстрых и удобных ресурсов.

Может быть это будут накручивать. Может быть значимость этих факторов будет низкой. Но... Все это можно привести в порядок самому или с ограниченным привлечением сторонних специалистов за несравнимо меньшие суммы, чем тратятся на внешнюю и внутреннюю оптимизации.

Что входит в Page Experience (анализ удобства страницы):

Page Experience

Как видите, тут и удобство просмотра сайта на мобильных (кто еще об этом не задумался — самое время, ибо около 70% пользователей заходят в сеть с мобилок), и безопасность для пользователей (отдельно от Https), и, собственно, Https.

Первый пункт (Основные интернет-показатели)  — это и есть пресловутый Core Web Vitals. Состоит он из трех составляющих:

  1. Отрисовка самого крупного контента (LCP).

    Что такое LCP и каковые его значения

    Этот параметр отражает скорость загрузки. Чтобы страницей было удобно пользоваться, значение LCP должно по возможности составлять менее 2,5 с с момента начала ее загрузки. Грубо говоря, это скорость загрузки первого экрана, а точнее самого большого его фрагмента (можно посмотреть чего именно в Пейдж Спид).
  2. Задержка после первого ввода (FID).

    Что такое FID

    Этот параметр отражает интерактивность. Чтобы ей было удобно пользоваться, значение FID должно по возможности составлять менее 100 мс. Грубо говоря, это скорость реакции на нажатие кнопки на сайте. Как быстро начнет все меняться. Но это сильно утрировано.
  3. Совокупное смещение макета (CLS) отражает визуальную стабильность.

    Что такое CLS

    Чтобы страницей было удобно пользоваться, значение 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 сделал буквально вчера), но скриншот просто чтобы вы понимали, где именно смотреть:

Core Web Vitals в Гугл панели

Почему это вам не поможет

Ну, не знаю. Просто мне пока не помогло (положительного результата в ранжировании от увеличения скорости не видно). Начал оптимизацию скорости я давно. Правда, через пень-колоду и много косяков было по ходу преобразования (даже пришлось проверить все страницы сайта на Html валидаторе, и не зря — нашел десятка два критических ошибок).

Возможно, что сделанное сейчас аукнется в будущем. А пока я получаю чисто эстетическое удовольствие от осознания, что все что мог в области ускорения сайта на сегодняшний день я реализовал. Можно поставить галочку и заняться чем-то другим (не менее интересным).

Повторять ли вам мой путь, тратить ли на это время или деньги — вопрос риторический. Однако, буду признателен вашим замечаниям и, возможно, советам (например, по реализации на практике работающего нативного лези лоуда).

За сим разрешите откланяться.

Удачи вам! До скорых встреч на страницах блога7j.ru

Подробнее..
Категории: Ускоряем сайт

Категории

Последние комментарии

© 2006-2024, 07j.ru