core web vitals
Оптимизация

Как оптимизировать сайт для Core Web Vitals

Google стремится повысить производительность веб-сайтов с помощью Core Web Vitals. Почему? Поскольку бизнес Google преимущественно связан с Интернетом, медленные сайты и веб-приложения заставляют пользователей возвращаться к нативным приложениям.Как оптимизировать свой сайт для основных веб-показателей Google.

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

Эта статья покажет вам, как вы можете оптимизировать свой сайт для показателей Google Core Web Vitals.

Почему Core Web Vitals?

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

Помимо улучшенного рейтинга страниц, высокоэффективные сайты могут быть включены в карусель мобильного поиска. Ранее это было зарезервировано для ускоренных мобильных страниц (AMP), что требовало переноса контента на отдельный сайт, размещенный в Google. AMP вызывает много критики, тем более что страницы не всегда быстрее, чем хорошо оптимизированный WordPress или статичный сайт. Однако это уже не обязательное требование.

Независимо от того, что вы выбрали, чем быстрее и отзывчивее ваш сайт, тем больше у него шансов занять более высокое место в результатах поиска Google.

Если учесть, что средний размер страницы составляет около 2 МБ, выполняется более 60 HTTP-запросов, а для полного отображения на мобильном устройстве требуется 16 секунд, вы увидите, что есть возможности для улучшения вашего сайта. Мы покажем вам лучшие способы добиться этих улучшений.

Ключевые факторы ранжирования Google

Прежде чем приступить к оценке производительности, необходимо изучить четыре ключевых фактора ранжирования:

  1. HTTPS: HTTPS необходим. Устанавливает ли ваш сайт безопасное соединение между браузером пользователя и веб-сервером?
  2. Удобство для мобильных устройств: ваш сайт должен хорошо работать на мобильных устройствах. Можно ли использовать ваш сайт на устройствах с маленьким экраном? Отрисовывает ли он без переполнения содержимого? Текст достаточно крупный? Достаточно ли кликабельных областей для сенсорного управления?
  3. Никаких межстраничных объявлений. Избегайте навязчивых межстраничных объявлений, которые занимают слишком много места на экране. Всегда ли ваш контент читаем? Не скрыто ли оно частично всплывающими межстраничными объявлениями или баннерами? Ваши рекламные или маркетинговые акции затрудняют использование сайта?
  4. Безопасный просмотр: на вашем сайте не должно быть вредоносных программ, вирусов, фишинга и других видов мошенничества.

Как только вы выполните эти требования, производительность вашего сайта будет оценена.

Как Google оценивает эффективность веб-сайтов?

Очень важно, чтобы ваш сайт загружался быстро, быстро отображался и быстрее реагировал на запросы. Но почувствует ли эту скорость пользователь?

Приложения для измерения производительности, такие как браузерные DevTools, сообщают о технических измерениях, таких как:

  1. Время блокировки: время, затрачиваемое на ожидание начала загрузки, обычно потому, что другие активы, такие как таблицы стилей и скрипты, имеют более высокий приоритет.
  2. Разрешение DNS: время преобразования имени хоста в IP-адрес для извлечения актива.
  3. Время подключения: время инициализации TCP-соединения.
  4. Время до первого байта (TTFB): общее время между запросом и первым байтом ответа.
  5. Время получения: время получения всего актива.
  6. Время загрузки DOM: время загрузки и рендеринга объектной модели HTML-документа. Обычно это первая точка, в которой скрипты, анализирующие или изменяющие DOM, могут надежно работать.
  7. Время загрузки страницы: время загрузки страницы и всех ресурсов, таких как изображения, таблицы стилей, скрипты и т. д.
  8. Общий вес страницы: общий размер всех ресурсов. Часто сообщается как в сжатом (загружаемом) размере, так и в несжатом размере.
  9. Количество элементов DOM: общее количество элементов HTML на странице. Чем больше элементов, тем дольше обрабатывается страница.
  10. First Contentful Paint (FCP): время, необходимое для того, чтобы браузер отобразил первый пиксель контента.
  11. Первая осмысленная отрисовка (FMP): время, необходимое для того, чтобы содержимое основной страницы стало видимым для пользователя.
  12. Время до интерактивности (TTI): время, необходимое для того, чтобы страница стала полностью интерактивной и могла надежно реагировать на действия пользователя.
  13. Первый простой ЦП: время, в течение которого ЦП обрабатывает страницу и запускает все сценарии инициализации, ожидая дальнейших входных данных.
  14. Загрузка ЦП: активность обработки, необходимая при отображении страницы и ответе на ввод пользователя.
  15. Макетов в секунду: скорость, с которой браузер должен пересчитывать стили и макеты страниц.

Их можно использовать для определения конкретных узких мест, таких как нагрузка на сервер, кэширование CMS , кэширование браузера, скорость загрузки и эффективность JavaScript . Но они не могут определить, обеспечивает ли страница хорошее или плохое взаимодействие с пользователем. Например:

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

Core Web Vitals — это попытка Google решить эти дилеммы.

Что такое Core Web Vitals?

Google Core Web Vitals (CWV) — это три показателя производительности, которые оценивают реальный пользовательский опыт:

  • Largest Contentful Paint (LCP): производительность загрузки
  • First Input Delay (FID): интерактивность
  • Cumulative Layout Shift (CLS): производительность визуальной стабильности

Это новое обновление алгоритма Google начало развертываться по всему миру к концу августа 2021 года. Показатели Core Web Vitals в первую очередь влияют на результаты мобильного поиска, но в случае успеха эксперимента последуют эквиваленты для настольных компьютеров.

Оценки LCP, FID и CLS страницы основаны на реальных пользовательских показателях за последние 28 дней, собранных анонимно через браузер Chrome. Эти измерения могут различаться в зависимости от устройства пользователя, подключения и других одновременных действий, поэтому рассчитывается 75-й процентиль, а не среднее значение.

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

Любая страница, получившая хороший (зеленый) балл по всем трем показателям Core Web Vitals, получит более высокий рейтинг в результатах поиска и будет включена в карусель «Главные новости» в приложении Google News.

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

Largest Contentful Paint (LCP)

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

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

Любой из следующих элементов подходит для анализа Largest Contentful Paint:

  • изображения (img элемент)
  • изображения внутри векторной графики (image встроенные в svg)
  • миниатюры видео (атрибут плаката, установленный на URL-адрес изображения внутри video элемента)
  • background-image url() элементы с фоновыми изображениями (обычно загружаются с помощью свойства CSS )
  • блочные элементы, содержащие текст

Страницы, на которых самая крупная отрисовка содержимого выполняется в течение первых 2,5 секунд после загрузки страницы, считаются хорошими (зеленые). Страницы, длительность которых превышает 4,0 секунды, считаются плохими (красные):

Largest Contentful Paint (LCP)

Инструменты анализа Largest Contentful Paint

LCP — самая простая для понимания метрика Core Web Vital, но может быть неясно, какой элемент будет выбран для анализа.

Панель инструментов Lighthouse предоставляется в браузерах на основе Chromium, таких как Chrome, Edge, Brave , Opera и Vivaldi. Откройте DevTools из меню браузера — обычно это Дополнительные инструменты > Инструменты разработчика или сочетания клавиш Ctrl | Cmd + Shift + i или F12 — затем перейдите на вкладку Lighthouse (в старых версиях она может называться Audit).

Создайте отчет Mobile Performance, а затем просмотрите полученный раздел Performance. Максимальное время отрисовки содержимого отображается в раскрывающемся разделе, который определяет выбранный элемент:

Отчет о производительности мобильных устройств DevTools Lighthouse.

Вы можете получить идентичную информацию в онлайн-инструментах PageSpeed ​​Insights и web.dev Measure, если у вас нет доступа к браузеру на основе Chromium:

Анализ Largest Contentful Paint в PageSpeed ​​Insights

На панели производительности DevTools также отображается индикатор LCP. Чтобы начать, щелкните круглый значок Запись, перезагрузите страницу, затем нажмите кнопку Стоп, чтобы просмотреть отчет. Щелкните значок LCP в разделе Время, чтобы идентифицировать элемент и просмотреть сводку статистики.

Индикатор LCP панели производительности DevTools.

Расширение Web Vitals доступно для Google Chrome, но его можно установить в большинстве браузеров на основе Chromium. Он рассчитывает показатели Core Web Vitals для каждого посещаемого вами сайта, и его значок становится зеленым, оранжевым или красным в зависимости от результата. Вы также можете щелкнуть значок расширения, чтобы просмотреть дополнительные сведения о LCP:

Браузерное расширение Web Vitals LCP.

Консоль поиска Google теперь предлагает раздел Core Web Vitals, если ваш сайт добавлен как собственность . В отчете показано, как показатели CWV менялись с течением времени. Обратите внимание, что он не определяет конкретные показатели LCP, и доступны только сайты с достаточно высоким трафиком:

Основные веб-показатели Google Search Console.

Отчет о пользовательском опыте Chrome позволяет вам запрашивать реальную статистику использования, включая LCP в разных странах, соединениях и устройствах, для определенного URL-адреса. Это общедоступный проект в Google BigQuery, поэтому вы должны зарегистрировать учетную запись Google Cloud Platform и предоставить платежные данные. Опять же, отчет будет полезен только в том случае, если URL-адрес имеет достаточно высокий уровень трафика.

Наконец, JavaScript-библиотека web-vitals представляет собой небольшой скрипт размером 1 КБ, который может рассчитывать LCP и другие показатели Core Web Vital для реальных пользователей на вашем работающем сайте. Поскольку его можно загрузить из CDN, вы можете добавить следующий скрипт в свой HTML head:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->

getLCP() — это асинхронная функция, которой передается обратный вызов, запускаемый при вычислении значения LCP (хотя он может никогда не сработать, если страница загружается на фоновой вкладке). В функцию обратного вызова передается объект, содержащий:

  • name: название метрики (в данном случае LCP)
  • value: расчетное значение
  • id: уникальный идентификатор, представляющий эту метрику для текущей страницы.
  • delta: дельта между текущим значением и последним зарегистрированным значением
  • entries: массив записей, используемых при вычислении значения

Приведенный выше скрипт выводит объект в консоль, хотя практичнее отправлять данные на сервер или в Google Analytics для дальнейшего анализа.

Распространенные причины плохих оценок за LCP

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

  • Ответ сервера может быть медленным, потому что он перегружен или выполняет слишком много работы для отображения страницы. Это не обязательно может быть ошибкой вашего сайта — это может быть связано с ограничениями сервера, если вы используете услугу виртуального хостинга .
  • CSS и JavaScript, блокирующие рендеринг, могут задержать загрузку страницы, если на них есть ссылки в HTML над основным контентом.
  • Другие ресурсы, такие как большие изображения и видео, могут уменьшить доступную пропускную способность и занять больше времени для рендеринга.
  • Содержимое страницы, созданное на клиенте, а не на сервере, также появляется дольше.

Как улучшить Largest Contentful Paint

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

  1. Обновите свой сервер и/или хостинг. Убедитесь, что скорость загрузки остается высокой даже во время интенсивного использования.
  2. Активируйте сжатие сервера и HTTP/2+. Нет причин не делать этого!
  3. Уменьшите нагрузку на сервер. Удалите неиспользуемый код и плагины CMS, а затем включите эффективное кэширование .
  4. Убедитесь, что браузер может эффективно кэшировать файлы. Установите соответствующие хэши Expires, Last-Modified и/или ETag в заголовке HTTP, чтобы файлы больше не запрашивались.
  5. Используйте сеть доставки контента (CDN), чтобы разделить нагрузку и разместить активы на серверах, географически расположенных ближе к пользователям.
  6. Повысьте общую оптимизацию, используя функцию минимизации кода.
  7. Оптимизируйте свои изображения. Уменьшите их до наименьших размеров и используйте соответствующий формат, чтобы уменьшить размер файлов. Убедитесь, что любое изображение в самом большом блоке контента запрашивается как можно раньше; предварительная загрузка может помочь.
  8. Ленивая загрузка изображений путем добавления loading="lazy" атрибута. Добавьте атрибуты ширины и высоты, чтобы обеспечить резервирование соответствующего места на странице до того, как изображение завершит загрузку.
  9. Сведите к минимуму сторонние запросы и рассмотрите возможность перемещения ресурсов в основной домен, чтобы избежать посторонних запросов DNS.
  10. Сведите к минимуму количество и размер запрашиваемых файлов, особенно в верхней части вашего HTML-кода.
  11. Убедитесь, что вы загружаете только необходимые веб-шрифты. Переключитесь на безопасные веб-шрифты для максимальной производительности.
  12. Удалите неиспользуемые файлы JavaScript и CSS.
  13. Объедините и минимизируйте файлы JavaScript и CSS.
  14. Избегайте операторов CSS @import — они блокируют рендеринг и загружают стили последовательно.
  15. Избегайте кодировки Base64 — она увеличивает размер файла и требует дополнительной обработки.
  16. Рассмотрите критический встроенный CSS. Вставьте необходимый CSS-код «вверху» в верхней части страницы, а затем асинхронно загрузите дополнительные таблицы стилей.
  17. Используйте асинхронный, отложенный или модуль ES JavaScript для отложенного запуска скриптов. Выполнение длительных процессов JavaScript в сервис-воркере.

First Input Delay (FID)

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

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

Страницы со временем FID 100 миллисекунд или меньше считаются хорошими (зеленые). Страницы длительностью более 300 миллисекунд считаются плохими (красный):

Задержка первого ввода.

Инструменты анализа First Input Delay

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

FID не рассчитывается в панели DevTools Lighthouse или PageSpeed ​​Insights. Однако они могут определить общее время блокировки (TBT). Это разумное приближение для первой задержки на входе. Он измеряет разницу во времени между:

  1. Первой отрисовкой содержимого (FCP) или временем, когда содержимое страницы начинает отображаться, и
  2. Временем до интерактивности (TTI) или временем, в течении которого страница может реагировать на ввод пользователя. TTI предполагается, когда нет активных длительных задач и нужно выполнить менее трех HTTP-запросов.
Инструменты анализа задержки первого ввода в  PageSpeed ​​Insights

Расширение Web Vitals для Google Chrome также может отображать метрику FID после взаимодействия со страницей путем прокрутки или щелчка. Щелкните значок расширения, чтобы открыть дополнительную информацию:

Расширение Web Vitals FID.

Как и LCP , отчет о пользовательском опыте Chrome позволяет вам запрашивать реальную статистику FID, записанную в разных странах, соединениях и устройствах для определенного URL-адреса.

Библиотека JavaScript web-vitals также может рассчитывать показатели FID для реальных пользователей на вашем работающем сайте. Вы можете добавить следующий скрипт в свой HTML для вывода метрик FID в функцию обратного вызова:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->

Распространенные причины плохих показателей FID

Плохие оценки FID и TBT обычно вызваны кодом на стороне клиента, который загружает процессор, например:

  • Значительное количество блокирующих рендеринг CSS и JavaScript, которые останавливают загрузку страницы, пока код загружается и анализируется.
  • Большие ресурсоемкие сценарии, которые запускаются сразу после загрузки страницы.
  • Долго выполняющиеся или плохо оптимизированные задачи JavaScript.

По умолчанию браузеры работают в одном потоке, который может обрабатывать только одну задачу за раз. Если для выполнения функции JavaScript требуется одна секунда, все остальные процессы рендеринга блокируются в течение этой секунды. Страница не может реагировать на действия пользователя, обновлять модель DOM, показывать анимацию и т. д. Даже GIF-анимации могут быть заблокированы в старых браузерах.

Как улучшить показатели First Input Delay

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

Следующие советы помогут получить более здоровую оценку FID:

  1. Создавайте и кэшируйте на сервере как можно больше статического HTML-контента. Старайтесь не полагаться на фреймворки JavaScript на стороне клиента для отображения одного и того же HTML для всех.
  2. Убедитесь, что браузер может эффективно кэшировать файлы. Установите соответствующие хэши Expires, Last-Modified и/или ETag в заголовке HTTP, чтобы файлы больше не запрашивались.
  3. Используйте методы прогрессивного улучшения, чтобы интерфейс можно было использовать в HTML и CSS до запуска JavaScript.
  4. Удалите неиспользуемые файлы JavaScript и CSS.
  5. Объедините и минимизируйте файлы JavaScript и CSS.
  6. Избегайте чрезмерного использования затратных свойств CSS, таких как box-shadow и filter.
  7. Используйте асинхронный, отложенный или модуль ES JavaScript для отложенного запуска скриптов.
  8. Минимизируйте сторонние запросы JavaScript для аналитики, виджетов социальных сетей, дискуссионных форумов и т. д. Они могут быстро увеличиться до нескольких мегабайт JavaScript.
  9. Отложенная загрузка компонентов JavaScript по требованию, например, виджеты чата, видеоплееры и т. д.
  10. Задержка загрузки менее важных сценариев, таких как аналитика, реклама и инструменты социальных сетей.
  11. Разбейте длительные задачи JavaScript на серию небольших заданий, которые выполняются после короткой задержки requestIdleCallback, setTimeout или requestAnimationFrame .
  12. Рассмотрите возможность выполнения длительных процессов JavaScript в веб-воркере, который использует фоновый поток.

Cumulative Layout Shift (CLS)

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

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

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

Совокупные баллы за смещение макета рассчитываются путем умножения следующих показателей:

  • Доля удара: это общая площадь всех нестабильных элементов в окне просмотра, т.е. тех, которые будут «прыгать». Если элементы, покрывающие 60% области просмотра, смещаются во время загрузки страницы, коэффициент воздействия равен 0,6. Обратите внимание, что элементы, вызвавшие это смещение, такие как изображение или реклама, считаются стабильными, поскольку они не обязательно перемещаются после рендеринга.
  • Доля расстояния: это наибольшее расстояние, на которое перемещается любой отдельный нестабильный элемент в окне просмотра. Если наибольшее смещение происходит на элементе, который перемещается от 0,100 до 0,800, он сместился на 700 пикселей по вертикали. Если окно просмотра устройства имеет высоту 1000 пикселей, доля расстояния составляет 700 пикселей / 1000 пикселей = 0,7. Таким образом, расчетный показатель кумулятивного смещения макета составляет 0,6 x 0,7 = 0,42.

Компания Google внесла изменения в показатель CLS, чтобы учесть следующие ситуации:

  • Сдвиги макета сгруппированы в «сеансы», которые длятся пять секунд, но закрываются через одну секунду, если дальнейшие сдвиги макета не происходят. Если в течение одной секунды происходит два или более сдвигов, их баллы суммируются.
  • Сдвиги макета не записываются в течение 500 мс после взаимодействия с пользователем, например клика. В некоторых случаях это вызывает обновления DOM (например, открытие меню, отображение сообщения об ошибке, отображение модального диалогового окна и т. д.).
  • Одностраничные приложения, которые остаются открытыми в течение более продолжительных периодов и выполняют многочисленные обновления DOM, не подвергаются неблагоприятному воздействию.

Страницы с показателем CLS 0,1 или ниже считаются хорошими (зелеными). Страницы, превышающие 0,25, считаются плохими (красными):

Совокупный сдвиг макета (CLS)

Инструменты анализа совокупного сдвига макета (CLS)

Метрики CLS рассчитываются в панели DevTools Lighthouse, PageSpeed ​​Insights и инструментах web.dev Measure:

Анализ совокупного сдвига макета (CLS) в PageSpeed ​​Insights.

Расширение Web Vitals для Google Chrome также показывает метрику CLS:

Анализ CLS с помощью расширения Web Vitals для Chrome.

Как и LCP и FID, отчет о пользовательском опыте Chrome позволяет вам запрашивать реальную статистику CLS, записанную в разных странах, соединениях и устройствах для определенного URL-адреса.

Библиотека JavaScript web-vitals также может рассчитывать показатели CLS для реальных пользователей на вашем активном сайте, как это делается с LCP и FID. В ваш HTML можно добавить следующий скрипт для вывода метрик CLS в функцию обратного вызова:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->

Распространенные причины плохих оценок CLS

Плохие оценки CLS обычно вызваны медленной загрузкой ресурсов страницы и динамическими или неразмерными элементами DOM:

  • Место на странице не резервируется для изображений, фреймов, рекламы и т. д.
  • Контент динамически внедряется в DOM, как правило, после сетевого запроса рекламы, виджетов социальных сетей и т. д.
  • Загрузка веб-шрифта вызывает заметное мигание невидимого текста (FOIT) или мигание нестилизованного текста (FOUT).

Как улучшить оценку Cumulative Layout Shift

Аудит на стороне клиента может выявить проблемы, но обычно это вопрос обеспечения того, чтобы место было зарезервировано для содержимого до его загрузки. Советы по оптимизации сервера, предложенные для Largest Contentful Paint, будут иметь некоторую пользу, но возможны дальнейшие улучшения:

  1. Добавьте атрибуты ширины и высоты в HTML img и iframe теги или используйте новое свойство CSS-соотношение сторон, чтобы убедиться, что на странице зарезервировано соответствующее пространство перед загрузкой ресурсов.
  2. Установите соответствующие размеры для элементов-контейнеров, содержащих более медленно загружаемый сторонний контент, например рекламу и виджеты.
  3. Убедитесь, что изображения и другие ресурсы, отображаемые в верхней части страницы, запрашиваются как можно раньше — предварительная загрузка может оказаться полезной.
  4. Сведите к минимуму использование веб-шрифтов и по возможности рассмотрите возможность использования общедоступных шрифтов ОС.
  5. Загрузите веб-шрифты и установите CSS-шрифт-отображение как необязательный или своп. Убедитесь, что вы используете резервный шрифт аналогичного размера, чтобы свести к минимуму сдвиг макета.
  6. Избегайте вставки элементов вверху страницы, если только они не реагируют на действие пользователя, например на щелчок.
  7. Убедитесь, что взаимодействие с пользователем завершается в течение 500 миллисекунд после срабатывания триггера ввода.
  8. Используйте CSS-преобразование и непрозрачность для более эффективной анимации, которая не требует повторного макета.
  9. Рассмотрите критический встроенный CSS. Вставьте необходимый CSS-код «в верхней части страницы» в блок в верхней части страницы, а затем асинхронно загрузите дополнительные таблицы стилей.
  10. При необходимости рассмотрите сдерживание , новую функцию CSS, которая позволяет вам идентифицировать изолированные поддеревья страницы. Браузер может оптимизировать обработку, отображая или не отображая определенные блоки содержимого DOM.

Резюме

Разработчики не всегда стремятся плясать под дудку Google. Компания обладает значительной властью, и незначительные обновления поисковых систем могут отрицательно сказаться на производительности и прибыльности интернет-организаций.

Тем не менее, Core Web Vitals использует подход «пряника», а не «кнута». У хорошо оптимизированных, удобных сайтов, которые отказываются от темных шаблонов, больше шансов на успех, чем у раздутых сайтов с большим количеством всплывающих окон, плохо адаптированных для мобильных устройств.

Core Web Vitals предоставляет измеримый способ оценки пользовательского опыта, чтобы помочь вам сосредоточиться на наиболее важных улучшениях. Изменения в CWV могут не увеличить доходы, но ваши пользователи станут намного лояльнее.

Есть ли у вас какие-либо другие советы по улучшению Core Web Vitals? Поделитесь ими в разделе комментариев!

Источник: kinsta.com

Вконтакте
Linkedin
Telegram
Whatsapp

Похожие статьи

Исправляем проблемы с CLS (Cumulative Layout Shift)


Нововведение Google, Core Web Vitals, поглотило мир SEO и веб-разработки, и многие сайты заняты оптимизацией своего Page Experience, чтобы повысить фактор ранжирования. Метрика Cumulative Layout Shift доставляет проблемы многим сайтам, поэтому давайте рассмотрим способы решения любых проблем с данной метрикой


Как улучшить атрибуты адаптивного изображения (sizes и srcset) в WordPress


Атрибуты адаптивного изображения (sizes и srcset) в ядре WordPress появились в версии 4.4. В этой статье мы рассмотрим, как их можно улучшить, а также добавить другие атрибуты. Изображения будут получать эти два атрибута (sizes и srcset) только в том случае, если HTML-код изображения будет получен с помощью функции wp_get_attachment_image


У этой статьи пока нет комментариев


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


Ваш адрес email не будет опубликован.

семнадцать + 16 =