Здесь все попроще, нежели чем с сервером.
1. Проверяем вес изображений на сайте. В помощь: Screaming Frog, Page Speed Insights.
2. Сжимаем изображения примерно до 200-300Кб, проверяем качество.
3. Просим программиста подключить lazyload, сменить расширение файлов на webp или подключить CDN для изображений.
Здесь не забываем о правиле, что иногда «тяжелая» картинка лучше той, которая будет идеальна по меркам Page Speed Insights, но пользователю придется рассматривать ее с лупой, чтобы понять, какого вообще цвета товар.
Подытожим.
1. Поджимаем картинки и используем lazy load. Всё, что можно, конвертируем в webp, который понимают далеко не все браузеры.
2. Не используем сервера в Уганде.
3. Используем CDN.
Всё? Кисловато. Давайте я чутка дополню реальными способами ускорения, чтоб перед роботами не было стыдно.
а) Снижаем количество запросов к серверу.
б) Включаем кэширование на уровне сервера и настраиваем кэширование на стороне клиента.
в) Разбираемся с настройками last-modified и 304-ми, объясняющими, что страничка не изменилась, бери, поисковик, контент из кэшей.
г) Настраиваем асинхронную загрузку, скрипты из "головы" переносим в "подвал" - все, что можно перенести (GTM можно оставить).
д) Избавляемся от мусора: лишних веб-шрифтов, избыточных css и js, которых на нынешних шаблонных сайтах - что блох на бродячей собаке.
е) Отключаем ненужные плагины и модули, создающие лишнюю нагрузку на сервер без всякой необходимости. Особенно это касается Bitrix и Wordpress.
ж) Смотрим на используемую CDN и думаем, действительно ли она ускоряет или и вовсе задерживает загрузку. Дешманские сидиэнки, как правило, только тормозят.
з) Анализируем DOM. Большинство верстальщиков понятия не имеет об оптимизации кода и скорости загрузки, поэтому вёрстка может быть проблемой не только для скорости загрузки сайта, но и для текстового ранжирования.
е) Оптимизируем БД, вдумчиво и аккуратно. Большинство тормозов в работе сайтов связано именно с ней.
Ну, и вот тогда, даст Кутулу, не только субъективная скорость загрузки улучшится, но и объективная, которая от картинок не очень-то и зависит. Даст ли это профит для ранжирования - отдельный вопрос.
Благодарю. Приведенное в комментарии скорее чек-лист для программиста, но это тоже здорово.
И да, мы пишем, что баллы в Page Speed не критичны для измерения скорости сайта. Но как инструмент, чтобы разобраться, какие ошибки есть в отрисовки контента - вполне подойдет. Потому что асинхронная загрузка, используемые скрипты, DOM и БД – уже боль нашего штатного программиста 😬
б) Включаем кэширование на уровне сервера и настраиваем кэширование на стороне клиента. в) Разбираемся с настройками last-modified и 304-ми, объясняющими, что страничка не изменилась, бери, поисковик, контент из кэшей. г) Настраиваем асинхронную загрузку, скрипты из "головы" переносим в "подвал" - все, что можно перенести (GTM можно оставить).
Перечисленные пункты не добавят попугаев в Lighthouse (PageSpeed Insights)
Вот это уже правильный подход!
Много раз замечал, что некоторые страницы имеющие худшие показатели по Page Speed по факту грузились быстрее! Их подсказки конечно можно использовать для поиска мест где копать для оптимизации, но это ни разу не истина в последней инстанции и сильные сомнения у меня что этот показатель напрямую сильно влияет на ранжирование.
А вот фактическая прогрузка страниц на устройствах пользователя, может влиять значительно через ПФ (отказы, глубину)!
Спасибо за материал.
Хочу вставить свои 5 копеек.
1. Не увидел такого (прошу прощения если не увидел), что можно "изолировать версии" сайтов: мобильный, декстоп, планшет. То есть под каждое устройство свои JS и CSS. Соответственно для мобильного эти файлы будут весить по 15-20 килобайт и также для декстопа. Огромнейший ощутимый плюс
2. Попробовать использовать на сервере SSD NVMe, быстрее обрабатывает и собирает странице нежели обычный SSD
3. Кешировать страницы целиком, если есть ресурсы для хранения и разогрева кеша.
4. TLS 1.3, чтобы быстрее возобновлять пользовательские сессии
5. В head оставить только главный CSS. Все остальное спустить вниз и лучше избегать асинхронной загрузки скриптов, а использовать defer. То есть при верстке заложить, что JS не влияет на отрисовку страницы.
И будет вам счастье)
Остальное ребята описали выше (или ниже)
http/2. Я не проводил замеры, но субъективно шустрее начинает бегать. Мне это кажется или действительно тоже вариант?