Как не вылететь из поиска в 2021

Начну с тезисов:

1. Чем быстрее загрузится страница, тем меньше пользователей ее покинут. По данным исследований, 70% людей не готовы ждать загрузки мобильного сайта более 2-х секунд

2. С 2021 года скорость загрузки сайта на мобильном станет одним из факторов ранжирования в поисковой выдачи у Гугла

3. В вебмастере Яндекса появилась метрика «Скорость сайта», что видимо так же будет учитываться (или уже учитывается) при ранжировании поисковой выдачи

4. Для оптимизированных сайтов контекстная реклама у Гугла дешевле (по непроверенным данным от одного рекламного агентства)

Хочу поделиться опытом ускорения собственного сайта. Разработчик мне особо не смог помочь (или не захотел), пришлось разбираться самостоятельно. В сети встречается много однотипных статей по ускорению сайта, которые по сути являются переводом советов от PageSpeed Insights , я постараюсь не увлекаться копипастом.

Основные требования Гугла по метрикам сформулированы тут . Ему важно следующее:

1. Largest Contentful Paint (LCP) – время отрисовки самого большого видимого элемента. Как правило для е-комерса это какая-либо картинка: либо фото товара, либо банер

2. First Input Delay (FID) – скорость ответа сайта

3. Cumulative Layout Shift (CLS) – смещение слоев сайта в процессе загрузки страницы

Все остальные метрики больше справочные, позволяющие понять суть проблем.

В PageSpeed Insights я пользовался блоком «Данные наблюдений» для сбора статистики по метрикам. В этом блоке отображаются реальные данные пользователей за последние 28 дней по заданной странице. Этот блок выводится только для популярных страниц, у которых было достаточно посетителей.

Блок «Origin Summary» показывает картинку по сайту в целом.

В блоке «Имитация загрузки страницы» не всегда выводятся релевантные данные (по моему опыту). К примеру, для мобильной версии в разделе «Диагностика» в «Отрисовка самого крупного контента» почему-то выводятся файлы от десктопной версии, возможно эти же десктопные файлы и учитываются в расчетах имитации. Так же имитация в PageSpeed Insights отрабатывает в основном быстрее, чем реальные девайсы у пользователей.

Общая оценка скорости может варьироваться в пределах +- 20 единиц. Достаточно сделать 3-5 запусков с интервалом в пару часов, чтобы в этому убедиться. При этом замечал, что это не связано с возможным изменением нагрузки на сервер.

Данные наблюдений от PageSpeed Insights я фиксировал в экселе: как сайту в целом, так по некоторым страницам. Там так же отражал основные действия с сайтом, чтобы понимать какие именно доработки на что могли повлиять.

Вот так выглядит статистика:

Спойлер: на момент публикации мой сайт соответствует требованиям WebVitals и для десктопной, и для мобильной версии.

В разделе «Улучшения» - «Основные интернет-показатели» видна картинка как в целом по сайту, так и по конкретным страницам, которые нужно взять в работу.

Наиболее полезной мне показалась панель разработчика в Хроме. Открываем страницу в режиме инкогнито, жмем F12, переходим во вкладку lighthouse.

Для запуска тестов рекомендую выбрать Low-end-mobile или Mid-tier-mobile. С низкой скоростью можно больше поймать проблем, связанных с загрузкой. К примеру, у меня банера начинали листаться до полной загрузки всей страницы, что негативно сказывалось на метрике «Совокупное смещение макета при отрисовке». На нормальной скорости эта проблема не выявлялась, и я голову сломал, прежде чем нашел эту багу.

Информацию о скорости и порядке загрузки файлов можно получить на вкладке Perfomance. Там же можно увидеть, как происходит сборка страницы послайдово. Именно тут становится понятно, как смещаются слои.

Еще бывает полезным для контроля за LCP раздел Experience. В нем видно, что куда и на сколько сместилось. Но мне все же удобнее показались именно слайды.

На скорость загрузки сайта влияют:

1. Подготовка страницы на стороне сервера (рендеринг)

2. Количество загружаемых файлов и их размер

3. Скорость отработки скриптов

Для ускорения рендеринга помимо стандартных советов по настройке сервера и кэшированию стоит проанализировать долгие запросы к БД. Мы перестали делать некоторые запросы к БД «на лету» в момент рендеринга, и стали их пересчитывать по расписанию. К примеру, можно заранее подсчитывать количество товаров в категориях. Или пересобирать характеристики товаров в специальную таблицу для ускорения сборки работы фильтра (денормализация таблиц).

В процессе загрузки страница тянет за собой файлы со стилями, скриптами, изображениями и т.д.

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

Некоторые мелкие изображения (например, лого или заглушки) можно записать непосредственно в html файл, предварительно закодировав в base64.

Что касается стилей, их в идеале объединять в 1 файл. Это же касается скриптов.

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

Ленивую подгрузку тоже никто не отменял.

Так же сократив размер изображений можно добиться существенного прироста в мобильной версии. Сокращать можно как за счет снижения качества фотографий, так и за счет снижения размера. У меня на мобильной версии для ширины экрана в 320 пикселей подгружалось изображение размером 700*700. Сократив его до 350*350 я уменьшил размер файла в 4 раза.

Я проводил эксперименты с переводом изображений jpg в более современный формат WebP. Размер уменьшался процентов на 20%. Казалось бы – кайф, но заметил, что отрисовка страницы стала отрабатывать медленнее.

Порядком загрузки файлов можно управлять с помощью директив async, preload, defer, preconnect. Первые 2 позволяют существенно улучшить метрики быстродействия сайта. Встречаются неочевидные ситуации, когда подгружается файл стилей, а из него уже начинают подгружаться файлы со шрифтами. Полезно такие шрифты подгрузить заранее.

По ним директивам информации в сети достаточно много, тут не буду останавливаться.

Зачастую верстальщики не сохраняют необходимые файлы стилей и скриптов на сервере, предпочитая их загружать со сторонних ресурсов. Стоит ли вашему сайту зависеть от доступности других? Вопрос открытый.

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

Так же статику (да и вообще весь сайт) можно перенести на CDN (Content Delivery Network) - это сторонние серверы, которые заточены на быструю отдачу контента. В сети активно рекламируется сервис Сoudflare. Лично для нас он не дал какого-либо прироста. Вероятно, потому, что у него в РФ всего 2 сервера: в МСК и СПБ, ну а наши клиенты живут в Сибири. Предполагаю, что даст ускорение локальные CDN-сервисы, но их я не успел испытать.

Очень хорошо на снижение LCP повлияла предварительная загрузка самого крупного изображения – мы так подгружаем первый банер для главной или фото товара в карточке товара

До загрузки изображений лучше использовать заглушки. Обычный прозрачный квадрат весит примерно 1 кб, если его сжать в фотошопе.

На этом - все! Надеюсь, публикация оказалось полезной.

Если что-то упустил - буду рад дополнениям в каментах.