SEO 2021. Скорость работы сайта, или удобство для пользователя. Какие параметры важнее?
Как найти баланс между скоростью и функциональностью сайта, не обидев посетителей
Время, необходимое для отображения содержимого веб-страницы, играет решающую роль в том, как пользователи будут взаимодействовать с ней. Это ясно.
Хотя, естественно, скорость загрузки страницы напрямую связана с пользовательским опытом. Осталось разобраться, насколько она (скорость загрузки) действительно важна для показа и рейтинга в поиске? От Google, как и от других поисковых систем, не было особой ясности в том, как они точно измеряют параметры скорости и насколько скорость страницы является фактором ранжирования.
Но теперь уже очевидно, что опыт работы со страницей становится важным фактором ранжирования. Он состоит из нескольких технических характеристик, включая аспекты загрузки, интерактивности и визуальной стабильности, известные как Core Web Vitals.
В этой статье мы подробно рассмотрим все эти термины и аспекты, обсудим другие показатели скорости веб-сайта и объясним, как улучшить скорость и производительность вашего веб-сайта, чтобы положительно повлиять на SEO.
Google впервые представил инструмент для анализа производительности веб-сайтов в 2013 году: PageSpeed Insights протестировала страницу и выставила оценку, дав рекомендации по улучшению.
Но, как показали исследования, полученная оценка была не очень точной как для оценки скорости, так и для результатов SEO. В 2018 году компания Google PageSpeed Insights усовершенствовала свои алгоритмы с помощью Lighthouse, предоставив тестирование скорости, которое является более объективным и более ценным для пользователей, поскольку оно учитывает возможности рендеринга.
Что еще более важно, показатели качества страницы скоро станут истинным сигналом ранжирования. Core Web Vitals также будут критерием для отображения веб-страницы в поисковой выдаче.
Легко понять теперь, что одно только повышение скорости вашего веб-сайта не приведет к вершине, хотя, нужно продолжать работать, чтобы гарантировать посетителям приличную скорость загрузки и бесперебойную работу. Естественно, если ваши страницы очень медленно загружаются и не позволяют пользователям свободно перемещаться по сайту, это максимально ухудшит выдачу в поиске, а также CTRCTR (кликабельность, англ. click-through rate — показатель кликабельности) — метрика в интернет-маркетинге. CTR определяется как отношение числа кликов на баннер или рекламное объявление к числу показов, измеряется в процентах
© Википедия
и коэффициент конверсии.
Но именно баланс между параметрами скорости вашего сайта и показателями пользовательского опыта улучшит ваш рейтинг.
Несмотря на то, что мы мало знаем о том, как именно другие поисковые системы оценивают такие показатели, как сигналы взаимодействия со страницей Google, все они ценят UX. В Руководстве для веб-мастеров Bing утверждается, что «положительное впечатление пользователя» важнее, чем просто более быстрая загрузка страницы; Yahoo Developer Network также подчеркивает важность UX, говоря о скорости.
Чтобы понять показатели производительности веб-сайта, нам необходимо знать, как загружается контент на веб-страницах и какие факторы влияют на этот процесс.
То, что должно произойти за секунды, - это многоступенчатый технический процесс:
✔ Он начинается с первоначального запроса к серверу, когда пользователь вводит URL-адрес или щелкает ссылку.
✔ Сервер обрабатывает запрос и отправляет HTML-ответ браузеру пользователя.
✔ Браузер строит дерево DOM (объектная модель документа, модель страницы, построенная из объектов HTML) и анализирует атрибуты CSS для отображения страницы.
✔ Браузер выполняет процесс макета, рисования и размещения элементов и стилей в нужных местах на странице.
Сигналы взаимодействия со страницей оценивают, как пользователи воспринимают данную веб-страницу и что делают с ней. Естественно, существуют факторы, связанные с дизайном и контентом, которые также несут ответственность за взаимодействие с пользователем, но восприятие страницы концентрируется на технических параметрах, которые создают основу для всех других факторов.
К сигналам восприятия страницы относятся:
✔ Core Web Vitals: самое большое время отрисовки содержимого (LCP), задержка первого ввода (первое впечатление пользователя об интерактивности и быстродействии вашего сайта) (FID) и совокупный сдвиг макета (CLS) (Сдвиги макета определяются каждый раз, когда элемент, видимый в области просмотра, меняет свое начальное положение).
Эти показатели означают производительность загрузки, интерактивность страницы и визуальную стабильность соответственно.
✔ Мобильный дизайн. Число поисковых запросов и посещений веб-сайтов с мобильных устройств растет, что делает мобильную оптимизацию одним из главных приоритетов Google.
Инструмент Google TestMySite позволяет анализировать скорость загрузки сайта на мобильных устройствах:
Инструмент Google TestMySite
✔ Безопасный просмотр. Алгоритм безопасного просмотра проверяет любое вредоносное поведение, которое может быть на веб-сайте.
✔ HTTPS-соединение. Google считает, что все веб-сайты HTTP небезопасны с июля 2018 года, поэтому в ваших интересах перейти на HTTPS, если вы еще этого не сделали.
✔ Доступность (без навязчивых межстраничных объявлений). Google будет наказывать за межстраничные объявления, такие как всплывающие окна, за исключением случаев, когда они имеют разумный размер и не являются неприятным сюрпризом для пользователей. Диалоги входа в систему и всплывающие окна, не подлежащие общедоступной индексации, созданные в соответствии с законом, не подлежат штрафным санкциям. Давайте подробно рассмотрим показатели Core Web Vitals.
Основное в том, как поисковые системы оценивают скорость веб-сайта, является то, что их не волнует, как быстро загружается вся страница, а волнует, как быстро будет представлен первый рендер.
То же самое и с реальными пользователями: прежде всего вы должны позволить им видеть и взаимодействовать с блоком страницы, которую они впервые видят в области просмотра. Это самое большое визуализированное изображение или текстовый блок - это то, что означает LCP.
Вот как отображается страница с элементами, постепенно появляющимися на экране мобильного устройства:
Для LCP можно рассматривать следующие типы элементов:
- <img>
- <image> внутри <svg>
- <video>
- элемент фонового изображения, загружаемый через функцию url
- блочные элементы, содержащие текстовые узлы
На LCP могут влиять:
Время ответа сервера. Это зависит от многих факторов, включая хостинг-провайдера, CMS, базы данных и т. д.
JavaScript и CSS с блокировкой рендеринга. При обработке HTML браузер может наткнуться на файлы JS и CSS, которые необходимо загрузить с сервера для выполнения. Файлы JavaScript и CSS делают страницу интерактивной и визуально привлекательной.
Показатели загрузки ресурсов. Время, необходимое для загрузки каждого ресурса (будь то файлы кода, изображения или видео) выше сгиба, влияет на LCP.
Тип рендеринга. Рендеринг JavaScript может выполняться на стороне сервера или клиента. В последнем варианте рендеринг выполняется непосредственно в браузере, и именно браузер выполняет файл. При рендеринге на стороне сервера браузер получает весь контент в удобном виде с предварительным рендерингом - из документа HTML, запрошенного с сервера.
Такие показатели, как Time to First Byte (TTFB) и First Contentful Paint (FCP), тоже полезны для диагностики LCP вашего сайта и общей производительности. Фактически, FCP использовался вместе с First Meaningful Paint (FMP) раньше, но Google обнаружил, что LCP более точен. FMP показал противоречивые результаты и не может быть стандартизирован для всех браузеров.
Поскольку эти показатели легко спутать, мы проиллюстрируем их различия:
• FCP - это первый индивидуальный элемент
• FMP - самое крупное изменение компоновки
• LCP - это самый крупный отдельный элемент в первом рендере.
FID измеряет, насколько быстро страница становится интерактивной. Когда пользователь нажимает на элемент сайта, браузер обрабатывает это действие и выдает результат, и чем быстрее он это сделает, тем лучше. Скорость здесь зависит от внутреннего и стороннего кода, используемого для содержимого страницы, вызванного действием пользователя.
FID - это метрика поля, которую невозможно смоделировать в лабораторной среде: пользователь может щелкнуть любой элемент на странице в любое время, и каждый элемент может иметь определенную задержку.
Раньше в отчете Lighthouse отображался MPFID (максимальная потенциальная задержка первого входа), вычислявший наихудший сценарий путем анализа основного потока. Теперь он включает в себя другие метрики, связанные с FID:
• TTI (Time To Interactive) измеряет время, необходимое для того, чтобы страница стала полностью интерактивной.
• TBT (Total Blocking Time) измеряет время после создания FCP (First Contentful Paint) и до того, как страница станет полностью интерактивной (TTI). Это похоже на метрику FID, но в отличие от последней, она вычисляет время без ввода данных пользователем, просто складывая время для каждой длинной задачи JS, которая блокирует основной поток.
Важно сочетать измерения FID и TBT для оценки интерактивности вашего веб-сайта. Вы можете увидеть эти параметры в отчете Lighthouse:
Несколько замечаний по поводу измерений FID:
• Значения FID различаются в зависимости от загрузки страницы и пользователей.
• FID не будет записан, если пользователь не взаимодействует со страницей
• FID не следует измерять, если страница загружается на фоновой вкладке, потому что первое взаимодействие происходит не сразу после загрузки страницы.
CLS показывает, насколько быстро контент на странице становится стабильным. Когда ресурсы, присутствующие на странице, загружаются асинхронно или элементы DOM добавляются динамически, некоторые фрагменты содержимого страницы могут перемещаться.
Согласно Google, показатели Core Web Vitals помогают обеспечить успешную навигацию по веб-странице, ее удобство использования и красоту, а низкий уровень CLS отвечает за восхитительное качество.
Какие элементы могут вызвать сдвиг макета:
• Изображения и видео с неопределенными размерами
• Шрифты, размер которых отличается от резервных шрифтов
• Сторонние объявления или виджеты с динамически изменяемым размером
Человек начинает читать то, что находится на странице, а затем происходит резкое смещение заголовка или абзаца, это мешает, раздражает и пользователь может прекратить изучение сайта. Еще хуже, когда ссылки или кнопки прыгают после загрузки: люди в конечном итоге, щелкают в пустое пространство или не в тот элемент, на который они нацелились.
Вот пример сторонней рекламы, которая является задерживаемым контентом на странице, вызывающим сдвиг:
Оценка сдвига макета является произведением доли удара и доли расстояния. Доля удара показывает, какая часть видимой части страницы занята нестабильными элементами.
Он рассчитывается путем деления площади всех нестабильных элементов на площадь области просмотра. Доля расстояния показывает, как далеко могут смещаться элементы в видимой части страницы.
Он рассчитывается путем деления наибольшего расстояния перемещения любого элемента на наибольший размер окна просмотра.
Давайте посчитаем (основываясь на числах выше). Доля удара составляет 0,375, а доля расстояния - 0,125, поэтому CLS составляет 0,046875.
0,1–0,25 означает, что есть возможности для улучшения,
а значение CLS выше 0,25 сигнализирует о проблемах, которые необходимо исправить.
Существуют онлайн-калькуляторы, позволяющие быстро оценить CLS любого сайта в настольной и мобильной версиях:
Основные предложения по улучшению CLS:
• Не размещайте намеренно контент над существующим.
• Укажите размеры изображений и видео. При использовании адаптивных изображений браузер сначала загружает их, а затем выделяет место. Чтобы предотвратить сдвиги, используйте соотношение сторон или включите несколько размеров в атрибут srcset.
• Для анимации используйте свойство преобразования CSS, чтобы избежать изменений макета.
• Для шрифтов используйте font: отображайте значения или предварительно загружайте файлы шрифтов.
• Для рекламы зарезервируйте фиксированный размер для рекламного места или выберите рекламные блоки фиксированного размера.
Есть некоторые изменения, которые не повлияют на оценку CLS:
• Преднамеренные изменения макета, т. е. вызванные пользователем.
• Движение элементов, которые не видны в окне просмотра
• Сдвиги, происходящие после добавления нового элемента в DOM
Обратите внимание, что измерения CLS могут отличаться от одного инструмента к другому: реальные данные пользовательского мониторинга будут накапливать сдвиги макета только перед загрузкой, тогда как синтетические инструменты мониторинга будут продолжать работу до полной загрузки страницы. Лучше всего сочетать два подхода к тестированию CLS вашего сайта.
Чтобы получить данные о Core Web Vitals вашего веб-сайта, вы можете использовать отчет об опыте пользователя Chrome или CrUX (который собирает данные только от пользователей Chrome), PageSpeed Insights (который включает данные из CrUX) или Core Web Search Console. Вы также можете протестировать эти показатели в лабораторной среде с помощью Chrome DevTools и Lighthouse.
Теперь, когда вы знаете, на каких параметрах следует сосредоточиться и как проверить слабые места вашего веб-сайта в отношении скорости и производительности, появился вопрос, что делать, чтобы на самом деле улучшить сигналы взаимодействия с страницей.
Необходимо учитывать следующие основные факторы:
• минимизация кода
• оптимизация визуального контента
• обновление хостинга
Рассмотрим их подробнее.
Чтобы оптимизировать свой код для SEO, вы можете определить ненужное, блокирующие рендеринг, и удалить.
Самое главное - минимизировать код, удалив все, что не используется. Минификация подразумевает удаление ненужных или избыточных частей кода, таких как комментарии или неиспользуемые источники. Это можно сделать как вручную, так и с помощью автоматических инструментов минификации.
Google рекомендует использовать для этой цели CSSNano и UglifyJS. Обратите внимание, что сеть доставки контента (CDN) может обеспечивать автоматическую минификацию и сжатие файлов кода, хранящихся на ее серверах.
Чтобы узнать о неиспользуемом коде, который можно удалить, вы можете открыть Инструменты разработчика в Chrome и перейти на вкладку «Источники», а затем на вкладку «Покрытие». Он дает фактическую статистику по файлам JS и CSS, показывая, какая часть кода на странице действительно выполняется:
Помимо минификации, вы можете использовать код, ограничивая источники в зависимости от типа устройства. Браузер определяет тип устройства с помощью пользовательского агента и отправляет его на сервер, чтобы сервер мог ответить соответствующей версией сайта. Для реализации этой логики код сайта должен включать несколько версий, подходящих для разных устройств. Таким образом, при каждом отдельном посещении веб-сайта не будет запрашиваться ненужный код.
Иногда имеет смысл использовать встроенный CSS, если в целом у вас не так много кода CSS. Таким образом, вы будете применять стили к каждому элементу HTML напрямую, и браузеру не нужно будет загружать файлы CSS отдельно, что ускорит рендеринг первого. Однако поддерживать такой код сложнее.
Когда браузер встречает CSS или JS перед первым рендерингом, процесс приостанавливается, потому что браузеру необходимо выполнить эти файлы. Чтобы определить источники, потенциально блокирующие отображение на веб-странице, вы можете запустить тест на WebPageTest.
В режиме водопада вы увидите начальную строку рендеринга и все файлы, которые обрабатываются до и после первого рендеринга. Если что-то до рендеринга не используется или может быть отображено позже, лучше исправить это. Естественно, если код отвечает за первичное взаимодействие пользователя со страницей, трогать его не следует.
Что вы можете сделать для тех элементов, которые не нужно загружать сразу (например, кнопок социального обмена), так это сделать загрузку JavaScript асинхронной. Есть два атрибута, которые могут помочь распределить нагрузку скрипта, чтобы ресурсы стали доступны асинхронно: async и defer. Оба они сокращают время, необходимое браузеру для синтаксического анализа HTML, без ущерба для отображения на странице. Вы можете применить эти атрибуты к сторонним JS.
На визуальный контент в среднем приходится 21% веса страницы, поэтому оптимизация изображений и видео чрезвычайно важна. Здесь мы суммируем основные действия, которые вам нужно предпринять в отношении визуальных элементов, чтобы улучшить восприятие страницы:
• Используйте форматы файлов, доступные во всех браузерах. JPEG и PNG - наиболее распространенный выбор; WebP - многообещающий формат, но пока поддерживается не всеми браузерами; GIF-файлы могут быть приемлемыми, но если они весят слишком много, подумайте о преобразовании их в видеофайлы.
• Сжимайте изображения без значительной потери качества. Во многих CMS есть встроенные решения для сжатия изображений.
• Укажите несколько соотношений, чтобы изображения хорошо смотрелись на любом устройстве. Обратите внимание, что большинство популярных CMS сделают это за вас. • Если на странице много изображений, рассмотрите возможность их асинхронной загрузки, чтобы ускорить первый рендеринг. Для этой цели используются два метода отложенной загрузки и декодирования.
• Размещайте большие видеофайлы на сторонних сайтах, чтобы уменьшить нагрузку на ваш сайт.
Для начала надо получить получить общую картину того, насколько быстро сервер отвечает на страницах вашего веб-сайта:
Помимо того, что мы уже упоминали, есть ещё работы которые нужно сделать для оптимизации времени ответа сервера:
• возможности устройства и сети со стороны пользователя
• объем трафика веб-сайта
• ресурсы на каждой веб-странице
• выбранное решение для хостинга
• CMS и плагины<
То, как пользователи взаимодействуют с вашим сайтом, во многом зависит от того, какие устройства и какое соединение они используют. Например, "хождение" по веб-сайту со смартфона с ограниченными возможностями процессора и памяти - сложнее, чем с ПК со стабильным подключением.
Важно отслеживать, какие устройства распространены среди ваших пользователей, и проверять загрузку веб-сайта на этих устройствах.
Выполняя различные тесты производительности, вы можете моделировать более медленные соединения и менее мощные устройства.
Проверка в Яндекс метрика.
Что бы узнать в Яндекс метрика тип устройства с которых посещали ваш сайт, Сделайте следующее: Откройте Яндекс метрику ➣ Счетчики ➣ Выберите необходимый сайт ➣ пролистайте страницу вниз:
Использовать Google Аналитику: Откройте Google Аналитику ➣ Выберите необходимый сайт ➣ пролистайте страницу вниз:
Даже если вы сделаете все возможное, оптимизируя ресурсы на своем веб-сайте, дешевый общедоступный хостинг все равно не даёт нужной скорости загрузки и удобства использования.
На рынке хостинга есть много экономичных решений, но большинство из них не подходят для веб-сайтов, которые продают продукты или услуги, содержат много мультимедийного контента или нацелены на пользователей из разных стран.
Всегда лучше выбирать выделенный сервер, который не используется для других веб-сайтов. Если у вас ограниченный бюджет, но вы хотите перейти с общего хостинга, рекомендую выбрать виртуальный частный сервер (VPS), который имитирует выделенный сервер в среде общего хостинга.
Еще одна полезная вещь - использовать сеть распространения контента (CDN), которая распределяет нагрузку по разным центрам обработки данных, расположенным в разных местах. Это особенно полезно, когда ваш веб-сайт ориентирован на аудиторию из разных уголков мира.
С помощью кэширования вы можете указать серверу или браузеру сохранять ранее показанный контент, чтобы он не загружался каждый раз, когда пользователь возвращается на страницу.
Загрузка содержимого непосредственно из кеша сокращает ресурсы сервера и повышает производительность. Исследование показало, что кеширование на стороне сервера может сократить время загрузки более чем на 30%. Некоторые хостинг-провайдеры автоматически кэшируют статический контент, оптимизируя производительность сервера.
Каждое перенаправление на страницу замедляет процесс загрузки, поэтому вам нужно уменьшить их количество. Проверьте свои шаблоны перенаправления, чтобы убедиться, что нет избыточных перенаправлений, которые снижают время ответа сервера. Существует множество инструментов для проверки и отслеживания индивидуальных и массовых перенаправлений.
Плагины также значительно повышают скорость и производительность вашего сайта. Чтобы избежать негативных последствий, убедитесь, что вы используете обновлённые CMS и плагины самой последней версии на PHP. Чтобы определить плагины, которые потенциально могут замедлить работу вашего веб-сайта, используйте инструменты тестирования о среде и производительности плагина.
Давайте подытожим самые важные моменты об оптимизации скорости и производительности страниц, чтобы сделать ваш сайт привлекательным для пользователей и поисковых систем:
🚩 Медленная загрузка веб-сайта наносит ущерб вашим конверсиям, но вместо того, чтобы сосредоточиться на оптимизации скорости, вам необходимо анализировать и отслеживать ориентированные на пользователя показатели производительности, такие как сигналы взаимодействия с страницей. Они являются приоритетными для Google и будут иметь прямое влияние на рейтинг, начиная с нового обновления в мае 2021 года.
🚩 Хорошие показатели Core Web Vitals включают LCP в течение первых 2,5 секунд, FID менее 100 миллисекунд и CLS менее 0,1. Эти параметры оценивают, сколько времени нужно веб-странице, чтобы стать доступной и интерактивной для пользователей: речь идет не о быстрой загрузке всей страницы, а о быстрой визуализации содержимого в верхней части страницы. Измеряйте эти сигналы как в лабораторных условиях, так и с помощью реального пользовательского мониторинга.
🚩 Тестируя производительность вашего веб-сайта по параметрам восприятия страницы, вы будете знать, на чем следует сосредоточиться для повышения скорости. Уменьшение кода, оптимизация изображений и обновление хостинга серверов - вот основные вещи, которые требуется рассмотреть. Регулярно проводите аудит веб-сайта, чтобы убедиться, что ничто не мешает вашим веб-страницам быть быстрыми и полезными.
Все скриншоты сделаны автором, апрель 2021 год. Идея: seranking.com