Скорость сайта – ахиллесова пята многих SEO-специалистов. Чаще всего при оптимизации сайта они сталкиваются с тем, что из-за обилия «тяжелых» картинок, ошибок при разработке сайта или же скриптов чатов сайт теряет свою скорость, и причем критично. Все это нужно объяснить клиенту и дать задачу штатному или удаленному программисту.
Но всегда ли это важно? Красивые цифры в Page Speed Insights – полбеды, что вообще входит в понятие «скорость сайта», на что она влияет и как ее оптимизировать?
Содержание статьи
«Скорость загрузки сайта» - с чем ее едят?
1. Скорость ответа сервера. Здесь ничего нового не скажем – это время между тем, как пользователь кликнул на сайт и ему начал загружаться сам ресурс.
Почему это важно?
Во-первых, скорость ответа сервера прекрасно отслеживает Яндекс, и чтобы не ждать предупреждения от Яндекса и понижения в выдаче, можно проверить свой сайт с помощью инструмента https://webmaster.yandex.ru/tools/server-response/ .
Во-вторых, скучающий пользователь, ожидая загрузки вашего сайта с 3D-моделями пылесосов, просто уйдет после 3 секунд загрузки, а вы получите себе в копилку не заказ, а увеличивающийся процент отказов.
2. Скорость загрузки контента. Это загрузка картинок и контента на сайте с сервера пользователю на устройство.
Почему это важно?
Опять-таки, картинка, которая весит 5 Мб и загружается минуту, скорее всего, приведет в недоумение пользователя, чем вызовет интерес. Но сразу предупредим, это палка о двух концах. Иногда лучше поставить картинку хорошего качества из интернета, которая весит больше рекомендованных 200 Кб, чем терять клиента из-за плохого, но своего фото товара.
Еще на скорость загрузки влияет местонахождение хостинга/сервера. Не секрет, что в одном регионе скорость будет довольно высокой с минимальной задержкой.
Если хостинг, на котором располагается сайт, находится в Америке (и тем более если хостинг виртуальный), то скорость загрузки будет ниже.
3. Скорость отрисовки страниц. Сайт состоит из элементов (картинки, скрипты и так далее), и при его загрузке у пользователя все собирается воедино – то есть отрисовывается.
Именно скорость отрисовки страниц и проверяет Google Page Speed Insights.
Это самый популярный ресурс для определения скорости сайта, но далеко не всегда самый верный. Ведь на скорость отрисовки страниц влияют:
- Количество элементов;
- Верстка сайта;
- Хостинг;
- Наполнение страницы;
- etc.
Список можно продолжать бесконечно. Если мы проверим любой интернет-магазин, например, Mvideo.ru, то увидим, что скорость отрисовки у них достаточно низкая:
Это неудивительно, потому что сайт, грубо говоря, сложный.
Как оптимизировать скорость загрузки сайта?
Допустим, вы все же столкнулись с тем, что скорость низкая, и с этим нужно что-то делать.
Сначала проверьте, стоит ли вообще оптимизировать скорость загрузки сайта. Мы проанализировали 3 проекта, которые находятся в ТОП-10 Яндекса и Google.
Все сайты по Loading Express и скорости ответа сервера получили хорошую оценку. Также мы привели примеры отказов в Метрике, чтобы вы поняли общую корреляцию. Показатели Google Page Speed Insights также на приемлемом уровне для ПК.
При этом наш сайт Lezhebokov.com получил оценку Google Page Speed Insights - 30 для ПК, 13 для мобильных. По мнениям, распространённым в интернете, нужно срочно бежать и оптимизировать скорости загрузки сайта, потому что это оценка Google, и вообще гробгробкладбищесмерть, но… при этом все продвигаемые запросы находятся в ТОП-10 Google по Уфе:
Потому что ничего общего оценка в Page Speed Insights с реальностью не имеет.
Скорость – это один из тысячи факторов, с помощью которого можно повлиять на ранжирование сайта.
Но бывает так, что вы заметили, что скорость загрузки сервера превышает требуемый показатель, или отрисовка контента чересчур длинная. И резонный вопрос: что делать, а главное, как объяснить программисту, что нам, SEO-специалистам, от него нужно?
Пойдем снова по пунктам.
Оптимизация скорости ответа сервера
1. Меняем хостинг/сервер
Если Яндекс уже неделю ругается, что скорость ответа сервера превышает допустимый максимум, логично, что нужно обратить внимание на сам сервер.
Сервер в Уганде – плохо. Виртуальный хостинг там же – вообще ужас.
Рекомендация: по возможности перейти на VPS. Если держите много «тяжелых» сайтов – берите выделенный сервер. Если у вас простой сайт услуг – берите хостинг на Beget/REG.ru.
2. Подключаем CDN
CDN (content delivery network) поможет пользователю подгрузить файл с сайта с сервера, находящийся ближе всего к его местоположению. Если все же хостинг сайта у нас остался в Уганде, предоставьте пользователю возможность хотя бы картинки смотреть из России.
3. Проверяем DNS-сервер
Немного разъясним.
Существуют авторитетные и рекурсивные DNS-серверы. Когда пользователь заходит на сайт, он делает DNS-запрос к рекурсивному серверу, где хранится кэш IP-адреса домена.
Рекомендация: выбрать DNS опять-таки не из Уганды, а проверенного и надежного оператора услуг.
Оптимизация загрузки контента
Здесь все попроще, нежели чем с сервером.
1. Проверяем вес изображений на сайте. В помощь: Screaming Frog, Page Speed Insights.
2. Сжимаем изображения примерно до 200-300Кб, проверяем качество.
3. Просим программиста подключить lazyload, сменить расширение файлов на webp или подключить CDN для изображений.
Здесь не забываем о правиле, что иногда «тяжелая» картинка лучше той, которая будет идеальна по меркам Page Speed Insights, но пользователю придется рассматривать ее с лупой, чтобы понять, какого вообще цвета товар.
Оптимизация отрисовки контента
Здесь озадачиваем программиста и подглядываем, что он делает:
- Улучшает значения рендеринга страницы: подключает «ленивую» загрузку, сообщает браузеру информацию о том, нужно ли отрисовывать элементы за пределами видимости сайта.
- Делает загрузку страницы частями, разделяя контент.
- Скрывает элементы, которые не нужны в мобильной версии сайта.
- Сообщает Вам, что сделать выше 60 баллов по Page Speed Insights вот вообще никак.
Последнее – шутка с долей правды. Если сайт загружается менее 3 секунд, а Page Speed Insight выдает 40 баллов – закройте Вы уже его и продолжайте работать над другими факторами.
Выводы
Что нужно обязательно делать при оптимизации скорости загрузки сайта? Приведем 3 правила:
- Не допускать изображений выше 1Мб на вашем сайте. В идеале – 200Кб.
- Подключать lazyload.
- Выбирать хостинг и сервер, который полностью удовлетворяет Вашим требованиям и требованиям поисковых систем.
Однозначно сказать, что вам нужно поменять, невозможно, не видя самого сайта. Если у вас интернет-магазин, скорость загрузки – один из тех факторов, которые находятся в «средней» зоне значимости.
Самый важный вывод: если есть отказы в метрике – значит, нужно проводить оптимизацию скорости загрузки сайта. А гнаться за красивыми цифрами – это ровно то же, что и сказать: сделайте мне красивый сайт.
Потенциальный покупатель не будет ждать Ваших невероятно красивых изображений, мириться с загрузкой по 15 секунд (3 секунды – его предел в наше неспокойное время с интернетом 5G). Он просто уйдет на другой сайт. Поэтому сейчас скорость сайта – это понимание того, от чего зависят отказы и конверсии на вашем ресурсе.
Ну и, конечно, делитесь своим мнением в комментариях :)
Подытожим.
1. Поджимаем картинки и используем lazy load. Всё, что можно, конвертируем в webp, который понимают далеко не все браузеры.
2. Не используем сервера в Уганде.
3. Используем CDN.
Всё? Кисловато. Давайте я чутка дополню реальными способами ускорения, чтоб перед роботами не было стыдно.
а) Снижаем количество запросов к серверу.
б) Включаем кэширование на уровне сервера и настраиваем кэширование на стороне клиента.
в) Разбираемся с настройками last-modified и 304-ми, объясняющими, что страничка не изменилась, бери, поисковик, контент из кэшей.
г) Настраиваем асинхронную загрузку, скрипты из "головы" переносим в "подвал" - все, что можно перенести (GTM можно оставить).
д) Избавляемся от мусора: лишних веб-шрифтов, избыточных css и js, которых на нынешних шаблонных сайтах - что блох на бродячей собаке.
е) Отключаем ненужные плагины и модули, создающие лишнюю нагрузку на сервер без всякой необходимости. Особенно это касается Bitrix и Wordpress.
ж) Смотрим на используемую CDN и думаем, действительно ли она ускоряет или и вовсе задерживает загрузку. Дешманские сидиэнки, как правило, только тормозят.
з) Анализируем DOM. Большинство верстальщиков понятия не имеет об оптимизации кода и скорости загрузки, поэтому вёрстка может быть проблемой не только для скорости загрузки сайта, но и для текстового ранжирования.
е) Оптимизируем БД, вдумчиво и аккуратно. Большинство тормозов в работе сайтов связано именно с ней.
Ну, и вот тогда, даст Кутулу, не только субъективная скорость загрузки улучшится, но и объективная, которая от картинок не очень-то и зависит. Даст ли это профит для ранжирования - отдельный вопрос.
в) Разбираемся с настройками last-modified и 304-ми, объясняющими, что страничка не изменилась, бери, поисковик, контент из кэшей.
г) Настраиваем асинхронную загрузку, скрипты из "головы" переносим в "подвал" - все, что можно перенести (GTM можно оставить).
Перечисленные пункты не добавят попугаев в Lighthouse (PageSpeed Insights)
Старая версия PSI вообще была предназначена для сплит-тестов версий посадок под рекламу. Новая худо-бедно показывает и реальную скорость по неким усредненным данным (типа из lighthouse).
Но суть в том, что попугаи не нужны. Данные PSI - не фактор ранжирования. Быстродействие измеряется не так и не этой балалайкой.
Быстродействие чего и какой балалайкой? Вот балалайки, которые отсчитывают Core Web Vitals.
Я про сервиски типа webpagetest.org
Очень удобно: можно протестировать загрузку с разных устройств и нескольких локаций по миру. К сожалению, серверов в РФ нету - самая ближняя Польша.
Однако базовый набор данных для первичного теста есть: ttfb, core web vitals, количество запросов, кэширование, архивация и прочее - всё наглядно.
Можно его собственно и у себя развернуть, если есть необходимость.
Ну, и gtmetrix грех не упомянуть - в принципе, те же метрики, только в профиль.
TTFB в отрыве от LCP, FID и CLS не имеет особого значения в части user experience, поэтому и был выпилен(скрыт) в Lighthouse.
И webpagetest, и gtmetrix годные инструменты, тут вопрос акцента. Google пытается описать/измерить метрики, важные для user experience
Не думаю, что он Web Vitals реально начнёт использовать как метрики ранжирования в обозримом будущем. Сколько они про http и mobile-first трындели, до сих пор в топах вижу сайты без адаптации.
Но если реально выкатят как фактор - ой вей, сколько сайтов падёт смертью храбрых