First contentful paint 3g как исправить

В начале 2019 года Google объявил, что будет оценивать рейтинг скорости веб-сайта, сосредоточив внимание на двух показателях производительности: First Contentful Paint (FCP) и First Input Delay (FID) .

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

Проверка скорости вашего сайта с помощью PageSpeed ​​Insights выдаст примерно следующие результаты:

Новая панель управления отчетом о скорости в Google Search Console также использует показатели FCP и FID для оценки URL-адресов. Это все еще рекламируется как экспериментальная функция (пока).

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

First Contentful Paint дает более реалистичную метрику пользовательского опыта. Ваш веб-сайт может загружаться менее 2 секунд в тесте скорости, но если это не так для большинства вашей аудитории, Google все равно будет наказывать вас.

Из этой статьи вы узнаете, что такое FCP и почему это важно. Далее мы перейдем к различным способам улучшения FCP на вашем сайте WordPress.

ЧТО ТАКОЕ FIRST CONTENTFUL PAINT (FCP)?

First Contentful Paint (FCP) — это ориентированная на пользователя метрика для измерения воспринимаемой скорости загрузки страницы. FCP измеряет, как пользователи воспринимают производительность веб-сайта, а не то, что измеряет инструмент для проверки скорости.

Первая Contentful Paint отличается от First Paint, которая представляет собой точку на временной шкале загрузки страницы, где в браузере обнаруживается любой тип визуализации. С другой стороны, FCP требует отрисовки некоторого контента. Это может быть текст, изображения (включая фоновые изображения, логотипы) или небелые элементы <canvas>.

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

КАК ИЗМЕРИТЬ FCP?

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

• Маяк
• WebPageTest
• Chrome DevTools
• PageSpeed ​​Insights
• Отчет об удобстве использования Chrome
• Мониторинг производительности Firebase (бета)

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

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

ЧТО ТАКОЕ ХОРОШИЙ РЕЗУЛЬТАТ FCP?

Согласно Google, FCP должен произойти в течение 1 секунды . Это обеспечивает удобный пользовательский интерфейс для посетителей вашего сайта.

Если FCP вашего сайта занимает более 3 секунд, это считается медленным. Согласно исследованиям , более 53% мобильных пользователей покидают сайт, если загрузка занимает более 3 секунд. Отнеситесь к этому показателю серьезно.

Теперь, когда мы разобрались, что такое FCP и почему это важно, вот несколько способов улучшить FCP вашего сайта WordPress:

1. Уменьшите время отклика сервера (TTFB)

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

FCP зависит не только от TTFB, но это первый шаг к достижению этой цели.

FCP = TTFB + время загрузки контента + время рендеринга

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

Выберите провайдера быстрого хостинга

Вы можете обратиться к статье WP Rocket о веб-хостинге, чтобы узнать, какие факторы необходимо учитывать, чтобы выбрать отличное решение для веб-хостинга. В идеале выберите хост с серверами, расположенными близко к вашим пользователям.

Используйте качественный CDN

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

Включите кеширование для своего веб-сайта

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

2. Устранение ресурсов, блокирующих рендеринг

Веб-страница отображается браузером после объединения многих элементов, таких как HTML, таблицы стилей CSS, сценарии JavaScript и импорт HTML.

Сам документ HTML включает в себя различные теги, но все они быстро анализируются большинством браузеров. Но это не относится к синтаксическому анализу CSS и JS.

Обычно браузер пытается сначала загрузить все элементы веб-страницы, проанализировать их все, а затем отобразить веб-страницу. Чаще всего размер HTML-документов намного меньше, чем у таблиц стилей CSS и сценариев JS. Количество ресурсов CSS и JS также обычно выше.

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

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

Встроенные критические ресурсы

Во-первых, определите важные сценарии и стили, которые необходимы для отображения FCP вашей веб-страницы. Вот простое руководство от Google о том, как определять важные ресурсы.

После того, как вы определили критические сценарии, вам необходимо удалить их из ресурса, блокирующего рендеринг, а затем встроить их в свою HTML-страницу с помощью тегов <script> и <style> .

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

Отложить некритические ресурсы

Для некритических ресурсов вам необходимо пометить URL-адреса атрибутами async или defer .

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

Вот как можно отложить файл сценария:

<script defer src="https://v3b4d4f5.rocketcdn.me/path/to/file/script.js">
</script>

Для некритических таблиц стилей рекомендуется добавить к их URL-адресу атрибут async . Это указывает браузеру загружать стили асинхронно, в то время как остальные элементы страницы продолжают загружаться без прерывания.
Поскольку таблицы стилей загружаются с тегом <link> , нет прямого способа применить к ним атрибут async . Но есть обходной путь, и вот как вы можете его реализовать:

<!-- Setting “media” type as ‘print’ forces the browser to load the stylesheet asynchronously. On full page load, the media type is changed to ‘all’ so that the stylesheet gets applied. -->
 <link rel="stylesheet" href="style.css" media="print" onload="this.media='all'">

 <!-- Fallback for when JavaScript is disabled, but in this case CSS can’t be loaded asynchronously. -->
 <noscript><link rel="stylesheet" href="style.css"></noscript>

Удалить все неиспользуемое

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

Если вам неудобно работать с кодом, вы можете использовать такой плагин, как WP Rocket, чтобы отложить некритические файлы JavaScript всего за несколько кликов.

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

3. Создайте CSS Critical Path и встроите его.

Если вы настроили асинхронную загрузку CSS, браузер будет показывать пользователям нестилизованный контент до загрузки требуемых стилей. Такое поведение известно как Flash of Unstyled Content (FOUC) и доставляет неудобства пользователям.

Чтобы предотвратить FOUC, вам необходимо сгенерировать CSS Critical Path и встроить его прямо в свой HTML-файл.

Но что такое Critical Path CSS?

Critical Path CSS — это минимальный набор CSS, необходимый для отображения первой части веб-страницы (в верхней части страницы) для пользователя.

Анализировать критический путь рендеринга браузера вручную и затем создавать CSS критического пути — утомительный процесс. Это выходит за рамки данной статьи.

Однако вы можете использовать бесплатные онлайн-инструменты, такие как Pegasaas, для создания CSS Critical Path. Он отлично работает для большинства случаев использования. Ознакомьтесь с Google Анализируя критическую производительность пути рендеринга, чтобы узнать больше.

После того, как вы сгенерировали CSS Critical Path, вам необходимо встроить его в HTML-документ. Теперь браузер может немедленно отобразить первую часть веб-страницы, не дожидаясь асинхронной загрузки таблиц стилей CSS. Это значительно улучшает FCP.

Кроме того, вы можете использовать WP Rocket для автоматизации этого процесса.

Включение параметра « Оптимизировать доставку CSS» в WP Rocket сгенерирует CSS Critical Path для всех типов страниц WordPress и встроит их. И если вам случится внести какие-либо настройки или изменить свою тему, он также автоматически обновит CSS Critical Path.

4. Избегайте элементов на основе сценария над сгибом

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

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

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

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

• Любые тяжелые анимации
• Плагины слайдера
• Социальные сети или плагины для обмена
• Плагины мегаменю
• Встраивается как Google Ads

5. Избегайте отложенной загрузки изображений, расположенных выше сгиба.

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

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

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

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

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

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

Примечание. Ленивая загрузка изображений была добавлена ​​в ядро ​​WordPress и станет встроенной функцией начиная с WordPress 5.5. Он также поддерживает фильтры для настройки ленивой загрузки.

6. Встроенные важные изображения

HTML и CSS предоставляют возможность встроить изображения с помощью форматов Base64 или SVG. Они называются URI данных .

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

Вот некоторые из наиболее распространенных изображений в верхней части страницы, которые можно встроить:

• Логотип
• Иконки (поиск, социальные сети и т. Д.)
• Изображение баннера
• Задний план

Что такое изображения Base64 и SVG?

Base64 — это алгоритм кодирования, который преобразует любой тип данных, включая изображения, в текст. Вы можете встраивать изображения в кодировке Base64 непосредственно в файлы HTML или CSS. Это отличный способ ускорить загрузку небольших изображений.

Base64 Image Encoder — отличный бесплатный инструмент для преобразования любого формата изображения в Base64. Он поддерживает форматы изображений JPEG, PNG, WebP, SVG и BMP.

Добавление изображений в кодировке Base64 в HTML:

<img src="data:image/jpeg;base64,/uj/…[content]..." width="100" height="50" alt="this is a base64 image">

Вы также можете использовать изображения в кодировке Base64 в CSS:

.custom-class {
    background: url('data:image/jpeg;base64,/9j/…[content]...');
}

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

Примечание. Использование изображения SVG в качестве источника внутри тега <img> отличается от встраивания изображения SVG напрямую через тег <svg> .

Вот как можно встроить SVG в HTML:

<body>
  <!-- Insert SVG code here, and the image will show up! -->
    <svg xmlns="http://www.w3.org/2000/svg">
        <circle cx='50' cy='25' r='20'/>
    </svg>
</body>

Это хорошая идея , чтобы компресс или преуменьшать (если SVG) изображений , прежде чем встраивание их. Если ваши изображения в растровом формате (JPEG или PNG), используйте Base64. Если их можно преобразовать в векторный формат, используйте SVG.

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

Если какие-либо изображения или значки жестко запрограммированы внутри вашей темы или плагинов, вам необходимо найти их вручную и заменить их исходные URL-адреса встроенными изображениями. Такой плагин, как Search & Replace, может помочь вам в этом легко.

Есть несколько недостатков встраивания изображений:

• Увеличивает размер изображений (обычно на 30%).
• Это увеличивает размер страницы и, следовательно, TTFB.
• Встроенные изображения не могут быть доставлены через CDN.

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

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

7. Оптимизируйте размер DOM вашего сайта

Объектная модель документа (DOM) — это представление всех объектов, составляющих веб-страницу. Графически это представлено в виде дерева с ветвящимися узлами и объектами.

Структурированное представление DOM позволяет легко изменять его элементы с помощью языка сценариев, такого как JavaScript.

Все элементы HTML в дереве DOM называются узлами . Узлы могут разветвляться на несколько элементов, каждый из которых может далее разветвляться, и так далее. Насколько глубоко они разветвляются, называется глубиной узла . Глубина узла всего дерева DOM называется глубиной дерева . Все непосредственные элементы ветвления узла называются дочерними элементами .

Наличие большого DOM-дерева может негативно повлиять на ваш FCP по многим причинам:

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

Google помечает веб-страницы деревьями DOM, на которых есть:

• Всего более 1500 узлов
• Глубина более 32 узлов
• Родительский узел с 60+ дочерними узлами

Как уменьшить размер DOM?

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

Вот несколько советов, которые помогут вам уменьшить размер DOM:

• Разделите большие страницы на более мелкие.
• Ленивая загрузка как можно большего количества HTML-элементов, а не только изображений.
• Пагинайте комментарии, сообщения, продукты и т. Д.
• Ограничьте количество сообщений, отображаемых на вашей домашней странице и страницах архива.
• Не скрывайте нежелательный контент с помощью CSS. Вместо этого удалите его полностью.
• Избегайте использования раздутых конструкторов страниц, которые вставляют ненужные теги <div> .
• Выбирайте хорошо оптимизированные темы (например, GeneratePress или Астра).

Не используйте плагины, которые добавляют слишком много тегов <div> (например, плагины мегаменю).

8. Убедитесь, что текст остается видимым во время загрузки веб-шрифта.

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

Есть причина, по которой Google отмечает такое поведение. Некоторые браузеры не отображают текст, пока не будут загружены все шрифты. Это вызывает так называемую вспышку невидимого текста (FOIT).

Вы можете исправить это, заставив браузер временно отображать системный шрифт во время загрузки пользовательских шрифтов. Просто добавьте font-display: замените свой стиль @ font-face, чтобы избежать FOIT почти во всех современных браузерах.

Вот пример того, как это можно применить:

@font-face {
  font-family: 'Pacifico';
  font-style: normal;
  font-weight: 400;
  src: local('Pacifico Regular'), local('Pacifico-Regular'), url(https://fonts.sample.com/pacifico.woff2) format('woff2');
  font-display: swap;
}

Если вы импортируете шрифты непосредственно из CDN (например, Google Fonts), вы можете добиться того же, добавив параметр & display = swap в конец URL-адреса.

<link href="https://fonts.googleapis.com/css?family=Roboto:400,700&display=swap" rel="stylesheet">

9. Используйте подсказки ресурсов

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

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

Некоторые подсказки относятся к ресурсам на текущей странице, а другие — к возможным будущим страницам. Все подсказки ресурсов используют для активации атрибут rel тега <link> .

Предварительная выборка DNS

Если вы загружаете какой-либо ресурс с внешнего веб-сайта, добавление параметра dns-prefetch сообщит браузеру, что нужно как можно быстрее разрешить DNS URL-адреса.

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

<link rel="dns-prefetch" href="//external-website.com">

WP Rocket упрощает добавление всех внешних доменов в предварительно загруженные .

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

Предварительное подключение

Preconnect работает так же, как предварительная выборка DNS, за исключением того, что не останавливается только на разрешении DNS. Он также продолжит и установит рукопожатие TCP и согласование TLS (если есть).

Его можно использовать так:

<link rel="preconnect" href="https://example.com">

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

Предварительная выборка

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

Вот как вы можете указать браузеру для предварительной загрузки ресурса:

<link rel="prefetch" href="scripts.js">

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

Prerender

Это самый мощный ресурсный совет. Добавление параметра prerender к ресурсу заставляет браузер загружать все свои ресурсы, анализировать их, создавать дерево DOM, применять стили, выполнять сценарии, отображать веб-страницу и держать ее готовой к обслуживанию. Если вы позже посетите URL-адрес, указанный в href , страница загрузится мгновенно.

Вот как вы делаете предварительную визуализацию ресурса:

<link rel="prerender" href="https://example.com/next-page">

Предварительный рендеринг вашей главной целевой страницы — отличный способ увеличить количество конверсий.

Предварительная загрузка

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

<head>
  ...
  <link rel="preload" href="styles.css" as="style">
  <link rel="preload" href="ui.js" as="script">
  ...
</head>

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

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

10. Избегайте множественных перенаправлений страниц.

Когда вы посещаете URL-адрес, который был перенаправлен на другой URL-адрес, сервер вернет ответ с кодом состояния перенаправления HTTP 301. В консоли вашего браузера это будет выглядеть примерно так:

HTTP/1.1 301 Moved Permanently
Location: /url/to/new/location

Ответ перенаправления заставляет браузер сделать еще один HTTP-запрос в новое место. Обычно это задерживает загрузку веб-страницы на сотни миллисекунд.

Если ваша страница имеет более одного редиректа, это может значительно замедлить работу FCP.

Lighthouse отмечает страницы с двумя или более редиректами.

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

ЗАКЛЮЧЕНИЕ

Улучшение FCP больше не выбор, а необходимость. Google уже начал ранжировать веб-сайты на основе их оценок FCP. Более того, более быстрый FCP также улучшает взаимодействие с пользователем.

И скоро появятся лучшие вещи! Google планирует ввести еще одну метрику производительности, ориентированную на пользователя, под названием First Meaningful Paint (FMP). В то время как FCP измеряет время рендеринга для любого контента (например, логотипов, слоганов, фоновых изображений), FMP будет запускаться только после того, как контент, желаемый пользователем, загружен (например, заголовки, изображения обложек, основной текст). FMP еще не стандартизирован, но вы можете узнать о нем подробнее здесь .

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

Если у вас все еще есть вопросы о том, как улучшить FCP вашего сайта, не стесняйтесь оставлять комментарии!

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

Одним из инструментов для анализа качества и usability страницы с составлением отчёта является PageSpeed Insights (далее просто PageSpeed).

Какие вопросы я затрону в статье:

• что такое PageSpeed;
• как измеряется и оценивается производительность;
• лирическое отступление: critical render path;
• способы оптимизации PageSpeed;
• для чего это нужно?

PageSpeed входит в набор сервисов от Google, и позволяет:

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

При анализе мы получаем два результата: для десктопной и мобильной версий, где значения от 0 до 49 являются низкими, от 50 до 86 — средними, и от 87 до 100 — высокими.

С выходом 8-го релиза PageSpeed, на примере мобильной версии главной страницы ДомКлик (актуальной на момент написания статьи) мы можем увидеть значения ниже, чем, например, в 5-м релизе (см. дальше), что доказывает рост пороговых показателей и ужесточение требований к производительности сайтов.

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

На текущий момент в основном используются: имитация мобильного устройства Nexus 5 на Android, сеть 3G со скоростью 8 мегабит/с., задержка 150 миллисекунд, рендерится на европейских серверах и применяется троттлинг процессора.

Показатели с каждым запуском анализа могут колебаться из-за A/B-тестов, изменений маршрутизации интернет-трафика, дополнительных активных расширений браузера, которые добавляют или изменяют сетевые запросы, и антивирусов.

Если говорить о критериях оценки, то основные представлены ниже:

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

Speed Index — индекс скорости загрузки, который показывает, как быстро загружается содержимое.

Largest Contentful Paint — время отрисовки крупного содержимого, находящегося на первом экране. Под крупным содержимым мы понимаем картинки, видео или текст.

Time to Interactive — время, в течении которого страница становится полностью готова к взаимодействию с пользователем.

Total Blocking Time — сумма всех периодов от первой отрисовки содержимого, когда скорость выполнения задач превышала 50 мс. Измеряется в миллисекундах.

Cumulative Layout Shift — процентная величина, на которую смещаются видимые элементы области просмотра при загрузке.

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

• запрос на сервер;
• получение HTML-документа;
• построение DOM-дерева;

• запрос на получение критических ресурсов (JS, CSS);
• построение CSSOM-дерева;

• получение и отработка JS-кода;
• построение render-дерева;
• отрисовка страницы

Как можно улучшить метрики?

Актуальная версия HTTP

Использование актуальной версии HTTP позволяет оптимизировать запросы к серверу. Если сравнивать версию HTTP/1.1, которая поддерживается до сих пор, и версию HTTP/2.0, то изменения ярко заметны и влияют на работу сайта в целом в HTML/2.0:

• используется мультиплексирование;
• служебные заголовки передаются в сжатом виде;
• повышается безопасность.

HTTP/2.0 обратно совместим с HTTP/1.1, что даёт время для перехода на новый протокол.

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

Используйте правильные размеры изображений. На странице не должно быть изображений, размер которых больше, чем можно отобразить на экране пользователя. С помощью «отзывчивых» изображений можно создать несколько версий каждой картинки, а затем через, к примеру, @media-запросы указать нужную для отображения. Также можно воспользоваться ресайзерами: thumbor, npm sharp, imagemagick или любым другим на ваш вкус.

Используйте современные форматы изображений: WebP и SVG.

Вне первого экрана важно использовать для всех изображений «ленивую загрузку», она позволяет подгружать картинки по мере необходимости.

Использование критического CSS

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

Уменьшайте bundle.js

Минифицируйте JS и CSS, это ускорит анализ скриптов и сократит объём полезной сетевой нагрузки.

Откажитесь от тяжёлых библиотек и асинхронной/отложенной загрузки скриптов

Для сокращения расхода трафика необходимо поддерживать код в актуальном состоянии, своевременно удалять неиспользуемый код. Чтобы не блокировать основной поток, по возможности загружайте сторонние скрипты асинхронно (атрибут async или defer в тегах script, или приоритизация загрузки основного содержимого, к примеру, рекламу грузим после), и при их выборе отдавайте предпочтение более легковесным библиотекам. Если в подгружаемой библиотеке используется менее 10-ти методов, можно рассмотреть вариант самостоятельной реализации этих методов в проекте, но такой подход должен быть хорошо обдуман.

Уменьшайте Critical Render Path

Включает в себя совокупность предыдущих пунктов. Сюда можно добавить «ленивую загрузку» DOM-элементов.

Использование SSR

Server Side Rendering — рендеринг страницы на сервере. В этом случае поисковые роботы получают готовый код сайта, что важно в условиях новых правил ранжирования.

Это основные моменты, которые работают на практике и которые мы применяем у себя в ДомКлик при разработке сервисов.

Для чего нам нужно улучшать метрики?

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

Очень ёмко и кратко смысл оптимизации описывает цитата из твиттера Википедии:

Cut page load by 100ms and you save Wikipedia readers 617 years of wait annually

Подведём итоги

Не следует ставить перед собой цель достичь заветных 100 %, скорее, нужно сосредоточиться на поиске и оптимизации проблемных мест, на сокращении времени загрузки. Чтобы создавать удобный и быстрый сайт для пользователей не во вред функциональной части и не в ущерб пользовательскому опыту. Оптимизируйте с умом.

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

«Я нажал, но ничего не произошло! Почему я не могу взаимодействовать с этой страницей?» 😢

First Contentful Paint (FCP) и Largest Contentful Paint (LCP) — это метрики, которые измеряют время, необходимое для визуального отображения (рисования) контента на странице. Хотя это важно, время рисования не учитывает реакцию на нагрузку или то, как быстро страница реагирует на взаимодействие с пользователем.  

Первая задержка ввода (FID) — это метрика Core Web Vitals, которая фиксирует первое впечатление пользователя об интерактивности и отзывчивости сайта. Она измеряет время с момента, когда пользователь впервые взаимодействует со страницей, до времени, когда браузер действительно способен ответить на это взаимодействие. FID является метрикой поля и не может быть смоделирован в среде lab. Реальное взаимодействие с пользователем требуется для измерения задержки ответа.  

Чтобы помочь предсказать FID в lab, рекомендуется общее время блокировки (TBT). Они измеряют разные вещи, но улучшения в TBT обычно соответствуют улучшениям в FID.  

Основной причиной плохого FID является тяжелое выполнение JavaScript. Оптимизация анализа, компиляции и выполнения JavaScript на вашей веб-странице напрямую сократит FID.

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

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

• Сократить время выполнения JavaScript
• Разбить длинные задачи
• Оптимизировать свою страницу для обеспечения готовности к взаимодействию
• Использовать веб-работника

Сократить время выполнения JavaScript

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

Чтобы уменьшить количество JavaScript, выполняемого на вашей странице нужно:

• Сократить и сжать файлы JavaScript
• Отложить неиспользуемый JavaScript
• Минимизировать неиспользованные полифилы

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

Сократить и сжать файлы JavaScript

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

Terser поддерживает синтаксис ES6+ и может использоваться для минимизации современных файлов JavaScript без необходимости их транспилирования. Если вы используете связку модулей и хотите включить Terser в свою цепочку инструментов:

• Webpack и Parcel уже минимизируют использование Terser по умолчанию в режиме production
• Если вы используете Rollup, включите rollup-plugin-terser в качестве выходного плагина

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

Отложить неиспользованный JavaScript

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

На вкладке Coverage в Chrome DevTools можно указать, сколько JavaScript не используется на вашей веб-странице.

Чтобы сократить неиспользуемый JavaScript необходимо:

• Разделить Code-split пакет на несколько частей
• Отложить любой некритический JavaScript, включая сторонние скрипты, используя async или defer

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

import('module.js')	
  .then((module) => {	
    // Do something with the module.	
  });	

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

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

• Если вы используете webpack, Rollup или Parcel в качестве связующего модуля, воспользуйтесь их динамической поддержкой импорта.
• Клиентские фреймворки, такие как React, Angular и Vue, предоставляют абстракции, облегчающие отложенную загрузку на уровне компонентов.

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

<script defer src="…"></script>	
<script async src="…"></script>	

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

Минимизируйте неиспользуемые полифилы

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

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

 Для оптимизации использования полифилла на вашем сайте: 

• Если вы используете Babel в качестве транспортера, используйте @babel/preset-env для включения тех полифилов, которые необходимы для браузеров с которыми вы планируете таргетинг. Для Babel 7.9 включите bugfixes опцию для дальнейшего сокращения ненужных полифилов
• Используйте шаблон module/nomodule для доставки двух отдельных пакетов (@babel/preset-env также поддерживает это через target.esmodules)  

<script type="module" src="modern.js"></script>	
<script nomodule src="legacy.js" defer></script>	

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

Разбейте длинные задачи

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

Длинные задачи — это периоды выполнения JavaScript, когда пользователи могут обнаружить, что ваш пользовательский интерфейс не отвечает. Любой фрагмент кода, который блокирует основной поток на 50 ms или более, можно охарактеризовать как длинную задачу. Длинные задачи являются признаком потенциального раздувания JavaScript (загрузка и выполнение больше, чем может потребоваться пользователю прямо сейчас).  

Разделение длинных задач может уменьшить задержку ввода на вашем сайте.

FID должен заметно улучшиться, поскольку вы принимаете лучшие практики, такие как разделение кода и разбитие ваших длинных задач. Хотя TBT не является полевой метрикой, он полезен для проверки прогресса и в конечном счете улучшения как времени до интерактивного (TTI), так и FID.

Оптимизация страницы для взаимодействия готовности

Существует ряд распространенных причин плохой оценки FID и TBT в веб-приложениях, которые сильно зависят от JavaScript:

Выполнение сценария первого лица может задержать готовность к взаимодействию #

• Увеличение размера JS, большое время выполнения и неэффективное разбитие на блоки могут замедлить скорость реакции страницы на ввод данных пользователем и повлиять на FID, TBT и TTI. Прогрессивная загрузка кода и функций может помочь распространить эту работу и повысить готовность к взаимодействию.
• Серверные визуализированные приложения могут выглядеть так, как будто они быстро рисуют пиксели на экране, но остерегайтесь того, что взаимодействие пользователей блокируется большим исполнением сценариев (например, повторная гидратация для подключения слушателей событий). Это может занять несколько сотен миллисекунд, иногда даже секунд, если используется разделение кода на основе маршрута. Подумайте о том, чтобы перенести больше логики на сервер или генерировать больше контента статически во время сборки.

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

Выборка данных может влиять на многие аспекты готовности взаимодействия

• Ожидание каскадных выборок (например, JS и выборок данных для компонентов) может повлиять на задержку взаимодействия. Цель минимизировать зависимость от каскадных выборок данных.
• Большие встроенные хранилища данных могут сократить время анализа HTML и повлиять на показатели рисования и взаимодействия. Стремитесь свести к минимуму объем данных, подлежащих последующей обработке на стороне клиента.

Выборка данных может влиять на многие аспекты готовности взаимодействия

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

Использование веб-работника

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

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

1. Comlink: вспомогательная библиотека, которая абстрагируется и облегчает использование postMessage
2. Workway: экспортер веб-работника общего назначения
3. Workerize: перемещение модуля в веб-работника

Инструменты разработчика

Доступен ряд инструментов для измерения и отладки FID:

Lighthouse 6.0 не включает поддержку FID, так как это метрика поля. Тем не менее, общее время блокировки (TBT) может использоваться в качестве прокси. Оптимизации, которые улучшают TBT, также должны улучшить FID на местах.

Chrome User Experience Report предоставляет реальные значения LCP, агрегированные на уровне источника.

В этой заметке мы рассмотрим основные проблемы PageSpeed Insight и методы их решения. Список дополняется.

Проблемы которые можно решить с помощью моих решений

1. Устраните ресурсы, блокирующие отображение — данную проблему можно решить с помощью решения Ускорение загрузки сайта (функционал ускорения стилей)

2. Используйте современные форматы изображений — данную проблему можно решить с помощью решения Ускорение загрузки сайта (функционал оптимизации webp)

3. Настройте показ всего текста во время загрузки веб-шрифтов — данную проблему можно решить с помощью решения Ускорение загрузки сайта (функционал оптимизации webp)

Проблемы, которые зависят от сервера

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

Проблемы, которые можно решить только с участием разработчиков

Доработкой конкретного сайта (не решить автоматическими методами или настройкой)

1. Для изображений не заданы явным образом атрибуты width и height — Нужно скорректировать шаблоны и страницы, прописать требуемые атрибуты

2. Настройте подходящий размер изображений — Изображения в странице имеют больший размер чем на странице, нужно доработать масштабирование на уровне шаблонов 

3. Уменьшите влияние стороннего кода — нужно максимально уменьшить количество подключаемых скриптов и стилей. Обычно это счётчики метрики, jivosite и т.п.

Проблемы, которые не решить

2. Сократите время выполнения кода JavaScript — зависит от количества и качества javascript на вашем сайте. Для улучшения показателя нужно анализировать весь javascript сайта, переписывать на более оптимальный или отрезать часть функционала.

3. Удалите неиспользуемый код CSS / Удалите неиспользуемый код JavaScript — зависит от шаблона, т.к. pagespeed не показывает что именно он считает неиспользуемым кодом, найти и вычистить почти нереально

4. First Contentful Paint (3G) — общий вес контента на странице, можно уменьшить, но фактически очень сложно дотянуть до нормы.

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

—-

Значимость проблем: First Contentful Paint (3G), можно уменьшить с помощью решения Ускорение загрузки сайта т.к. его механизмы уменьшают вес стилей, картинок и т.п.

This is a simple (yet in-depth) guide on improving first contentful paint in WordPress.

First contentful paint (FCP) is the point when users see anything on your site (very similar to LCP where users see your largest image or text block in the viewport). Anything before that (including TTFB, DNS lookups, as well as the first content shown) is part of both FCP and LCP.

The Waterfall chart in WebPageTest shows which files load in your FCP time (test your site then click the Waterfall image). In the example below, all files loading in green are part of FCP.

The first request is usually the longest and includes factors like TTFB, DNS, and SSL. The other requests are related to whatever files load first which can be CSS, JavaScript, fonts, and images.

Pay special attention to files loading in the viewport: preloading images/fonts, avoiding bloated headers created by page builders (by hard coding them in CSS), and pushing plugins + third-party code below the fold can help. Aside from reducing the size of files loading in your viewport, using a performant setup (hosting, theme, plugins, CDN) are two big FCP/LCP factors.

1. Aim For A <100ms TTFB

TTFB is 40% of LCP, which means it’s also a big part of FCP. The 2 biggest TTFB factors are:

• Hosting
• CDN, ideally with a large network (PoPs) and full page caching

I always recommend Rocket.net with their Cloudflare Enterprise who averages a TTFB of <100ms globally which you can test in KeyCDN (or click through my site since I’m using them).

Here are the specs if you want to do your research:

 
I’ve written plenty of bad reviews on SiteGround, Hostinger, Kinsta, Bluehost, GoDaddy, and “mainstream hosts” who are only popular because of marketing, but have less CPU cores/RAM, slower SATA SSDs, low CPU and PHP worker limits, and are mostly overglorified shared hosting.

Cloudways and Scala Hosting are 2 other solid cloud hosts, or RunCloud/GridPane for more DIY. If you absolutely must use shared hosting because of a tight budget, at least use someone who uses LiteSpeed like NameHero or ChemiCloud. Both use NVMe SSDs with more CPU/RAM than other LiteSpeed hosts like Hostinger. Not only is LiteSpeed faster than Apache/Nginx, but it can handle more traffic, is more efficient regarding CPU usage, and you’ll use LiteSpeed Cache with QUIC.cloud. Rocket.net is still faster – but that is arguably the fastest setup if you’re on a budget.

A few notes about Rocket.net:

• Here’s a Facebook thread if you’re still not sure.
• You get your first month for $1 when you create an account.
• Support is the best I’ve used (by far) and does free migrations.
• Cloudflare Enterprise is automatically setup (no need to do anything).
• The only “tweaks” I did were PHP 8 and requesting Redis Object Cache Pro.
• There are no PHP workers limits and 10-25x more monthly visits than Kinsta.
• You can see other people who improved TTFB in Rocket’s TrustPilot reviews.
• It’s owned by Ben Gabler who has extensive experience with hosting + CDNs.
• Here’s an interview I did with Ben where he answers several helpful questions.
• Test your before & after results and I also suggest using the WP Hosting Benchmarks plugin (here are my results, my GTmetrix report, and all my URLs pass core web vitals).

2. Reduce CSS + JavaScript Files

Are CSS/JS files part of FCP in your waterfall chart? You can also use the coverage report in Chrome Dev Tools to see your largest files:

Themes, plugins, and third-party code are usually the biggest culprits. After that, you can further reduce files through the “remove unused CSS” setting in FlyingPress or Perfmatters (faster than WP Rocket’s setting), delaying JavaScript, and replacing plugins. For example, I replaced wpDiscuz with native comments and started using Gutenberg for galleries + tables.

3. Use Local Fonts, Preload Them, And Use “Swap”

Fonts loading in your first contentful paint time? No problem…

Use Local Fonts – check your Waterfall chart to make sure fonts load from your domain, not fonts.gstatic.com or use.fontawesome.com. If they do, there are several tools to host them locally: several cache plugins can do this (but not WP Rocket), Perfmatters, OMGF, Elementor, Transfonter, etc. Also use woff or better, woff2 which are faster than alternative formats like .ttf. Finally, only use 1 font without loading too many font weights/icons (obvious but still common).

Preload Fonts – fonts loading above the fold or those in CSS files should be preloaded. There’s no magic tool to learn which fonts to preload, so this requires testing them in a Waterfall chart (preloading too many fonts or preloading fonts not being used can result in a negative impact).

Use Font-Display: Swap – if you need to ensure text remains visible during webfont load, PSI tells you which fonts are causing FOIT (flash of invisible text). Basically, you want to locate that file using String Locator, then add font-display: swap to the @font-face. Some plugins may also be able to do this: Elementor, Perfmatters, FlyingPress, WP Rocket, Swap Google Fonts Display.

@font-face {
font-family: "Lato Regular";
font-weight: 300;
font-style: normal;
src: url("fonts/Lato-Regular-BasicLatin.woff2") format("woff2");
font-display: swap;
}

4. Preload Viewport Images And Exclude From Lazy Load

Since viewport images should be loaded with high priority, they should be preloaded and excluded from lazy load. Again, FlyingPress/Perfmatters are more effective than WP Rocket.

Both can preload critical images where you set the number of images that usually load in the viewport (i.e. 2-3), then they will be automatically excluded from lazy load while preloaded. With WP Rocket, you need to follow an 8-step process just to specify the number of images to exclude from lazy load. Then you need to preload them individually (with code or a plugin like Pre* Party Resource Hints) which is a pain since usually, each page has unique viewport images.

If you have background images loading in the viewport, they’re treated differently, but you’ll want to exclude those from lazy load as well. Cache plugins and page builders usually have documentation on how to do it, for example, some plugins have a “skip-lazy” class you can add.

Your header/menu is part of the viewport and one of the first things people see.

Creating these with a page builder adds a lot of unnecessary code. So if you insist on using a page builder, code these in CSS (or hire a developer to do this). When I was trying to remove Elementor, I hired WP Johnny and this was the first thing he did which made a huge difference. And while we’re on the topic, stay clear of hamburger menus and other bloated menu plugins.

6. Defer JavaScript

Eliminating render-blocking resources is the first thing Google recommends to improve first contentful paint, which usually means deferring JavaScript.

If your site breaks, you’ll need to exclude problematic JS files from being deferred. And if you still don’t see good results, try installing Async JavaScript and click “apply defer” in the settings.

7. Use Full Page Caching

In Cloudflare’s test, APO improved first contentful paint by around 5% for desktop/mobile.

Of course, there are other options if you don’t want to pay $5/mo for APO: QUIC.cloud’s CDN, Super Page Cache plugin, and Rocket.net’s Cloudflare Enterprise all include full page caching.

8. Avoid Loading Plugins/Scripts In The Viewport

Since the viewport is high priority, consider moving heavy plugins/scripts down on the page.

Ads, social sharing buttons, and other files can be pushed down below the fold so they won’t load in the viewport. And, they can usually be delayed which can further improve web vitals.

9. Use A Performant DNS/CDN

Going back to your Waterfall chart, DNS lookup time is part of that long first request, and CDNs are also one of the best ways to improve TTFB.

Cloudflare’s DNS is my go-to which performs well on cdnperf.com (just sign up and change nameservers). If using QUIC.cloud, their DNS seems to perform well. But if you registered your domain with someone like GoDaddy or NameCheap, you’re using their DNS by default which is usually slow. And because DNS speed is part of TTFB, you’ll want to move it from your registrar.

While the best CDN is debatable, there’s no arguing Cloudflare Enterprise, QUIC.cloud (for LiteSpeed), and BunnyCDN are 3 solid options. Cloudflare has a massive network of 270+ locations with extensive speed/security features. QUIC.cloud’s CDN is newer but still has 75+ PoPs with powerful CSS/image optimizations when used with LiteSpeed Cache (but use the paid plan since the free version only uses 6 PoPs). BunnyCDN is another one of my favorites.

Cloudflare settings that can improve FCP include: Signed Exchanges, TCP Turbo, TLS settings, APO, using Workers for serverless rendering, and Brotli (although your host must support this).

10. Use Multiple Caching Layers

Did you know there are 6 different caching layers?

You might know 4 of them: browser cache (done by your cache plugin), CDN cache (done by your CDN), full page cache (done by your CDN), and HTTP accelerators like Varnish/FastCGI (done through your host). There are 2 other important caching types you may not know about:

11. Generate Critical CSS And Inline It

Some plugins like WP Rocket generate critical CSS and inline it for you.

Otherwise, you can also use a free critical CSS generator tool which prevents FOUC (flash of unstyled text). The next step would be to inline it. Because the browser won’t have to wait for the CSS, it can start rendering your page sooner which will also improve first contentful paint.

12. Delay JavaScript

Delaying JavaScript can improve both your largest and first contentful paint.

Several cache plugins do this (FlyingPress, Perfmatters, Flying Scripts, WP Rocket). Just make sure you read the documentation and view common scripts to delay. You can even delay entire plugins when they load below the fold, such as third-party comments or social sharing plugins.

13. Fix Errors In Your Waterfall Chart

Sounds obvious, but you’d be surprised how many websites have red errors (which probably means you’re loading something that’s not being used, therefore creating a canceled request). Errors can often create the largest requests on your site, so you’ll want to fix them immediately.

14. Set A Longer Cache Expiration

Serving static assets with an efficient cache policy is an easy one to fix. Check your hosting account to see if there’s a setting. For example in Cloudways, it’s static cache expiry. Google wants a cache expiration of 365 days, but WooCommerce sites should generally use 1 month.

15. Test Cloudflare’s Rocket Loader

Rocket Loader defers JavaScript and can improve your site’s first contentful paint. However, it can also break your site, so use with caution. I personally prefer to keep Rocket Loader disabled.

Retest Your First Contentful Paint

PageSpeed Insights can take 28 days to update, so use SpeedVitals which uses Lighthouse.

Frequently Asked Questions

Feel free to ask me any questions in the comments. Hope this helped

Cheers,
Tom

In this article, you’ll learn everything you need to know about First Contentful Paint (FCP), including:

• What FCP is?;

• Why measuring FCP alone isn’t enough;

• How to measure FCP;

• How to fix a page’s FCP time

So, if you want to improve your Google’s PageSpeed Insights score and the user experience on your site, read on. 

What is First Contentful Paint (FCP)?

FCP is the time it takes for the browser to visualize the first piece of DOM content (e.g., image, SVG, non-blank canvas element) on a page. 

To be in the green zone, a page’s FCP should occur in 1.8 seconds or less.

Different elements can trigger this metric, depending on the website. For example, a loading animation:

Or your company logo:

These elements might seem insignificant, but they’re crucial for the user experience. They tell your visitors: “Hey, your input is being processed and the site is loading. The result will be ready in a second”. If a page stays blank for a few seconds before it loads, users don’t know whether something is happening or not.

That’s why FCP is also a perceived load speed metric. 

It’s a good indicator of the first impression your website makes.

FCP can be measured both in the lab (on a predetermined device and network settings) or in the field (by tracking page loads for real users). Improving FCP in the field should be your primary goal, as field data reflects how real users experience your site.

But while important, FCP doesn’t tell the whole story of how users experience load time. In fact, FCP (like all metrics) has some significant gaps.

Here’s why.

Why Measuring FCP Alone Isn’t Enough

Imagine opening a website and watching a white screen for a few seconds before anything is rendered.

During these few seconds, nothing indicates to you that the website is loading.

It’s an awful experience. In fact, this blank screen alone can cause a ton of page abandonment.

This is where First Paint (FP) comes in.

FP measures how long it takes for the browser to render anything on the page, not just DOM content.

This could be a background change, for example.

This change alerts the user that something is happening. The content might not be there, but the visitor knows it’s coming.

In an ideal situation, your FP and FCP should occur at the same time, or with an unnoticeably small delay.

So, FP and FCP are great at measuring the beginning of the loading experience. But we also need to track its culmination.

Enter: Largest Contentful Paint (LCP).

LCP measures the time it takes for the largest above the fold content element to load.

That might be the breaking story on a news website or a product picture in an eCommerce store.

In most cases, your visitors came to see precisely that element. That’s the culmination of their loading experience.

To recap:

• At the start of the loading experience, FP and FCP assure your visitors that their input is being processed;

• At the culmination of the loading experience, LCP gives your visitors what they came for — the largest content element.

How to Measure FCP

The only way to put yourself in the shoes of your visitors is to analyze all 3 paint metrics.

You can use multiple testing tools to measure FCP, and we’ll take a look at some of them.

Important: Keep in mind that each testing tool can give you a slightly different score due to various factors like testing methodology, testing location, etc. Also, focus on tools that provide data from real users over those that only have lab metrics.

Chrome’s DevTools

You can find your FP, FCP, and LCP times with Chrome’s DevTools.

Open a page you want to analyze, right-click and select “Inspect”.

From there, go to “Performance”.

And click the “Reload” button.

Chrome will analyze your page and give you a detailed report. In the “Timings” section, you can find information about your FP, FCP and LCP.

From there, it’s about finding specific issues and solving them.

PageSpeed Insights

Google’s PageSpeed Insights tool shows your FCP and LCP times based on lab and field data:

Important: When looking at web performance, it’s important to focus on field data since it’s gathered from real users and reflects their experience. If your FCP is okay in the lab but not in the field, you still have work to do.

GTmetrix

Another great tool to measure your FCP time is GTmetrix. 

Along with FCP results, GTmetrix will show your LCP score as well:

WebPageTest

WebPageTest allows you to test your site’s performance from different locations while emulating a device with a specific connection:

Once you fine-tune the settings and run the tests, you will see your FCP and LCP, along with other important metrics:

You can run personalized tests by finding where your visitors access your site from (with Google Analytics or another analytics tool) and testing your site from their locations. If the results in some locations are worse, consider investing in a content delivery network (CDN).

Now, let’s talk about improving your FCP time.

How To Fix Your FCP Time

If you open PSI (or the Lighthouse audit), you’ll likely get the following Opportunities:

And Diagnostics:

A lot of these suggestions can help you improve your FCP (and the other two paint metrics).

In general, you should aim to resolve all of them, not just to please PSI, but also to achieve an excellent user experience.

For now, let’s stick to reducing FCP.

Fix Your Caching, Hosting, and CDN

These 3 factors are a pass/fail type of deal.

You have to take care of them and there’s no way around that.

Let’s start with your hosting and CDN.

You should consider 3 key factors when choosing your hosting and CDN provider:

• Your Website’s Type — blog, eCommerce store, personal portfolio, etc.;

• Your Budget;

• Your Website’s Traffic.

But there’s one rule that applies to everyone:

Free hosting and CDN services suck. Sorry to say it, but it’s true.

If you’re serious about website performance, you need a paid plan from a reputable company.

That doesn’t mean you should spend hundreds of dollars on hosting every month. You can find affordable plans with excellent performance.

Check out Quicksprout’s guide to the best hosting companies in 2022 to find a hosting provider that’s right for you.

Most hosting providers also offer CDN services, so you can get both in one swing.

On the other hand, your caching policy will depend on highly individual factors. For example, how often you update the content on your website.

If you want to learn more, our in-depth guide on web caching is a great place to start.

Improve font load time

A common issue when working with custom fonts is the “flash of invisible text” or FOIT.

FOIT occurs when the browser can’t download a font file quickly. When that happens, the browser doesn’t show any text until the entire font file is loaded.

The easiest solution is to temporarily show a system font before the custom font is loaded.

The font-display: swap property can help you achieve this effect. The property tells the browser to use the fallback (swap) font until the custom font is ready. 

Check out our article on 7 font loading techniques that will improve your Core Web Vitals.

Eliminate render-blocking CSS and JavaScript

CSS and JavaScript (JS) files are render-blocking by default.

The browser can’t render anything on the page until it processes them. That’s why you need to improve their delivery.

To solve this issue, you have to inline critical resources and defer non-critical ones.

For example, you should set up Critical CSS, so above-the-fold content can appear instantly. Meanwhile, the rest of the page can load asynchronously.

That’s one form of inlining critical resources. And it’s a great way to start resolving the entire render-blocking problem.

Optimize Your Images

Image optimization means reducing the size of each image without affecting the quality.

It’s a simple idea, but a difficult one to implement.

Choosing the right image type is a great place to start.

The classic image formats (JPEG, GIF and PNG) all have their pros and cons. But right now, the WebP format is your best bet for a few reasons.

First, WebP is developed by Google. The almighty search engine will be happy to see you using this format.

On top of that, WebP produces better results than both JPEG and PNG. According to Google, WebP images are 26% smaller than PNGs and 25-34% smaller than JPEGs.

In short, choosing WebP is a win-win.

Besides the file type, it’s also good to review all the pictures on your website and delete the unnecessary ones. Trust me, they’re there.

An image that doesn’t contribute to the overall goal of the page shouldn’t be there. Plain and simple.

If you want to get more advanced, check out this comprehensive guide on responsive images by Mozilla.

Minify and combine your code files

Minifying and combining code files is an essential part of optimizing your website’s CSS and JS.

On one hand, minifying the code removes unnecessary bits of information like whitespace, comments, and line-breaks. The browser doesn’t need that data to render the page.

On the other hand, combining code files reduces their total number. The fewer the files, the easier it is for the browser to find and download them.

Again, minifying your website’s resources is a simple idea that can yield great web performance results. In fact, a lot of hosting providers offer compression and minification services. So check out with yours to see if they already do it for you.

Avoid Excessive JS Usage (A Proven Way to Improve Your WordPress Site’s FCP)

JS is usually the biggest threat to your website’s performance.

As Addy Osmani puts in his annual talk on web performance, JS is the most expensive part of most websites:

There are many reasons why this problem is so widespread.

First, there are tons of JS frameworks out there.

Each of them helps developers but adds more JS to the website or application. That certainly doesn’t help with website performance.

In fact, Backlinko’s research on page speed found that the fastest JS frameworks (Wink and Gatsby) are 213% faster than the slowest ones (Meteor and Tweenmax).

Second, WordPress’s popularity also contributes to this problem.

As of 2022, WordPress powers around 43% of all websites on the Internet.

All WordPress websites have a theme and at least 2-3 additional plugins. These themes and plugins often have a huge amount of JS (and CSS) baked into them.

To achieve great performance with a WordPress website, apply all the techniques that we already mentioned and choose your theme and plugins carefully. A lot of themes offer demo versions, which you can run through the speed testing tools shown above.

Besides that, you can go through your website and search for excessive JS usage. A few elements you can look out for are:

• Unnecessary sliders (especially above the fold);

• Images and videos that can be served with HTML & CSS instead of JS;

• Animations.

These elements aren’t bad by design. But if they add a lot of JS overhead and don’t contribute to the user experience, they shouldn’t be there.

Don’t be afraid to remove them.

With all that being said, choose your plugins carefully and always monitor your site’s performance after adding a new one. In most cases, sacrificing web performance for a slight design improvement isn’t worth it.
 

NitroPack Can Do All of These Optimizations for You

Without a doubt, web performance optimization is a complex area that takes a lot of effort and time. That’s why a lot of website owners decide to deal with this aspect of their websites by hiring a performance specialist or installing numerous plugins. 

Unfortunately, both options have their setbacks. 

Web performance optimization is a niche discipline which complicates the process of finding a specialist in the field. In turn, this makes their services very expensive and not everyone can afford them. 

Installing multiple plugins might look like a good alternative if you cannot afford to hire a web performance specialist. However, there are a few things that you need to consider before taking that route. Firstly, as you already know, plugins come with a huge amount of JS and CSS baked into them. Something you would like to avoid. Secondly, making all of your plugins work together without conflicting with each other is a tough task.

That’s where NitroPack comes in. 

NitroPack is an all-in-one solution that offers a ton of out-of-the-box features. Such as:

Image Optimization
By default, NitroPack uses lossy compression to reduce image file size. We also convert all images to WebP while keeping the original format as a backup for browsers that don’t support WebP.

Built-in CDN
NitroPack comes with a built-in CDN. It works automatically once you set it up and you don’t have to pay for or integrate 3rd party services.

Critical CSS
Our service creates unique Critical CSS for every page (not page type), per layout. This ensures that each of your pages has unique Critical CSS, resulting in better performance and stability.

Defer JS Loading
NitroPack delays the loading of non-critical resources until user interaction is detected. You can also specify other scripts that should be loaded with a delay.

Code Optimization
We minify and compress HTML, CSS, and JavaScript files. NitroPack also combines multiple CSS/JS files into a single file, reducing the number of network requests the browser has to make.

Optimizing Beyond FCP

Optimizing your FCP will vastly improve the user experience on your website.

It’s not easy, but it’s worth it.

However, that’s not the only metric to work on.

As I said, you should analyze FCP in combination with LCP and FP.

At the same time, LCP is also a part of Google’s Core Web Vitals, along with Cumulative Layout Shift (CLS) and First Input Delay (FID).

These three metrics (LCP, CLS, and FID) are part of Google’s ranking algorithm.

So, a great next step is to learn everything you can about LCP, CLS, and FID. You can get started with our Core Web Vitals guide.