Скорость сайта – ахиллесова пята многих 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. Большинство верстальщиков понятия не имеет об оптимизации кода и скорости загрузки, поэтому вёрстка может быть проблемой не только для скорости загрузки сайта, но и для текстового ранжирования.
е) Оптимизируем БД, вдумчиво и аккуратно. Большинство тормозов в работе сайтов связано именно с ней.
Ну, и вот тогда, даст Кутулу, не только субъективная скорость загрузки улучшится, но и объективная, которая от картинок не очень-то и зависит. Даст ли это профит для ранжирования - отдельный вопрос.
Благодарю. Приведенное в комментарии скорее чек-лист для программиста, но это тоже здорово.
И да, мы пишем, что баллы в 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. Я не проводил замеры, но субъективно шустрее начинает бегать. Мне это кажется или действительно тоже вариант?
Спасибо за хорошие рекомендации)
Для беглого анализа скорости группы сайтов или страниц рекомендую программу BulkPageSpeed ( https://site-analyzer.ru/soft/bulk-google-page-speed/ ) для массовой проверки скорости загрузки страниц сайта по Google PageSpeed Insights (показывает основные параметры и общую оценку скорости сайта).
3 сек реально за глаза, мы делали исследование про влияние скорости загрузки на показатель отказа в яндексе https://overlead.me/blog/vliyanie-skorosti-zagruzki-stranicy-na-pokazatel-otkaza/
Милана, то что Вы написали далеко от истины. Важна не прорисовка страницы, а прорисовка первого экрана. И можно легко сделать 95 баллов, даже если у вас 30 картинок, установлена Метрика и Аналитика. Всё дело в том, чтобы сосредоточиться на оптимизации 1го экрана. Все советы что Вы даете: лейзилоад, cdn это лечение симптомов. Даже хуже. Это вредные советы. . Тот лейзилоад, который реализон на большинстве сайтов вреден, потому что нарушает правильную индексацию картинок
В продвижении, как уже писал, как на войне. 0.01%, это тоже хорошо. Но! Скорость как фактор ранжирования учитывается только при остальных равных. То есть, у вас на двух сайтах, примерно одинакового качества контент, одинаковое количество пользователей, одинаковые поведенческие (все это недостижимо), сайты одинаково удобны - тогда скорость, как фактор работает. Тот, кто быстрее, будет в выдаче выше.
А по факту, сайт со скоростью 100/100 (чего я видел только один раз, случайный тест показал), может находиться бог знает где, из за качества контента.
Как эта информация поможет SEO'шнику? Просто я, как веб-разработчик этого вообще не понимаю. Этого не досточно для того, чтобы составить ТЗ. Ну, а с точки зрения бизнеса - это достаточно дорого. Ведь для этого потребуется системный администратор, front-end и back-end разработчик, а еще CDN и VPS.
Ну и к вашему сведенью, Beget и Reg.ru - это самые тормозные хостинги, с которым я когда-либо работал. Сравните время ответа сервера Beget/Reg.ru с Sweb/Fornex и будите сильно удивлены, как круто оно отличается.
И да, вы правы, скорость загрузки сайта официально является фактором ранжирования в Google, но достаточно незначительным. Так например, блог Brian Dean имеет очень низкую оценку по PageSpeed, но при это все его страницы находятся в ТОП'е поисковой выдачи Google.
Брайан будет в топах только потому, что идут именно к нему. Тут все метрики уступают, если речь о тайп-ин и витальных запросах.
Ну и есть ещё Яндекс. Вот у нас сотня безликих сайтов, одинаково скверных, с одинаковыми ценами, рерайтами одного и того же текста, реальный цифровой мусор. Как выбрать лучших из худших? – Да хоть по скорости загрузки.
Есть и третья причина: в этой череде цифрового мусора пользователь выберет то, что доставит меньше хлопот с загрузкой. Статистика не врёт: 4 секунды - минус 60% посетителей.
А причина одна (безблагодатность)
Вы делаете ошибочные выводы. Просто у сайтов в Топе мощное ссылочное.
Но если сравнивать два сайта с одинаковым количеством внешних ссылок, то выше будет тот, у которого скорость загрузки выше
Горячая тема! Автор далека от тех деталей, обычный сеошник. Я не буду умничать дам совет только. Вы про webp больше не заикайтесь, айфоны его не понимают и выдают пустой блок. Вроде пару недель назад там договорились что айфон будет понимать webp, но опять же только в новых версиях ПО. А на счет объемов фото раньше надо было париться, сейчас уже всё меньше и меньше. Любой хороший программист сможет написать программу которая будет заранее оптимизировать фото под нужный размер в указанном месте. Можете посмотреть шаблон колормаг от themegrill там эта функция реализована очень удачно
"Вы про webp больше не заикайтесь" Webp можно по агенту/браузеру выдавать через сервер, или через picture src реализовать на крайний случай и не будет никаких пустых блоков
Да, с webp вопрос до сих пор спорный, некоторые сайты внедряют, некоторые - нет. Видимо, через год или два этот вопрос станет снова актуальным.
В чем проблема IOS отдавать не webp?
"Показатели Google Page Speed Insights также на приемлемом уровне для ПК."
У моего сайта показатель для ПК - 82%, а вот для мобильных устройств еле еле 30 натягивает. Что нужно предпринять?
Фактически - ничего. В статье абсолютно правильно сказано, что как таковые данные GSI ничего не определяют. Инсайты - они и есть инсайты, способ понять, что может быть не так и куда копать.
Если у вас по позициям и трафу стагнация или и вовсе - падение, тут уже простор для подумать, может, техничка хромает или юзверям сайт кажется чересчур тормозным. Если нет - я бы не парился этим вопросом.
Потому что у вас куча CSS который не используется в мобильной верстке, предназначенный для ПК. Если удалить и отдать только под мобильный то будет одинакового. Вот попробовали изолировать версии и показатели на мобайл.
Виктор и Сергей правы. Опять повторимся, что показатель Page Speed Insights не влияет на ранжирование сайта.
Но если вы замерили другими сервисами, что скорость для мобильных низкая, то передайте программисту задачу оптимизировать мобильную версию, использовать меньше ненужного кода для загрузки и т.д. Но более 60 баллов Google редко выдает сейчас для мобильных.
Кстати региональная принадлежность сайта для Гугл уходит на второй план, главное языку контента, к примеру сайт со швейцарским доменным адресом - https://www.mamytova.ch/ прекрасно ранжируеться как при поиске из России, так и Украины
По информационным запросам, да. Этому сайту нельзя задать регион Россия. Подробнее читайте тут https://support.google.com/webmasters/answer/182192?hl=ru
Не надо на это тратить много времени. В топе висят сайты, скорость загрузки которых в районе 25 и нет проблем. Не это главное.
Я тоже человек далёкий от сео, но даже я понимаю, как важно оптимизировать картинки и адаптировать сайт под мобильные. Мы даже когда заказываем линки в zenlink, берём соц. сети в том числе, так как многих пользователи интернета только с телефона там и бывают.
Уважаемые знатоки, подскажите пожалуйста что нужно сделать / какая стоимость поднятия сайта в ТОП гугл и как его ускорить, особенно мобильную версию.
Направление:
Бензиновые генераторы.
Дизельные генераторы.
Electric-gear.com.ua
Viber для связи
+380939959326
Комментарий недоступен
По информации от независимого сервиса «хостинг пульс», одним из самых производительных хостингов в рунете является руцентр. Если интересно посмотреть подробнее на все выкладки по сравниваемым характеристикам, то это можно сделать в статье на дзене https://zen.yandex.ru/media/rucenter/stoit-li-doveriat-reitingam-pri-vybore-hostinga-pogovorili-s-sozdatelem-servisa-hosting-puls-60229d3aff10a04637556941
Игрались мы как-то с этим Пейдж спидом, толку ноль. Яндекс метрика всё испортила, но мы всеравно достигли, как вы написали в статье, мечты сеошника на примере страниц https://pravozem.ru/uslugi/ Трафик от Гугла даже упал. Вот такой результат. Решили что в других страницах будем менять дизайн сайта без учёта этих скоростных показателей.
Комментарий удален модератором