Анастасия Осипенко
Мар 23, 2021 | Время чтения: 20 мин

Чем быстрее веб-страница загружается, тем удобнее она для пользователей. А насколько скорость загрузки важна для позиций в поиске?

Ни Google, ни Яндекс, ни другие поисковые системы не рассказывают, как конкретно они измеряют показатели скорости и насколько они влияют на ранжирование в поиске. Но сегодня можно быть уверенными, что удобство страниц становится важным фактором поискового продвижения. Оценка удобства страницы включает в себя несколько технических характеристик, в частности Core Web Vitals — метрики загрузки, интерактивности и визуальной стабильности. Если вкратце, то они оценивают не то, как быстро страница загружается, а то, как быстро рендерится первая видимая часть.

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

Баланс между удобством и скоростью

Google запустил инструмент для анализа производительности сайта в 2013 году: PageSpeed Insights сканировал ресурс и давал ему оценку вместе с рекомендациями по загрузке. Но этот анализ был не очень точным и репрезентативным. В 2018-м инструмент получил улучшенный алгоритм Lighthouse — с тех пор анализ скорости стал объективнее, так как инструмент начал оценивать рендеринг страницы. В 2021 году метрики удобства страницы выходят на передний план и станут важным аспектом ранжирования. 

Работать над скоростью несомненно нужно. Если страницы вашего сайта грузятся медленно, ваши позиции просядут вместе с показателями просмотра и конверсии. Но для успешного поискового продвижения недостаточно просто улучшать показатели загрузки — нужно находить баланс между скоростью и удобством для пользователей.

UX важен для всех поисковых систем: в руководстве Bing «положительный пользовательский опыт» признан более значимым, чем быстрая загрузка страниц, документация Yahoo! тоже указывает на приоритет удобства для пользователей в оценке скорости. Яндекс также акцентирует на том, что скорость загрузки важна для поведенческих факторов, и учитывает ее при ранжировании: в 2019 году поисковик внедрил технологию турбо-страниц с оптимизированной версткой, а в 2020-м подключил модуль скорости сайта в Яндекс.Вебмастер.

Процесс загрузки страницы от «а» до «я»

Чтобы разобраться в том, как работают показатели скорости и производительности, нужно для начала понимать, как загружается контент на странице и что на это влияет.

Незаметный для пользователя секундный процесс включает в себя несколько этапов:

  • Юзер вводит URL-адрес или переходит по ссылке, отправляя запрос серверу.
  • Сервер обрабатывает запрос и отправляет HTML браузеру.
  • Браузер строит DOM-дерево (Document Object Model, модель страницы из HTML-объектов) и парсит CSS-атрибуты.
  • Браузер рендерит страницу в соответствии с версткой, стилями и присутствующими элементами.

Процесс загрузки страницы

Метрики для анализа загрузки и удобства

На поведенческие факторы влияет несколько аспектов. Визуальная и смысловая составляющие важны для восприятия страницы, но основой всему остальному служат технические параметры — их оценивают метрики удобства страницы (page experience) в системе ранжирования Google.

Оценка удобства страницы включает:

  • Параметры Core Web Vitals: Largest Contentful Paint (LCP), First Input Delay (FID), Cumulative Layout Shift (CLS). Они отвечают за скорость загрузки, интерактивность страницы и стабильность верстки.
  • Дизайн, оптимизированный для мобильных устройств. Мобильный поиск становится все популярнее, поэтому адаптивный дизайн — один из приоритетов для поисковиков. Инструмент Google TestMySite анализирует загрузку страницы на мобильных устройствах. Также существуют отдельные онлайн-сервисы для аналогичной проверки.
  • Безопасный поиск. Алгоритм Safe Browsing проверяет сайты на наличие вредоносных факторов.
  • Протокол HTTPS. Google маркирует все HTTP-сайты как небезопасные с июля 2018 года, так что если вы до сих пор не переехали на HTTPS, стоит этим заняться. Узнайте, как перевести сайт на HTTPS без потерь трафика из нашей статьи.
  • Беспрепятственный доступ (отсутствие назойливых межстраничных объявлений). Межстраничные объявления (например, попапы) могут привести к штрафам от Google. Не подлежат штрафам объявления адекватного размера, которые не всплывают слишком неожиданно для пользователей, диалоговые окна для логина или вывода информации, требуемой по закону (например, о файлах cookie).

Рассмотрим детальнее параметры Core Web Vitals и способы их вычисления.

Largest Contentful Paint

Поисковые системы обращают внимание не на то, как быстро загрузится вся страница, а на то, как быстро станет доступным первый рендер (то есть первый экран, с которым можно взаимодействовать). Для пользователей точно так же важно, чтобы первый видимый фрагмент побыстрее стал читабельным и интерактивным. Largest Contentful Paint (LCP) — буквально «отрисовка самого большого элемента контента» — это изображение или текстовый блок, занимающий больше всего места на первом экране. 

Пример рендеринга страницы с постепенно появляющимися элементами на экране (LCP здесь — картинка):

Пример LCP при загрузке страницы

Типы файлов, которые могут быть самым большим элементом контента:

  • Изображения (<img>)
  • Изображения внутри svg-объектов (<image> внутри <svg>)
  • Видео (<video>)
  • Фоновые изображения, загруженные с помощью функции url()
  • Блочные элементы с текстовыми узлами

Что влияет на загрузку LCP:

  • Время ответа сервера. Оно зависит от многих факторов — провайдера хостинга, системы управления контентом, задействованных баз данных и др.
  • Блокирующие рендеринг JavaScript и CSS. Именно файлы JavaScript и CSS отвечают за интерактивность и визуальную привлекательность страницы. При обработке HTML браузер встречает JS- and CSS-файлы, которые нужно выгружать из сервера, — из-за этого тормозится процесс рендеринга.
  • Время загрузки ресурсов. На показатель LCP влияет время загрузки ресурсов страницы — кода, картинок, видео.
  • Тип рендеринга. Рендеринг JavaScript может осуществляться на стороне клиента и на стороне сервера. В первом случае рендеринг происходит непосредственно в браузере, а во втором браузер получает уже предварительно отрендеренный контент страницы из HTML-документа, запрошенного у сервера.

2.5 секунды и меньше — хороший показатель LCP.

Метрики Time to First Byte (время до первого байта) и First Contentful Paint (первый отрисованный элемент контента) тоже полезны в анализе LCP и скорости загрузки сайта в целом. Раньше для оценки скорости использовали FCP и First Meaningful Paint (первый значимый отрисованный элемент), но измерения FMP были во многом неточными и их сложно было стандартизировать для всех браузеров. В результате Google пришел к LCP как к более объективной метрике.

Чтобы вы не путались в этих показателях, подсуммируем их отличия:

  • FCP — любой отдельный элемент, который первым появляется на странице
  • FMP — самый большой сдвиг верстки в первом экране
  • LCP — самый большой отдельный элемент, показанный в первом экране

Разные метрики оценки загрузки страницы: FCP, FMP, LCP

First Input Delay

Метрика First Input Delay (буквально «задержка первого ввода») определяет то, как быстро страница становится интерактивной. Любой кликабельный элемент должен побыстрее обрабатываться браузером — а зависит это от собственного и стороннего кода, который используется для интерактивного контента.

Измерение FID нельзя симулировать в тестовой среде, потому что реальное взаимодействие юзеров — которые могут кликнуть по любому элементу в любой момент, или по нескольким сразу или подряд — может приводить к разным задержкам. Можно определить параметр FID по JavaScript с помощью Event Timing API, библиотеки web-vitals или библиотеки от GoogleChromeLabs.

Раньше в отчете Lighthouse можно было просмотреть показатель Max Potential First Input Delay (максимально возможная задержка первого ввода) — система анализировала основной поток выполнения и рассчитывала самый худший вариант задержки. Сейчас отчет включает две другие метрики, так или иначе связанные с FID:

  • Time To Interactive (время до интерактивности) — то, как быстро страница становится полностью интерактивной (когда со всеми ее элементами можно взаимодействовать).
  • Total Blocking Time (общее время блокировки) — промежуток времени после рендеринга FCP (первого элемента контента) до возможности взаимодействия со всей страницей (TTI). Эта метрика подобна FID, но она высчитывает время без учета реальных пользователей — добавляя все долгие JavaScript-задачи, блокирующие основной поток выполнения. 

Блокировка рендеринга при загрузке страницы

Для анализа интерактивности сайта стоит учитывать и FID, и TBT. Последнюю метрику вы можете увидеть в отчете Lighthouse:

Отчет производительности сайта Lighthouse

Несколько уточнений об измерении FID:

  • Значения FID зависят от каждой конкретной загрузки страницы реальным пользователем.
  • Показатель FID не зафиксируется, если пользователь никак не взаимодействует со страницей.
  • Измерения FID будут необъективными, если страница загружена в фоновой вкладке, потому что первое взаимодействие происходит не сразу после загрузки.

Хороший показатель FID — менее 100 миллисекунд.

Cumulative Layout Shift

Метрика Cumulative Layout Shift (совокупное смещение верстки) показывает, как быстро стабилизируется верстка страницы. Если ресурсы страницы загружаются асинхронно или DOM-элементы добавляются динамически, какие-то фрагменты могут смещаться во время загрузки. Низкий показатель CLS гарантирует легкое и беспрепятственное взаимодействие с веб-страницей.

Какие элементы могут быть причиной сдвига верстки:

  • Изображения и видео с неуказанными размерами
  • Шрифты, отличающиеся по размеру от резервных шрифтов
  • Сторонние виджеты или рекламные блоки, динамически изменяющие размер

Если текстовый или любой другой блок смещается в то время как пользователь с ним ознакамливается — это нарушает процесс взаимодействия со страницей и может стать причиной ухода с сайта. Одно дело, если сдвиг происходит во время чтения и скроллинга страницы, и другое дело, если юзер нажимает на кнопку или ссылку, но получает совершенно неожиданный результат. Важно минимизировать смещение верстки, чтобы предотвратить некорректные итоги пользовательских действий.

Пример загрузки изображения, которое смещает контент на странице:

Пример смещения верстки при загрузке страницы

Показатель CLS — произведение «доли воздействия» и «доли расстояния». Доля воздействия — размер той части страницы, на которой размещены нестабильные элементы. Она рассчитывается путем деления площади нестабильной области на площадь области просмотра. Доля расстояния — показатель смещения верстки в рамках экрана. Она рассчитывается путем деления самого большого расстояния сдвига на самую большую высоту экрана.

Измерение CLS (смещения верстки)

Давайте рассчитаем CLS по указанным на картинке выше данным. Доля воздействия — 0.375, доля расстояния — 0.125, так что показатель CLS равен 0.046875.

Показатель CLS ниже 0.1 считается хорошим, 0.1-0.25 требует улучшения, а выше 0.25 сигнализирует о серьезных проблемах.

Вы можете быстро оценить CLS любого сайта с помощью онлайн-калькуляторов:

Онлайн-калькулятор для измерения CLS

Что можно сделать, чтобы улучшить CLS:

  • Не размещайте контент поверх уже существующего.
  • Указывайте размеры изображений и видео. Если вы используете адаптивные изображения, браузер сам их размещает по странице в зависимости от размеров экрана девайса. Чтобы избежать сдвигов, нужно прописывать пропорции в CSS или в атрибуте srcset.
  • Используйте CSS-свойство transform для анимаций.
  • Используйте CSS-значения font:display для шрифтов или предварительно загружайте файлы шрифтов.
  • Указывайте точные параметры для рекламных блоков или используйте изначально фиксированные по размеру объявления.

Какие смещения не влияют на параметр CLS:

  • Намеренные изменения верстки, вызванные пользователем
  • Движение элементов, не отображаемых в окне экрана 
  • Смещения, вызванные добавлением нового элемента в DOM

Измерения CLS варьируются в зависимости от инструмента: данные мониторинга реальных юзеров включают сдвиги верстки, произошедшие только до первого рендеринга, а синтетические инструменты будут продолжать собирать смещения, пока страница полностью не загрузится. Чтобы получить объективную оценку, комбинируйте оба подхода.

Инструменты для измерения Core Web Vitals

Оценить сайт по параметрам Core Web Vitals можно с помощью отчета Chrome User Experience (CrUX), собирающего данные пользователей Chrome, инструмента PageSpeed Insights, который включает данные CrUX, или отчета Core Web Vitals в Google Search Console. Без учета пользовательских данных эти метрики можно проанализировать с помощью Chrome DevTools и Lighthouse.

Кроме этого существует множество онлайн-инструментов, которые мониторят разные показатели производительности сайта, включая Core Web Vitals. 

Проверка загрузки сайта и удобства страниц
Пример сбора данных Core Web Vitals

Как улучшить скорость загрузки сайта

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

Основные аспекты улучшения работы сайта:

  • Минимизация кода
  • Оптимизация визуального контента
  • Апгрейд хостинга

Давайте рассмотрим их детальнее.

Оптимизация JS, CSS, HTML

Ускорить загрузку сайта можно, удалив ненужные или блокирующие рендеринг ресурсы.

Минификация

Первое, что стоит сделать, для оптимизации загрузки сайта, — определить части кода, которые не используются, и удалить их. Этот процесс называется минификацией. Можно минимизировать код вручную или с помощью автоматизированных решений — например, Google рекомендует CSSNano и UglifyJS. Сеть доставки контента (CDN) тоже может автоматически минимизировать и сжимать файлы кода.

Минификация кода
Пример результата минификации

Чтобы определить, какой код не используется для работы сайта, можно воспользоваться Developer Tools в Chrome — перейдите во вкладку Sources в верхнем меню и Coverage в нижнем. Инструмент покажет реальную статистику по файлам JS и CSS и укажет размеры и процентное соотношение лишних файлов:

Статистика по файлам JS и CSS в Chrome Developer Tools

Проверить, какая часть JS- и CSS-кода не минимизирована, можно и в «Анализе сайта» SE Ranking — в разделе «Отчет об ошибках»:

Проверка кода в анализе сайта SE Ranking

В этом инструменте вы также можете проверить соотношение текста к HTML: слишком низкий показатель может сигнализировать о лишнем HTML-коде, который тормозит страницу. Хорошее соотношение — 20-70%.

Проверка соотношения текста к HTML в SE Ranking

Адаптация под разные устройства

Кроме минификации вы можете распределить файлы кода в зависимости от устройства — чтобы использование ресурсов ограничивалось только теми, которые нужны для конкретного девайса. Браузер может определять тип устройства с помощью user-agent и отправлять запрос к серверу на получение соответствующей версии сайта. Чтобы происходило именно так и сервер мог отвечать с нужной для конкретного девайса версткой — не используя при этом лишние ресурсы, код сайта должен включать несколько версий.

Встроенный стиль

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

Постепенный рендеринг

Когда браузер натыкается на файлы CSS или JS перед первым рендером, выполнение этих файлов приостанавливает процесс загрузки. Стоит определить, какие ресурсы на странице могут блокировать рендеринг, — для этого можно запустить проверку с помощью WebPageTest:

Определение блокирующих рендеринг ресурсов с помощью WebPageTest

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

Например, кнопки для распространения в соцсетях можно отображать не сразу — для этого нужно использовать асинхронную JavaScript-загрузку. Два атрибута помогают распределить скрипты и сделать рендеринг постепенным: async и defer. Их можно применять к собственному и стороннему JS-коду, сокращая время парсинга HTML без ущерба для отображения контента страницы.

Оптимизация изображений и видео

Очень важно оптимизировать визуальные материалы, ведь они занимают в среднем 21% веса страницы. Вы можете узнать больше деталей о SEO для изображений из нашего гайда, а здесь мы продублируем самые главные способы оптимизации визуального контента:

  • Используйте форматы, поддерживаемые всеми браузерами. Самые распространенные и беспроигрышные форматы — JPEG и PNG; WebP — многообещающий в плане качественного сжатия формат, но пока не доступен во всех браузерах; GIF можно использовать, если размер не слишком большой, или же конвертировать в видеофайл.
  • Сжимайте изображения без существенной потери качества. Можно пользоваться онлайн-инструментами или встроенными в CMS решениями для сжатия.
  • Указывайте несколько пропорций изображений, чтобы они выглядели как нужно на любом устройстве. Большинство CMS способны сделать это автоматически.
  • Используйте асинхронную загрузку, если на странице много изображений. Сделать это можно с помощью ленивой загрузки или атрибута decoding=async.
  • Храните большие видеофайлы на сторонних сайтах, чтобы уменьшить нагрузку при отображении сайта.

В «Анализе сайта» SE Ranking, в разделе «Найденные ресурсы», можно просмотреть размеры изображений и время их загрузки:

Проверка размеров изображений в анализе сайта SE Ranking

Оптимизация сервера

С помощью инструмента SE Ranking вы также можете проанализировать общую ситуацию скорости ответов сервера:

Проверка времени ответа сервера в анализе сайта SE Ranking

Кроме файлов кода и других ресурсов на сайте на время ответа сервера влияют:

  • Возможности девайса и качество связи со стороны пользователя
  • Количество получаемого сайтом трафика
  • Ресурсы на каждой странице
  • Выбранный провайдер и тип хостинга
  • CMS и подключенные к ней плагины

Оборудование и сетевое подключение

Нельзя упускать из виду тот факт, что загрузка сайта во многом зависит от пользователя — используемого устройства и качества подключения. Просмотр веб-страниц с компьютера со стабильным подключением отличается от просмотра со смартфона с ограниченными возможностями центрального процессора и памяти. Поэтому важно отслеживать, какие девайсы популярны среди вашей аудитории, и проводить тесты на этих девайсах. В целом важны разные типы тестирования, с помощью которых можно симулировать плохую связь и устройства со слабой производительностью.

Хостинг и CDN

Как бы вы ни старались оптимизировать скорость сайта, с дешевым совместным хостингом добиться быстрой загрузки и удобства для пользователей будет очень сложно. Цена — важный аспект при выборе провайдера и типа хостинга, но экономия может обернуться против вас, особенно если ваш сайт продает товары или услуги, содержит много мультимедийного контента или таргетирует людей из разных локаций.

Выделенный сервер — всегда лучший выбор, потому что так вы не будете делить сервер с другими сайтами. Как промежуточный вариант можно рассматривать виртуальный приватный сервер (VPS), который является совместным, но имитирует выделенный сервер. 

Также задумайтесь об использовании сети доставки контента (CDN), в частности если вы целитесь на пользователей из разных стран и регионов. Эта инфраструктура распределяет нагрузку между несколькими серверами, расположенными в разных географических точках. 

Кэширование

С помощью кэширования можно дать указания серверу или браузеру хранить ранее загруженный контент — так они не будут обрабатывать страницу, когда пользователь зайдет на нее повторно. Загрузка из кэша минимизирует нагрузку на сервер и улучшает производительность — например, исследование Kinsta показало, что кэширование на стороне сервера может уменьшить время загрузки на целых 30%. Можно настроить кэширование вручную в коде или с помощью плагинов вроде WP Rocket и W3 Total Cache. Некоторые провайдеры хостинга автоматически отправляют статический контент в кэш.

Редиректы

Каждый настроенный редирект замедляет процесс загрузки страницы, поэтому стоит проверять их количество и избегать проблем с цепочками перенаправлений. Узнайте больше о работе редиректов из нашего гайда, а пока разберемся с тем, как их отслеживать. В «Анализе сайта» SE Ranking вы можете просматривать список настроенных редиректов и их ответы сервера, определяя проблемные моменты:

Проверка редиректов в анализе сайта SE Ranking

Проверка плагинов

Еще один фактор влияния на скорость и производительность сайта — плагины. Используйте самые актуальные версии CMS и плагинов и следите, чтобы они работали на последней версии PHP. С помощью онлайн-инструментов проверяйте плагины на предмет использования памяти и влияния на скорость загрузки:

Проверка производительности плагина

Чеклист оптимизации загрузки сайта

Подобьем итоги — почему важно улучшать показатели загрузки сайта и удобства страниц:

  • Медленная загрузка веб-страниц несомненно портит впечатление о сайте и негативно влияет на конверсию, но не делайте ставку только на улучшение скорости — анализируйте и отслеживайте метрики, напрямую влияющие на взаимодействие пользователей с сайтом. Сигналы удобства страниц должны быть в центре вашего внимания, ведь они в приоритете Google и будут напрямую влиять на ранжирование с мая 2021 года.
  • Метрики Core Web Vitals оценивают то, как быстро страница становится доступной и интерактивной, и здесь важна не скорость загрузки всей страницы, а скорость рендеринга первого экрана. Хорошими показателями считаются LCP до 2.5 секунды, FID до 100 миллисекунд и CLS до 0.1. Измеряйте их и в тестовой среде, и с учетом данных реальных пользователей.
  • Отслеживая сигналы удобства страниц, вы будете лучше понимать, что нужно исправить для оптимизации скорости. Среди основных действий, улучшающих загрузку, — минификация кода, оптимизация изображений и выбор подходящего хостинга. Регулярно запускайте проверку своего сайта, чтобы вовремя реагировать на проблемы, влияющие на загрузку.

4 комментария
  1. Интересно, что турбо-страницы яндекса – это аналог AMP, от которых гугл будет отказываться

    1. Спасибо за комментарий! Действительно подход поисковиков отличается, и пока Яндекс делает акцент на ускоренных страницах, Google переходит к параметрам удобства страницы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

БОЛЬШЕ ИНТЕРЕСНЫХ СТАТЕЙ
Экспертиза
Ошибки SSL/TLS и способы их исправления
Апр 02, 2021 Время чтения: 9 мин

Технология SSL/TLS обеспечивает безопасное соединение, поэтому для любого сайта важно настроить надежный SSL-/TLS-сертификат. В этой статье мы рассказываем о том, как работает SSL/TLS, как исправить типичные ошибки в использовании SSL/TLS и какие версии протокола и алгоритмов шифрования самые актуальные.

Анастасия Осипенко
Экспертиза
SEO для новых сайтов: как понравиться поисковикам
Мар 31, 2021 Время чтения: 18 мин

Если у вас появился новый сайт, но Google его не видит, скорее начинайте работать над поисковой оптимизацией. В этой статье мы поможем найти и решить технические проблемы сайта, сделать контент понятным для пользователей и поисковиков и составить грамотный план по наращиванию ссылочной массы.

Мария Ефименко
Экспертиза
Гид по атрибуту hreflang для начинающих
Мар 30, 2021 Время чтения: 12 мин

Если на вашем сайте есть страницы для пользователей из разных стран, говорящих на разных языках, вам наверняка стоит настроить языковую разметку hreflang. Узнайте, как задавать атрибут hreflang, чтобы посетители видели подходящую версию страницы.

Мария Ефименко