Распространенные проблемы основных веб-показателей в WordPress и способы их устранения

Пытаетесь пройти Core Web Vitals?

По данным Google:

55,4% всех веб-сайтов с данными CrUX не соответствуют хорошему порогу по всем трем показателям — LCP, FID и CLS.

Однако прохождение оценки CWV ни в коем случае не является невыполнимой миссией.

Фактически это трехэтапный процесс:

• Запустите тесты производительности
• Выявление проблем Core Web Vitals
• Оптимизируйте их

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

Так что читайте дальше!

Краткий обзор основных веб-показателей

Возможно, вы наткнулись на это заявление Google:

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

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

Еще в 2020 году Google представил Core Web Vitals, чтобы предоставить владельцам веб-сайтов окончательный набор тестов, которые напрямую влияют на пользовательский опыт и определяют его. Они были объявлены как часть более широкой инициативы Google, направленной на то, чтобы сделать упор на показатели, ориентированные на пользователя, при оценке общего состояния сети.

По своей сути (каламбур) CWV представляет собой набор показателей производительности, которые проливают свет на качество взаимодействия с пользователем на веб-странице. Они включают в себя три основных элемента:

• Производительность загрузки (LCP)
• Интерактивность (FID)
• Визуальная стабильность (CLS)

LCP, или Largest Contentful Paint, измеряет скорость загрузки страницы. Он измеряет время, необходимое для загрузки основного содержимого страницы. Оптимальным LCP считается время менее 2,5 секунд.

FID, или задержка первого ввода, оценивает интерактивность и скорость реагирования сайта. Он измеряет время с момента первого взаимодействия пользователя с вашей страницей (например, нажатия кнопки) до момента, когда браузер начинает обрабатывать это взаимодействие. Хороший показатель FID — это значение ниже 100 миллисекунд.

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

Есть также четвертый показатель, который заменит FID в марте 2024 года — «Взаимодействие с следующей отрисовкой» (INP).

INP записывает задержку всех взаимодействий на протяжении всего жизненного цикла страницы. Затем самая длинная задержка из всех взаимодействий записывается как INP страницы.

Причина, по которой INP заменит FID, заключается в том, чтопервый представляет более комплексный способ оценки отзывчивости страницы , измеряя все взаимодействия.Напротив, FID учитывает только первый из них. Хороший показатель INP — это значение ниже 200 миллисекунд.

Хотя INP напрямую не влияет на вашу оценку Core Web Vitals (на данный момент), Google уже начал отмечать проблемы INP через Search Console.

Изучите лучшие методы оптимизации вашего показателя INP от Google. Зарегистрируйтесь на наш эксклюзивный вебинар →

Прохождение основных веб-показателей: 75-й процентиль

Обсуждая показатели Core Web Vitals, Google часто ссылается на 75-й процентиль.

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

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

Инструменты для выявления основных проблем Web Vitals

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

Есть несколько популярных инструментов, которые вы можете использовать на этом пути:

1. Статистика PageSpeed

Google PageSpeed ​​Insights предлагает данные CWV как по конкретной странице, так и по всему источнику за последние 28 дней. Он также дает практические советы по повышению производительности.

Это один из наиболее широко используемых инструментов повышения производительности благодаря дружественному UX/UI. Страница отчета включает оценку основных веб-показателей на основе полевых данных и оценку производительности на основе лабораторных данных.

А внизу расположены виджеты «Возможности и диагностика», которые предоставляют список проблем и соответствующие показатели, на которые они влияют.

2. Консоль поиска Google

Отчет «Основные веб-показатели» в Search Console включает данные по эффективности для отдельных URL-адресов. Это делает его отличным вариантом для выявления конкретных страниц, нуждающихся в улучшении. В отличие от PageSpeed ​​Insights, отчеты Search Console включают исторические данные о производительности.

Следовательно, вы можете отслеживать, насколько эффективны ваши оптимизации и движетесь ли вы в правильном направлении.

Отчет об опыте использования Chrome (CrUX)

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

Вы можете подключиться к набору данных CrUX двумя основными способами:

• API отчетов Chrome UX — идеально подходит для тех, кто знаком с JavaScript и JSON;
• BigQuery — подходит для тех, у кого есть проект Google Cloud и знание SQL.

Хотя эти методы требуют больше усилий, чем быстрая проверка PageSpeed ​​Insights или GSC, они предоставляют универсальные возможности анализа и визуализации данных. Например, BigQuery позволяет сегментировать данные и интегрировать их с другими наборами данных.

Посмотрите свои результаты CWV до и после с помощью NitroPack. Проверьте свой сайт бесплатно →

Наиболее распространенные проблемы с основными веб-жизненными показателями в WordPress

Крупнейшие проблемы с отрисовкой содержимого (LCP)

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

Любая задержка в получении исходного HTML-документа с сервера может привести к тому, что метрика LCP окажется в неблагоприятном диапазоне.

И вот основные виновники:

1. Медленное время ответа сервера из-за бюджетного хостинга.

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

Когда время ответа сервера запаздывает, загрузка элементов LCP следует этому примеру, создавая каскадный эффект задержки рендеринга контента.

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

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

А поскольку такие ресурсы, как ЦП и ОЗУ, распределены между несколькими веб-сайтами на общем хостинге, ваш сайт WordPress не всегда может получать ресурсы, необходимые для эффективной загрузки.

2. Блокирующий рендеринг JavaScript и CSS, представленный некоторыми темами и плагинами.

Ресурсы, блокирующие рендеринг, — это скрипты и таблицы стилей, которые действуют как блокпосты, останавливая рендеринг веб-страницы до тех пор, пока она не будет полностью обработана.

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

Итак, когда дело доходит до вашего сайта WordPress, меньше значит лучше.

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

3. Неоптимизированные изображения

По данным Веб-альманаха:

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

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

Проблемы с накопительным сдвигом макета (CLS)

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

Вот причины, из-за которых содержимое вашей страницы подпрыгивает вверх и вниз:

1. Изображения вставлены без заданного размера.

Одной из деталей, которую часто упускают из виду при веб-разработке, является указание размеров изображения.

Определение атрибутовширины и высотыдля изображений — это не только эстетическая точность; это практическая мера для поддержания стабильности макета.

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

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

2. Размещение рекламы без зарезервированного места.

Добавляете ли вы динамические элементы, такие как реклама, видео или другой встроенный контент?

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

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

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

3. Неоптимизированная доставка шрифтов.

В стремлении к единообразию бренда и привлекательному дизайну пользовательские шрифты стали основным продуктом веб-дизайна.

Но они создают проблемы, а именно FOIT (Flash of Invisible Text) и FOUT (Flash of Unstyled Text).

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

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

Проблемы с задержкой первого ввода (FID)

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

Вот ресурсы, которые чаще всего блокируют основной поток:

1. Тяжелое выполнение JavaScript

Интенсивное выполнение JavaScript может существенно повлиять на FID на веб-сайтах, в первую очередь из-за однопоточной природы JavaScript.

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

2. Плохая приоритезация ресурсов

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

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

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

3. Запуск чрезмерного количества сторонних скриптов.

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

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

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

Проблемы взаимодействия со следующей отрисовкой (INP)

Учитывая, что INP заменит FID в следующем году, неудивительно, что факторы, которые негативно влияют на текущий показатель оперативности, также повлияют на предстоящий.

Другими словами, блокировка основного потока длинными задачами из-за выполнения неоптимизированных файлов JavaScript также приведет к плохой оценке INP.

Но есть еще одна вещь:

1. Большой размер DOM

Объектная модель документа (DOM) является основой каждой веб-страницы, представляя HTML-документ в виде структурированного дерева. Каждая ветвь этого дерева завершается узлом, в котором размещаются различные объекты. Эти узлы могут отображать различные сегменты документа, например элементы, текстовое содержимое или комментарии.

Хотя DOM имеет основополагающее значение для функционирования веб-страницы, его размер может привести к проблемам с реагированием, потому что:

Чем больше DOM, тем выше потребность браузера в быстром и эффективном отображении страницы.

Проще говоря:

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

Вы можете поразмышлять над определением «необходимого». Согласно критериям Lighthouse, размер DOM считается обременительным, если он превышает1400 узлов.

Присоединяйтесь к 45% веб-сайтов, прошедших основные веб-показатели. Установите NitroPack сегодня →

Как исправить основные проблемы Web Vitals в WordPress (контрольный список)

Оптимизация LCP

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

• Обновите свой хостинг . Рассмотрите возможность отказа от общего хостинга.Хотя он экономически эффективен, он может быть медленнее, чем более дорогие варианты — выделенный или облачный хостинг. Варианты хостинга премиум-класса, как правило, обеспечивают более быстрое время ответа.
  
• Используйтесеть доставки контента (CDN): CDN хранят кэшированные версии вашего сайта на нескольких серверах, расположенных по всему миру. Это гарантирует, что пользователи получают данные с ближайшего сервера, сокращая время, необходимое для получения данных.
  
• Оптимизация баз данных . Сюда входит удаление устаревших данных, оптимизация запросов и эффективное использование индексов. Для веб-сайтов на WordPress такие плагины, как WP-Optimize, могут помочь в обслуживании базы данных.
  
• Выберите правильный формат изображения : выберите наиболее эффективный формат для ваших изображений. Хотя JPEG идеально подходит для фотографий, PNG лучше подходит для изображений с прозрачностью. Современные форматы, такие как WebP, могут предлагать высококачественные визуальные эффекты при меньшем размере файлов.
  
• Применить сжатие . Используйте сжатие с потерями, чтобы уменьшить размер файла без значительного визуального ухудшения. Используйте сжатие без потерь, чтобы сохранить каждую деталь изображений, где качество имеет первостепенное значение.
  
• Изменение размера изображений. Предоставляйте изображения, адаптированные для устройства и области просмотра. Избегайте использования больших изображений, размер которых затем изменяется с помощью CSS или в браузере. Создавайте изображения разных размеров для разных разрешений экрана и обслуживайте их с помощью атрибута «srcset». Или попробуйте плагин вроде NitroPack, который автоматически изменяет размер ваших изображений.
  
• Минимизируйте файлы JS и CSS . Уменьшите размер ваших скриптов и таблиц стилей, удалив ненужные символы, пробелы и код. В этом могут помочь такие инструменты, как Terser (для JS) и CSSNano (для CSS).
  
• Используйте defer или async. Используйте атрибут defer для сценариев, которые не требуются для отрисовки начальной страницы. Это гарантирует, что файлы JS будут выполняться по порядку после анализа HTML. Используйте атрибут async для сценариев, которые не зависят от других сценариев и не имеют решающего значения для первоначального рендеринга. Это позволяет браузеру продолжать анализ страницы во время загрузки скрипта.
  
• Встроенныйкритический CSS: определите минимально необходимый CSS для рендеринга начальной страницы и встройте его непосредственно в HTML. Это гарантирует, что стили, необходимые для содержимого над сгибом, будут доступны немедленно.
  

Улучшение ПИД

Чтобы гарантировать плавное и быстрое реагирование страницы, выполните следующие оптимизации:

• Используйте веб-воркеров : перенесите сложные вычисления на веб-воркеров. Они запускают JavaScript в фоновом режиме в отдельном потоке, гарантируя, что основной поток остается отзывчивым.
  
• Расставьте приоритеты для критического JS : в первую очередь установите приоритет загрузки и выполнения наиболее важного кода JS. Используйте rel="preload", чтобы сообщить браузеру о сценариях с высоким приоритетом.
  
• Уменьшите количество неиспользуемого CSS . Хотя JavaScript обычно является главным злодеем, CSS также блокирует основной поток. Уменьшая неиспользуемый CSS, вы уменьшаете общее количество байтов, которые необходимо загрузить. Что еще более важно, вы гарантируете, что браузеры смогут начать отображать страницу быстрее, поскольку им придется выполнять меньше операций.
  
• Разбивайте длинные задачи. Разделите длинные задачи на более мелкие асинхронные фрагменты, используя такие методы, как requestIdleCallback(). Это гарантирует, что основной поток будет чаще оставаться свободным для ввода данных пользователем.
  
• Оптимизируйте прослушиватели событий. Если у вас много прослушивателей событий на нескольких элементах, рассмотрите возможность делегирования событий. Этот метод присоединяет один прослушиватель событий к общему родительскому элементу, сокращая количество прослушивателей и повышая производительность.
  

Сокращение CLS

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

• Определите размеры изображений, рекламы и встраивания. Всегда включайте атрибуты ширины и высоты для своих изображений. Это помогает браузеру выделить правильное количество места для изображения перед его загрузкой.
  
• Используйте Font-Display: Необязательно: Использование Font-Display: Необязательно в сочетании со ссылкой rel=preload для самых важных шрифтов считается лучшей общей стратегией использования шрифтов для хорошего CLS. Необязательное значение не приведет к изменению макета, когда веб-шрифт будет готов. В то же время предварительно загруженный шрифт, скорее всего, будет соответствовать первой отрисовке, гарантируя отсутствие изменений макета.
  
• Зарезервируйте место для динамического контента . Всегда заранее выделяйте подходящее пространство для динамически загружаемого контента, например рекламы или iframe. Это предотвратит перемещение контента по другим элементам при загрузке.
  

Прохождение ИЯФ

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

• Уменьшите размер DOM. Чтобы уменьшить глубину DOM вашего сайта, избегайте плохо закодированных плагинов и тем, не скрывайте нежелательные элементы с помощью display:none, отходите от конструкторов страниц, которые раздувают ваш код, и минимизируйте узлы DOM на основе JavaScript.
  
• Избегайте повторяющихся таймеров: setTimeout и setInterval — это часто используемые функции таймера JavaScript, которые могут способствовать задержке ввода. Если у вас есть контроль над таймерами в вашем коде, оцените их необходимость и максимально уменьшите их рабочую нагрузку.

Заворачивать

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

Действительно ли мне нужно пройти оценку Core Web Vitals? Они настолько впечатляющие?

И правда в том, что дело не в самих показателях.

Да, провести тест PSI и увидеть все зеленым цветом — это всегда приятно. И да, они являются частью факторов ранжирования Google, так что вы можете увидеть повышение своей позиции в поисковой выдаче.

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

И это приводит к реальным результатам, таким как:

• Повышенный коэффициент конверсии
• Уменьшить показатель отказов
• Наличие веб-сайта, который пользователи любят посещать

Итак, возвращаясь к вопросам, мы бы сказали, что сдача основных веб-показателей имеет решающее значение.

Но мы также согласимся, что справиться со всеми оптимизациями непросто.

Вот почему мы создали NitroPack.

NitroPack — это легкое решение для повышения производительности в Интернете, которое обеспечивает работуболее 180 000 веб-сайтов по всему миру , позволяя им достигать отличных основных веб-показателей, показателей производительности и удобства взаимодействия с пользователем.

Благодаря более чем 35 встроенным функциям оптимизации скорости страницы NitroPack является лидером в оптимизации Core Web Vitals:

И самое приятное то, что вы можете настроить NitroPack за 3 минуты. Никаких технических навыков или кодирования не требуется. Просто установите плагин, подключите его к своему веб-сайту и наблюдайте, как устраняются проблемы с производительностью.

Протестируйте NitroPack БЕСПЛАТНО →