Как оптимизировать свой сайт для показателей Google 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. Первая отрисовка содержимого (FCP): время, необходимое до того, как браузер отобразит первый пиксель содержимого.
11. Первая значимая отрисовка (FMP): время, которое проходит до того, как содержимое основной страницы становится видимым для пользователя.
12. Время до интерактивности (TTI): время, необходимое для того, чтобы страница стала полностью интерактивной и может надежно реагировать на ввод пользователя.
13. Первый простой ЦП: время, в течение которого ЦП обрабатывает страницу и запускает все сценарии инициализации, ожидая дальнейшего ввода.
14. Использование ЦП: обработка, необходимая при рендеринге страницы и ответ на ввод данных пользователем.
15. Макетов в секунду: скорость, с которой браузер должен пересчитывать стили и макеты страниц.

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

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

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

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

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

• Самая большая Contentful Paint (LCP): производительность загрузки
• Задержка первого входа (FID): интерактивность
• Cumulative Layout Shift (CLS): Показатели визуальной стабильности

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

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

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

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

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

(LCP)

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

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

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

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

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

Крупнейшие инструменты анализа содержательной краски

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

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

Создайте отчет «Эффективность мобильных устройств», а затем изучите полученный раздел » Эффективность» . Самое большое время Contentful Paint отображается с расширяемым разделом, который идентифицирует выбранный элемент:

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

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

PageSpeed ​​Insights Самый большой анализ.

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

Индикатор LCP панели DevTools Performance.

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

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

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

Google Search Console Core Web Vitals.

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

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

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

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

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

Распространенные причины плохих самых больших баллов за краску

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

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

Как улучшить самые LCP

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

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

Задержка первого входа (FID)

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

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

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

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

Инструменты анализа задержки первого входа

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

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

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

PageSpeed ​​Insights Общее время блокировки.

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

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

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

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

Распространенные причины плохих оценок задержки первого ввода

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

Устали от поддержки хостинга WordPress низкого уровня 1 без ответов? Попробуйте нашу службу поддержки мирового уровня! Ознакомьтесь с нашими планами

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

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

Как улучшить показатели задержки первого ввода

Аудит клиентского 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 в веб-воркере , который использует фоновый поток.

Накопительный сдвиг макета (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 рассчитываются с помощью панели DevTools Lighthouse , инструментов PageSpeed ​​Insights и web.dev Measure :

PageSpeed ​​Insights CLS.

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

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

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

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

Распространенные причины плохой совокупной оценки сдвига макета

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

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

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

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

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

Резюме

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

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

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

У вас есть другие советы по улучшению Core Web Vitals? Делитесь ими в комментариях!