Оптимизация скорости загрузки сайта, или почему не стоит гнаться за цифрами
Скорость сайта – ахиллесова пята многих SEO-специалистов. Чаще всего при оптимизации сайта они сталкиваются с тем, что из-за обилия «тяжелых» картинок, ошибок при разработке сайта или же скриптов чатов сайт теряет свою скорость, и причем критично. Все это нужно объяснить клиенту и дать задачу штатному или удаленному программисту.
Подытожим.
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)
Вот это уже правильный подход!