Total blocking time как исправить

Total Blocking Time (TBT) is a load responsiveness metric that measures the usability of the web page during the loading. Total Blocking Time is an important user-centric performance metric that compares the time amount of non-responsive and responsive time during the rendering phase of the web page.

Input responsiveness or the interactivity between the web page and user during the loading are related to the “Long Tasks”. Long tasks are blockers for the Main Thread of the Browser that are longer than 50 MS. Long Tasks are blockers because Browser can’t interrupt or stop a task and during the long task, the browser can’t respond to the users’ input. Total Blocking Time is closely related to First Input Delay and First CPU Idle web page performance metrics. First Input Delay measures when a user can interact with the web page as much as possible earlier while First CPU Idle measures when the first time that browser’s main thread is idle and can respond to the user.

Total Blocking Time measures the total time that the browser’s main thread is blocked by tasks longer than 50 ms. If TBT is optimized, load-responsiveness will be better and First Input Delay, First CPU Idle also will create a better user experience. If a web page can’t respond to the users’ input longer than 50 MS, users will notice the delay. You may check the graph that shows the Total Blocking Time visually below to understand the term better.

Example of tasks during the web page loading process for the browser’s main thread. Every task that longer than 50 MS is a long task. And every MS after the first 50 MS for every Long Task will be counted as Total Blocking Time. Total Blocking Time (TTB) is being measured between First Contentful Paint (FCP) and Time to Interactive (TTI).

You may see the Total Blocking Time calculation example below for these example tasks.

In this example, we have 345 MS as Total Blocking Time in sum.

What is the Relation Between Total Blocking Time and Time To Interactive

Total Blocking Time (TBT) is also related to the Time to Interactive (TTI) like First Input Delay (FID) and First CPU Idle. If the main thread of the browser doesn’t encounter a long task for 5 seconds, Time to Interactive happens. Time to Interactive is a necessary metric for understanding that when the web page is “fully” and “continuously” interactive. Thus, Total Blocking Time and Time to Interactive are complementary terms to each other. Without the Total Blocking Time, Time to Interactive can’t give the right User Experience situation solely. Let’s examine the example below, to understand this situation, better.

If there are only five long tasks that take 51 MS for the browser’s main thread that spread out to the 12 seconds during the loading of the web page, it means that our TTI will happen in the 17th second of the loading. Without the Total Blocking Time, we couldn’t understand that when and in which proportion the browser lets the user interact with the web page. In this example, the Total Blocking Time is only 3 MS. It means that most of the time, users can interact with the web page without notice of a significant delay. To understand and measure the User Experience (UX) and Load Responsiveness, Total Blocking Time and Time to Interactive should be used together.

How to Measure the Total Blocking Time

Total Blocking Time is a lab metric so it can be measured with Page Speed simulators. The tools and services that help for Total Blocking Time calculation and measurement are listed below.

• Lighthouse
• Chrome DevTools
• WebPageTest
• GTMetrix
• SpeedCurve
• Pingdom
• Puppeteer (Suggested for Holistic SEOs)

To understand the Total Blocking Time’s effect on the User Experience, using First Input Delay measurement in the field data can be useful because according to the users’ behavior patterns, the TBT can change in a wide range.

What is a Good Total Blocking Time?

A good Total Blocking Time should be less than 300 MS in a average device and network connection. Lighthouse measures the Total Blocking Time by summing up the Long Tasks’ total blocking effects and comparing it with the top 10.000 web sites’ TBT Score. The 404 pages and assets are also counted in this measurement.

Total Blocking Time classifying thresholds:

• Between the 0 and 300 MS are good and as labeled green in Lighthouse.
• Between the 300 and 600, MS are moderate and labeled as Orange in Lighthouse.
• Over 600 MS is bad and labeled as red in Lighthouse.

How to Determine the Total Blocking Time’s Causes

To improve Total Blocking Time, the Long Tasks should be determined and optimized. To determine the Long Tasks during the web page loading process, Chrome DevTools can be used. You may see an example of Long Tasks during the loading from Chrome DevTools below.

Too see the what causes the Long Tasks, you should click on the Long Task and check the “Bottom Up” section from the Chrome DevTools like below.

As you may notice, we have a “appendChild” event with four sub-process. At the right section, you will see the Javascript Code that starts the Long Task. If you click on that determined JavaScript File, you will see the code block that starts the “appendChild” event as below.

As you may see that in the 12605th line, we have a “d.appendChild(b)” command that starts our long tasks. This is a compiled Javascript. Compiled Javascript means that all of the variables, commands, selectors are shortened for decreasing the total file size. Thus, understanding the code is harder but if you are a Holistic SEO, you may see the optimization opportunities quickly. After, finding the causes of the Total Blocking Time, we may proceed for optimizing them.

How to Optimize Total Blocking Time

After determining the Long Tasks and the code blocks and web page assets that are causing them, optimizing Total Blocking Time can be possible. To optimize the Code Blocks that busy the main thread longer than 50 MS, the methods below can be used.

• Reduce the Request Count of the Third-Party Scripts
• Reduce the Size of the Third-Party Scripts
• Minimize the Browser’s Main Thread Work
• Clean the Unused Javascript and CSS Codes
• Compress the Javascript and CSS Files
• Implement the Code Splitting for Javascript Assets

All of these methods are useful and beneficial for mostly every web page performance metrics, below, we will handle these methods in terms of Total Blocking Time Optimization.

1.Reduce the Request Count of the Third Party Scripts to Optimize Total Blocking Time

Third Party Scripts can reduce the web page performance tremendously. Below, you will see the total impact of the third-party scripts for all of the web in scale.

As you may see that on the web there are lots of third party script kind and all of them have different impact levels on the web pages. Below, you will see some effects of the third-party scripts on web page performance below:

• Creating new network requests
• Stalling the browser’s main thread with long tasks
• Including large image and video assets that are not being optimized
• Uncompressed and Unrefacted third-party scripts are out of control
• Using harmful Javascript Code Structures such as “document.write()”.
• Too long and expensive CSS Selectors usage
• Blocking the “window.Onload” event with unoptimized “iframes”.
• Lacking HTTP Caching
• Slow Response Times from the servers
• Blocking the content displaying without “progressive rendering”.

Because of all these reasons, third-party scripts are important factors that affect the Total Blocking Time. Thus, reducing the third-party scripts count is crucial and beneficial in terms of total blocking time. I recommend you to remove the unnecessary third-party scripts or convince the marketing team for better and efficient third-party usage.

Also, most of the third-party scripts do not affect the content of the web page, thus, delaying the downloading, parsing, and executing the third-party scripts until the main content is being downloaded is an important optimization process that can improve the First Contentful Paint, Largest Contentful Paint, First Input Delay, and Speed Index performance metrics. To learn more about Third-party Scripts and Web Page Performance, you may check our related guidelines.

2. Reduce the Size of the Third Party Scripts to Optimize the Total Blocking Time

To optimize the Total Blocking Time, the size of the Third-Party Scripts should be decreased as their count. To decrease the size of the third party scripts, you may open a request to the third-party scripts’ owners. For instance, I have opened a simple request for even a reduction of “four unnecessary code characters” like below through twitter.

In one of my clients’ websites, the HTML Document has a response header that says that the content is in the “UTF-8” format, this makes the “UTF-8” code snippets in the HTML Documents unnecessary. But since I can’t remove the “UTF-8” block from the “<script async=” src=’script.hotjar.com/modules.7d9bf3…’ charset=’UTF-8′</script>” line, I have contacted with Hotjar and they have opened a new task that says if the web page has already in UTF-8 format, do not include the “UTF-8” addon in the HTML Line for the IT Team.

In this example, these “5 characters” cost only “20 Bytes” but in Holistic SEO and Page Speed Optimization, every code, every pixel, and every letter have importance. For the better user experience and Crawl Efficiency, this mindset is necessary.

3. Minimize the Browser’s Main Thread’s Work to Optimize Total Blocking Time

Main Thread is the processor of the Browser that can perform the process below for creating the web page.

• Script Evaluation
• Style & Layout
• Rendering
• Parse HTML & CSS
• Script Parsing & Compilation
• Garbage Collection

You may also see how many MS Browser’s Main Thread spend on these tasks in Lighthouse as below.

If the main thread is busy longer than 50 MS in a continuous way, this means that some of these Main Thread Work Sections should be optimized. Knowing which section has taken the most time is a good start to know what and how should be optimized. In Chrome DevTools, you may see all of the processes of the main thread in the performance tab as below.

In this example, we see that there are long tasks and non-responsive times to the user while the main thread processes the web page. You may also see the asynchronous loading events and asset loading order to improve. For optimizing Total Blocking Time (TBT) by minimizing the main thread work, you may use the methods below.

• Optimize the Third-party scripts
• Reduce the Main Thread’s work with Web Workers
• Avoid long and complex input handlers
• Reduce the scope of the variables for style calculations
• Avoid layout thrashing
• Minify, Compress and Refactor CSS
• Clean all of the unused Codes
• Defer non-critical CSS and Javascript
• Use code-splitting for reducing the Javascript Payloads

All of these methods can be used for improving the Main Thread’s Efficiency and also optimizing the Total Blocking Time. To learn more about Decreasing the Work for Main Thread, you may check our related guidelines.

4. Decrease the Size of the Web Page Assets’ Size and Request Count to Optimize the Total Blocking Time

Request Size and Transfer Amount are important factors that affect the web page performance in every aspect. In this guideline, we will discuss it in terms of total blocking time. In the Lighthouse’s Diagnostic Sections, you may see that which file type has how many requests and request size as below.

To create a better Total Blocking Time (TBT) performance, smaller file sizes and lesser request amounts are critical. Since the main thread of the browser can download the small files faster with lesser request amount, the possible Total Blocking Time will also be decreased. This situation also will improve the First Input Delay. To decrease the request and transfer amount, you may use the methods below.

• Optimize the Images with better extensions and pixel reducing algorithms.
• Create CSS and Javascript Bundles
• Remove the unused codes according to the different categories.
• Optimize and Compress the Font Files
• Clean the Unnecessary HTML Nodes and Inlined Style and Script Tags
• Turn GIFs into Videos that starts automatically in a loop
• Try to create performance budgets with Lighthouse’s Lightwallet by examining the competitors

To learn more about CSS and Javascript Optimization for page speed and page loading time, you may read the related guidelines from Holisticseo.digital. Implementing these methods will help Total Blocking Time along with other page speed metrics.

5. Importance of Response Time of the Server for Total Blocking Time Optimization

Response time and Time to First Byte (TTFB) is another important subject for the Total Blocking Time. Having a faster server and optimized TTFB will also reduce the TBT. To increase the Server Response Time, you may use the methods below.

• Avoid Using of Dynamic Content
• Configure the Web Server for lesser query
• Optimize the Back-end Infrastructure
• Improve the Server Hardware
• Try to use a CDN Service
• Use Service Workers and Advanced Caching

There are other methods and sections for TTFB Improvements in the context of Total Blocking Time. For instance: if the web site uses server-side rendering, even if the First Contentful Paint happens earlier since the necessary Javascript Functions aren’t being loaded immediately, the user may not interact with the web page yet. While the browser’s main thread loads the necessary functions, Total Blocking Time also creates frustrations, thus having a faster server along with other subjects are important together.

Using the Content Delivery Network (CDN) is also another important aspect of Total Blocking Time. Having a fast CDN around the globe may provide a faster delivery speed since the main web server won’t be overloaded thanks to CDNs, the TTFB can be improved and this affects indirectly the Total Blocking Time per web page asset processing.

To improve Time To First Byte, you may read our related guideline.

Last Thoughts on Total Blocking Time and Holistic SEO and UX

Total Blocking Time is a user-centric performance metric that focused on load responsiveness. If a web page is not responsive during the loading, this situation frustrates the users and create a non-reliable impression related to the Entity’s Reputation in the users’ point of view. Also, Search Engine’s algorithms always care about the User Experience while ranking the web pages in the SERP. If a web page has lots of blocker assets and long tasks for the browser’s main thread, this will impact the crawl budget and efficiency along with the web page’s rankings on the SERP since it can’t response the users properly.

A frozen web page that doesn’t interact with the users create also a trust issue between the brand and the users. It also creates stress during the search on the web. Especially the queries that want a quick answer will have a more Total Blocking Time weight on the rankings. Every search intent creates a new search query and searching behavior pattern, so importance of the different ranking factors has different weights on different queries. Especially the quick answer-seeking queries and e-commerce, calculation and financial search intents need a better Total Blocking Time on the SERP.

A Holistic SEO should always approach in an analytical and critical point of view to all of those ranking factors, user-centric web performance metrics. Our Total Blocking Time guideline will be improved with time.

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

Одним из инструментов для анализа качества и 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 %, скорее, нужно сосредоточиться на поиске и оптимизации проблемных мест, на сокращении времени загрузки. Чтобы создавать удобный и быстрый сайт для пользователей не во вред функциональной части и не в ущерб пользовательскому опыту. Оптимизируйте с умом.

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

Многие думают, что могут самостоятельно провести все необходимые настройки. Но, оптимизация сайта веб-разработчиками потому и выполняется, что любые действия человеком, который не досконально разбирается в JavaScript, построении DOM, CSS и другой внутренней начинке, в лучшем случае не принесут результата. В худшем — придётся проводить «реанимационные мероприятия» и буквально переделывать всё заново. Профессиональная настройка сайта позволяет сделать его действительно быстрым и функциональным.

Одним из показателей, которые можно отследить в аудите Lighthouse — Общее время блокировки. В отчёте он располагается в разделе «Производительность». И каждый из показателей отображает отдельный аспект скорости загрузки страницы. Главное — не получить результаты с помощью проведения тестирования. Первоочередная задача — провести анализ, выявить закономерности и на их основании провести оптимизацию сайта по всем параметрам.

Что такое общее время блокировки

Общее время блокировки (TBT) — это метрика, основанная на времени, которая описывает активность основного потока JavaScript. Эти данные необходимы для понимания того, как долго страница не может ответить на ввод пользователя. ТВТ является более показательным нежели Time to Interactive на который могут оказывать влияние различные процессы в JavaScript.

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

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

Как рассчитывается общее время блокировки

Общее время блокировки рассчитывается путём сложения всех блокирующих частей длинных задач, которые находятся в интервалемежду First Contentful Paint и Time to Interactive. Если на выполнение задачи требуется более 50 миллисекунд, то она будет длинной. И не стоит обращать внимание на тот факт, что зачастую рекомендованным временем называют 100 миллисекунд. Это не совсем достоверная информация, так как 100 миллисекунд включают в себя общее время. Которое требуется браузеру для выполнения полностью всех работ.

Время, которое начинается после вожделенных 50 миллисекунд и является частью блокировки. К примеру, если Lighthouse обнаруживает задачу длительностью 70 миллисекунд, то её блокирующая часть будет составлять 20 миллисекунд.

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

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

•  Задача 1 — 250 миллисекунд

•  Задача 2 — 90 миллисекунд

•  Задача 3 — 35 миллисекунд

•  Задача 4 — 30 миллисекунд

•  Задача 5 — 155 миллисекунд

Таким образом, мы получаем общее время работы затраченное в основном потоке, равное 560 миллисекунд. Но общим временем блокировки будут являться 345 миллисекунд — превышение лимита в первой, второй и пятой задачах.

Почему ТВТ эффективнее ТТI

Говорить о том, что Total Blocking Time эффективнее Time to Interactive — не совсем корректно. TBT является отличным сопутствующим показателем для TTI, поскольку помогает количественно оценить степень неинтерактивности страницы до того момента, когда она станет надежно интерактивной.

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

Как улучшить показатель TBT

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

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

•  Неэффективные операторы JavaScript. Например, после анализа вашего кода можете увидеть вызов document.querySelectorAll(‘a’), который возвращает 2000 узлов. В данном случае требуется провести рефакторинг кода для использования более конкретного селектора, который возвращает только 10 узлов и это также улучшит показатель TBT.

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

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

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

Браузер получает HTML-код страницы сайта и начинает ее разбирать на отдельные элементы, пытаясь каждый тег перевести в (DOM) Document Object Model. В процессе разбора HTML браузер натыкается на внешние скрипты и стили, которые пытается загрузить. Парсер HTML будет продолжать работу по мере загрузки файла CSS, но он заблокирует рендеринг до тех пор, пока файл не будет загружен и проанализирован. Когда он встречает JS-файлы, то рендеринг так же блокируется, но у JS-файлов есть преимущество в виде атрибутов defer и async, которые позволяют HTML-парсеру продолжать работу, пока JS выполняется в фоне. Также в процессе загрузки CSS формируется CSSOM (CSS Object Model), которая содержит в себе карту всех CSS-селекторов сайта. 

После всего этого браузер создает дерево рендеринга, в котором объединяет CSS и HTML. Для каждого узла дерева рендеринга происходит расчет того, где он будет находиться на странице. И уже после этого браузер идет по этому дереву и отрисовывает страницу. 

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

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

Дополнительно к этому в мае 2020 года Google представил Web Vitals – важные показатели для сайта, которые начнут использоваться в ранжировании с середины июня 2021 года. 

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

То есть, если мы сделаем идеальные показатели Web Vitals, но страницы сайта не будут отвечать на запросы пользователей, это не приведет в ТОП. 

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

На текущий момент всего около 20% сайтов соответствуют рекомендуемым Google значениям (по данным https://corewebvitals.iprospect.com/).

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

Ниже я постараюсь рассказать вам про каждый показатель подробнее, а именно – максимально просто объяснить каждый из показателей и то, как на него можно качественно влиять. Также подробнее раскрою стандартную рекомендацию «Улучшить показатели скорости загрузки сайта», чтобы добавить конкретики: «куда смотреть/что править». 

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

LCP (Largest Contentful Paint) – показывает, за какое время самый большой контент отрисовался в видимой части пользователя (на первом экране). 

FID (First Input Delay) – накопленные данные, показывающие среднее время реагирования браузера на первое действие пользователя. 

TBT (Total Blocking Time) – общее время блокировки. 

CLS (Cumulative Layout Shift) – совокупный сдвиг макета. 

FCP – первая отрисовка содержимого (не путайте с LCP!). 

TTI – время до интерактивности. 

Лабораторные данные – данные для одного измерения скорости загрузки сайта. 

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

Область просмотра – это логическое разрешение экрана пользователя. 

Все эти показатели можно увидеть в PageSpeed Insights. 

Рассмотрим на примере сайта https://alliancesales.ru/. Область просмотра в данном случае – это скриншот экрана справа от значений. 

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

1. Largest Contentful Paint (LCP) 

LCP показывает, за какое время самый большой контент отрисовался в видимой части пользователя (на первом экране). Например, для главной страницы https://alliancesales.ru/ самым большим контентом является баннер. 

Хорошим показателем будет считаться показатель до 2,5 секунд для 75% пользователей. 

Посмотреть текущий показатель можно в сервисе Google Page Speed. Данный сервис представляет как лабораторные данные – для конкретной проверки, так и накопленные статистические данные. 

Например, вот показатели для страницы https://alliancesales.ru/ для мобильных устройств (важно соответствовать и на мобильных, и на ПК): 

Мы видим, что накопленные данные говорят о том, что среднее время отрисовки основного видимого контента составляет 3 секунды. Для 65% пользователей – менее 2-х секунд, однако для 13% пользователей данный показатель находится в «красной» зоне. 

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

Какие элементы входят в LCP при его подсчете: 

• < img > (как в нашем примере), 
• < image > элементы внутри < svg > (могут входить), 
• < video > (могут входить), 
• элементы с фоновым изображением, загруженным с помощью CSS, 
• элементы уровня блока, содержащие текстовые узлы или другие дочерние текстовые элементы встроенного уровня (например div с текстом внутри, скриншот ниже). 

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

Примеры для лучшего понимания

Пример 1. 

В данном случае в первый момент отрисовки (FCP – шаг 1) у нас появляется контент под логотипом – он является самым большим контентом. 

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

Пример 2.

В данном случае в момент первой отрисовки контента (FCP – шаг 1) на сайте появляется текстовый блок, который занимает самую большую часть экрана. На втором шаге подгрузились миниатюры, однако самый большой контент остался прежним. На третьем шаге у нас появился дополнительный контент, что привело к смещению прежнего самого крупного контента вниз, а самым крупным контентом стал другой текстовый блок. Четвертый шаг лишь немного сместил контент ниже. А вот на пятом шаге, в момент последней стадии загрузки первого экрана, снова появилась картинка, которая и стала самым крупным контентом в области просмотра. 

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

Еще несколько примеров:

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

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

Внимание! Показатель LCP отличается для разных типов страниц и разных страниц одного типа. 

Как улучшить LCP 

На LCP в первую очередь влияют четыре фактора: 

• Медленное время ответа сервера (например, скорость работы базы данных; скорость выполнения скриптов на сервере; все, что происходит на back-end; а также удаленность сервера от пользователя, скорость интернета). 
• JavaScript и CSS с блокировкой рендеринга (в первую очередь вставлять в код только критичный CSS и JS, остальное можно подгружать позже, чтобы не происходило блокировки основного потока (использовать lazy-load)). 
• Время загрузки ресурса (нужно уменьшать размер передаваемых файлов). 
• Клиентский рендеринг (актуально для SPA). 

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

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

• Применение PRPL (предварительная загрузка, ускорение отрисовки, кеширование, lazy-load). 
• Оптимизация процесса визуализации/отрисовки (например, использовать прогрессивный рендеринг страниц с подгрузкой JS-файлов по мере необходимости). 
• Оптимизация CSS (например, сделать загрузку CSS асинхронной, подгружая файлы через JS). 
• Оптимизация изображений (использовать современные форматы изображений, использовать прогрессивное сжатие изображений и т.п.).
• Оптимизация веб-шрифтов (например, избегать невидимого текста, уменьшить размер шрифтов/включить сжатие). 
• Оптимизация JavaScript для сайтов с клиентским отображением – SPA-сайты, JS-frameworks (например, чтобы HTML-контент формировался в браузере пользователя с помощью JS, а не на сервере). 

Проработка LCP 

Данные по всем проблемным страницам можно найти в Google Search Console (требуется авторизация) https://search.google.com/u/1/search-console/core-web-vitals. Это касается только тех сайтов, где достаточно «полевых данных». Если «полевых» данных нет, а также в GSC нет никаких ошибок, то стоит самостоятельно проверить основные типы страниц через Google Page Speed для оценки наличия полевых и лабораторных данных LCP. 

Дальше необходимо найти причины столь низких значений LCP. Напоминаю, что показатель хуже чем 4 секунды, считается плохим. Желательно добиться показателя ниже 2,5 секунд. 

Посмотрим на примере страницы https://alliancesales.ru/. По данным Google Page Speed, наш LCP равен 14,9 секунд (лабораторные). 

При просмотре через сервис https://gtmetrix.com/ LCP составляет только 4,7 секунды. 

При просмотре через инспектор браузера Google Chrome (кнопка F12, далее перейти на вкладку Performance, включить Screenshots, переключиться в мобильные устройства (например, iPhone X)):

После чего запустить проверку Ctrl + Shift + E (в Windows). Видим, что в разделе Timings есть блок LCP. 

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

Итого три разных инструмента нам показали 3 разных показателя: Google Page Speed – 14,9 секунд; GTmetrix – 4.7 секунды; Инспектор браузера – 5,9 секунд. 

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

Рекомендации 

1. Необходимо увеличить мощность сервера для сокращения времени его ответа. 
2. Так как наша картинка товара является наибольшим контентом на странице, то для изображения первого товара можно использовать preload. 
3. Добавление CDN. 
4. Прочие рекомендации из раздела «Как улучшить LCP». 

2. First Input Delay (FID) 

FID – время до интерактивности вашего сайта. 

 

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

Важно! FID измеряет только «задержку» обработки событий. Он не измеряет ни время обработки событий, ни время, необходимое браузеру для обновления пользовательского интерфейса после запуска обработчиков событий. 

Постараемся понять, что же это такое, на простом примере. 

Условные обозначения: 

FCP – первая отрисовка содержимого (не путайте с LCP!). 

TTI – время до интерактивности. 

Серые блоки – запросы на ресурсы (в основном CSS и JS). 

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

Вертикальная черная линия рядом с красной стрелкой – момент взаимодействия пользователя. 

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

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

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

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

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

Для примера посмотрим показатели страницы https://alliancesales.ru/.

Видим, что среднее значение полевых измерений составляет 91 миллисекунду. 75% пользователей имели FID менее 100 миллисекунд. Для 13% пользователей показатель FID более 300 миллисекунд. Лабораторные данные по TBT составили 4050 миллисекунды. То есть основной поток в браузере был заблокирован различными задачами чуть больше 4-х секунд. 

Как улучшить FID 

Хотя FID является полевым показателем, рекомендации по улучшению FID такие же, как и для улучшения лабораторного показателя Total Blocking Time (TBT). 

Частично рекомендации, которые могут улучшить показатель FID, такие: 

• Уменьшить влияние стороннего кода (удалить либо уменьшить код со сторонних сайтов/приложений). 
• Уменьшить время выполнения JavaScript (например, сократить или сжать код, удалить неиспользуемый код, использовать асинхронную загрузку). 
• Уменьшить основной рабочий поток (например, следует избегать больших и сложных макетов, минимизировать CSS, удалить неиспользуемый код и многое другое). 
• Сохранить низкое количество запросов и небольшие размеры переводов (самое простое – уменьшить размеры крупных файлов при передаче). 

Проработка FID (TBT) 

Данные по всем проблемным страницам можно найти в https://search.google.com/u/1/search-console/core-web-vitals (требуется авторизация), это касается только тех сайтов, где достаточно «полевых данных». Если «полевых» данных нет, а также в GSC нет никаких ошибок, то стоит самостоятельно проверить основные типы страниц через Google Page Speed для оценки наличия полевых данных FID и лабораторных данных TBT. 

Напоминаю, что показатель хуже, чем 300 миллисекунд, считается плохим. Желательно добиться показателя ниже 100 миллисекунд. 

Из списка страниц, которые содержит в себе отчет в Google Search Console, необходимо выбрать основные шаблонные страницы с наихудшими показателями. Для примера возьмем https://alliancesales.ru/. 

Можно проверить показатели FID (TBT) в Google Page Speed. Для более детального подхода можно воспользоваться инспектором браузера. 

В инспекторе браузера Google Chrome (кнопка F12) необходимо перейти на вкладку Lighthouse, выбрать мобильные устройства и Performance, после этого нажать Generate report. 

Получим следующую картину. 

 

Внимание! Могут появляться предупреждения, поэтому проделывайте данные операции в «чистом» браузере. 

Видим, что показатель TBT составил 3,0 секунд. 

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

• Ненужная загрузка или выполнение JavaScript. Это происходит, когда основной поток выполняет работу, которая на самом деле не нужна для загрузки страницы. Сокращение нагрузки JavaScript с помощью разделения кода, удаления неиспользуемого кода или эффективной загрузки стороннего JavaScript должно улучшить ваш показатель TBT. 
• Неэффективные операторы JavaScript. Например, после анализа вашего кода можете увидеть вызов document.querySelectorAll(‘a’) (выбор всех ссылок на странице), который возвращает 2000 узлов. В данном случае требуется провести рефакторинг кода для использования более конкретного селектора, который возвращает только 10 узлов, а это улучшит показатель TBT. 

Рекомендации

Рассмотрим на примере страницы https://tomdom.ru/vladivostok/komplekti-shtor/. 

Используем инспектор браузера Google Chrome (F12). Переходим на вкладку Lighthouse, ставим категорию Performance для мобильный устройств. Жмем кнопку «Generate report» (подобные данные можно получить и через Google Page Speed, однако зачастую приходится проверять что-то на тестовом сервере, который закрыт для роботов, поэтому мы используем DevTools). 

Получаем следующие данные и возможные рекомендации по оптимизации. 

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

Неиспользуемый код JS/CSS

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

На обычном сайте достаточно сложно отрефакторить ВЕСЬ код таким образом, чтобы необходимый код грузился только на нужной странице. Обычно это либо невозможно, либо занимает гигантское количество времени, так как придется поменять саму архитектуру фронтенда на сайте. Не у каждого проекта есть ресурсы на это. А вот на сайтах, построенных по принципам SPA, такой подход возможен. Например, можно использовать асинхронную загрузку JS-кода компонентов. 

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

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

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

Устраните ресурсы, блокирующие отображение 

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

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

Уменьшение влияния стороннего кода 

Тут все просто. Обычно этот параметр завышен, когда на сайт внедрено большое количество разнообразных сторонних скриптов, таких как Яндекс.Метрика и Google Analytics. Поэтому очень важно загружать их так, чтобы они не блокировали основной поток выполнения рендеринга. 

Например, Яндекс.Метрика в последнем обновлении выкатила «асинхронность» счетчика по умолчанию. Другие внешние скрипты можно подключать, используя атрибуты async или defer. 

3. Cumulative Layout Shift (CLS) 

CLS – показатель стабильности макета, или, по-другому, «накопительный сдвиг макета». 

Как это примерно выглядит https://www.webit.ru/images/layout-instability2.mp4 .

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

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

Сдвиг макета происходит каждый раз, когда видимый элемент изменяет свое положение от одного визуализируемого кадра к другому. Хорошим CLS будет считаться показатель не выше 0,1 для 75% пользователей сайта. 

CLS можно измерить как в полевых условиях, так и лабораторных. Например для страницы карточки товара на нашем исследуемом сайте https://alliancesales.ru/catalog/perchatki/perchatki_nitrilovye/perchatki_nitrilovye_benovy_dental_formula_chernye_50_par_up/ сдвиг макета для мобильных устройств: 

 

Средний показатель для «полевых» данных составляет 0,39. Только для 46% пользователей CLS меньше чем 0,1. 

Лабораторные данные показывают CLS 0,475, то есть происходит сдвиг макета на величину, которая не входит в рекомендуемые показатели. 

Как улучшить CLS 

Для большинства веб-сайтов вы можете избежать всех неожиданных сдвигов в макете, придерживаясь нескольких принципов:

• Всегда включайте атрибуты размера в свои изображения и видеоэлементы или иным образом резервируйте необходимое пространство. Такой подход гарантирует, что браузер сможет выделить правильный объем места в документе во время загрузки изображения. 
• Никогда не вставляйте контент поверх существующего контента, кроме как в ответ на взаимодействие пользователя.  
• Анимируйте переходы таким образом, чтобы обеспечить контекст и непрерывность от состояния к состоянию. 

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

Проработка CLS 

Данные по всем проблемным страницам можно найти в https://search.google.com/u/1/search-console/core-web-vitals (требуется авторизация. Это касается только тех сайтов, где достаточно «полевых данных». Если «полевых» данных нет, а также в GSC нет никаких ошибок, то стоит самостоятельно дополнительно проверить основные типы страниц через Google Page Speed для оценки лабораторных данных показателя CLS. 

На примере сайта https://tomdom.ru:

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

На текущий момент проблема наблюдается только на мобильных устройствах. На ПК проблемных URL не найдено: 

 

Напоминаю, что показатель хуже, чем 0,25, считается плохим. Желательно добиться показателя ниже 0,1. 

Из списка страниц, которые содержит в себе отчет в Google Search Console, необходимо выбрать основные шаблонные страницы с наихудшими показателями. Вернемся к нашей странице https://alliancesales.ru/catalog/perchatki/perchatki_nitrilovye/perchatki_nitrilovye_benovy_dental_formula_chernye_50_par_up/.

В инспекторе браузера Google Chrome (кнопка F12) необходимо перейти на вкладку Performance, включить Screenshots, переключиться в мобильные устройства (например iPhone X). 

После чего запустить проверку Ctrl + Shift + E (в Windows). Мы получим картинку:

Нас интересует раздел Experience. В нем содержится 4 блока, которые говорят нам, что сдвиг макета происходил четыре раза. При изучении трех последних блоков, сдвиг макета был соответственно на: 0,021, 0,01 и 0,00005 – это очень низкий показатель, и на подобные минимальные сдвиги можно не обращать внимание (напоминаю, наша задача чтобы сдвиг макета был ниже 0,25 и желательно ниже 0,1). 

Важно! Тут действует накопительная система. То есть в расчет берется СУММАРНОЕ значение всех сдвигов. 

При просмотре первого блока сдвиг макета составил 0,5352. 

Итого, основной сдвиг макета пришелся на первый блок. 

Постараемся понять, где именно происходит сдвиг макета. 

При наведении на соответствующие строки «Moved from/to» у нас происходит подсветка элемента, который сместился. 

Визуально сдвиг макета выглядит так https://www.webit.ru/images/EQ4C7FfpIT.gif. То есть произошло смещение макета вниз. 

Рекомендации 

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

P. S. Если копать дальше, то можно разобраться, что конкретно сдвинуло наш макет. Начать можно со связанного узла (выше на скрине есть Related Node). В нашем случае подгрузилась иконка корзины, из-за чего произошел сдвиг иконки мобильного телефона. Другие сдвиги можно также отследить и разобраться, что конкретно повлияло на сдвиг того или иного элемента. 

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

Выводы 

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

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

По статистике Google, если сайт загружается дольше 3-х секунд, 53% пользователей покидают его. Каждая следующая секунда задержки загрузки сокращает конверсию в среднем на 20%.

Опрос Unbounce, в котором участвовали сотни покупателей и маркетологов, показал, что около 70% респондентов с меньшей вероятностью совершат покупку на сайте, если время его загрузки оказалось дольше, чем ожидалось. Поэтому компаниям необходимо следить не только за ростом трафика, но и за тем, как посетители взаимодействуют с сайтом, т.к. скорость загрузки страниц влияет как на конверсию, повышение позиции в поисковиках и снижение процента отказов, так и другие важные для бизнеса KPI: количество MQL и SQL, LTV, ROI.

Что сейчас в тренде?

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

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

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

Показатели, отражающие удобство страницы:

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

— Задержка после первого ввода (First Input Delay, FID). Это значение подразумевает интерактивность – время ожидания до первого взаимодействия с контентом. И оно должно составлять менее 100 мс.

— Совокупное смещение макета (Cumulative Layout Shift, CLS) свидетельствует о стабильности верстки и элементов, не препятствующих взаимодействию с контентом. Значение CLS должно быть менее 0,1.

Инструменты для тестирования скорости загрузки сайта

Оптимизация скорости загрузки сайта: 9 основных рекомендаций

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

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

Total blocking time is caused by long main-thread tasks, which means that’s the report you should be looking at in PageSpeed Insights.

Open your avoid long main-thread tasks report. Are your longest tasks from third-party code like Google Tag Manager or Analytics? Are they from specific plugins using jQuery? Most times, blocking time is caused by JavaScript added by WordPress plugins, themes, or third-party code.

Just like most recommendations in PageSpeed Insights, using a lightweight foundation will solve most of your issues (as well as avoiding too many third-party tracking tools in this case).

While it’s always best to start at the source, you can make other optimizations like delaying, deferring, and minifying JavaScript. Or even removing certain plugins/JavaScript files from specific content using asset unloading plugins like Perfmatters. This is a 3-step process: find bottlenecks, start at the source, then optimize everything else. Comment if you have questions.

Total Blocking Time (Milliseconds)	Recommendation
0–300	Good
300-600	Needs Improvement
Over 600	Poor

1. Find Long Main-Thread Tasks

In PageSpeed Insights, look at your longest main-thread tasks.

The URLs often tell you whether it’s from a specific third-party domain, plugin, jQuery (which is also needed for many plugins), etc.

Minimize main-thread work is basically the same report only it shows a more general picture. You can see whether you need to work on JavaScript, CSS, or other files. Any report affecting total blocking time shows the “TBT” abbreviation next to it like shown in the screenshot above.

2. Delay JavaScript

Third-party code is one of the biggest culprits of blocking time.

This usually happens when you install a bunch of tracking codes so you can track analytics (Google Analytics, Tag Manager, Heatmaps, Facebook Pixel, New Relic, and even reCAPTCHA or AdSense). Once you’ve removed third-party code you don’t need, you can usually delay the rest.

View your third-party code report and look at their JavaScript files:

WP Rocket delays most of these automatically while other plugins require you to add these manually (FlyingPress, Flying Scripts, LiteSpeed Cache, and Perfmatters are all manual). Choose a plugin for this and read through the plugin’s documentation since their steps can be different.

Here’s a list of common JavaScript files you can delay:

ga( '
ga('
google-analytics.com/analytics.js
analytics.js
gtagv4.js
analytics-minimal.js
/gtm.js
/gtag/js
gtag(
/gtm-
adsbygoogle.js
grecaptcha.execute
optimize.js
fbevents.js
fbq(
/busting/facebook-tracking/
disqus.com/embed.js
script.hotjar.com
wp-content/themes/script-name
wp-content/plugins/plugin-name

Then add them to your plugin:

Some plugins let you adjust the timeout. If you’re not seeing good results in PSI, try increasing it. But make sure you test this since delaying too long can impact things like AdSense revenue.

3. Remove Plugins Adding JavaScript

Still not sure which plugins add the most JavaScript?

Look at the coverage report in Chrome Dev Tools. You can filter by “type” to see all JavaScript files and see their total bytes, unused bytes, and URL (which usually has the plugin name in it). You could even search for Elementor to find CSS/JS files Elementor and its plugins are adding.

Query Monitor, WP Hive, and my list of 75+ common slow plugins are also useful resources.

4. Optimize Your Theme + Page Builder

Elementor and Divi add more CSS/JS than Gutenberg.

I recently switched to GeneratePress but there are plenty of other solid options that also use Gutenberg (like Blocksy and Kadence, although Kadence is definitely on the expensive side).

Don’t want to remove your page builder? Then optimize it.

Activate Built-in Performance Settings – Elementor’s Experiments and Divi’s built-in performance settings have several options to reduce and optimize CSS, JavaScript, and fonts. Even Elementor’s optimized DOM output can help since DOM size is part of total blocking time.

Don’t Install Heavy Page Builder Plugins – using slow page builders is bad enough, why make it worse? I get you may want more templates, but you have to be careful with those plugins too.

Code Your Header/Footer In CSS – CSS is much more lightweight than page builder code. You can still use a page builder to design pages, but these appear across your entire site. I hired WP Johnny to do it and my source code went from mentioning Elementor from about 2,000 to 200.

5. Remove JavaScript From Specific Content

Yep, we’re talking about asset unloading plugins like Perfmatters and Asset CleanUp. I like Perfmatters because it has many other optimizations not found in most cache plugins (or do a better job). Like remove unused CSS which does a better job than WP Rocket (see why in #14).

Some plugins and JavaScript files load across your entire site when they’re only being used in specific areas. By disabling these on specific pages/posts, you can remove unused JavaScript.

Once you choose a plugin, activate the script manager if needed, then enable test mode until you’re ready to publish changes. View any page on your site and click “script manager” in the top menu to see CSS/JS files loading on that page. I listed examples on disabling things below.

Examples:

• Disable social sharing plugin everywhere but posts.
• Disable contact form everywhere but contact page.
• Disable gallery plugins everything but pages with galleries.
• Disable elementor-diagolog if you’re not using it for Popups.

6. Remove jQuery

jQuery slows down your website and increases total blocking time. Felix Arntz from Google/WordPress wrote an article on how removing jQuery can lead to 80% less JavaScript.

Perfmatters has a script manager setting to show dependencies. Once enabled, head to “jQuery” in the script manager and you’ll see whether your plugins/theme depend on jQuery. This can mean removing plugins, replacing them with code or plugins that don’t use jQuery, and even changing themes. But this is worth it if you’re serious about making improvements.

If removing jQuery completely isn’t an option, you can just try removing jQuery migrate. Check Chrome Dev Tools to see if your website is using it.

If it’s not, disable it. Some optimization plugins do this or use jQuery Manager.

7. Minify JavaScript/CSS

Minification reduces file sizes by stripping unnecessary characters. If it breaks your site, you should find problematic files and exclude them rather than disabling the setting completely.

8. Test Combining CSS/JavaScript

Combining files is not recommended in the majority of cases especially for large sites or if you’re using HTTP/2 (which most websites are). This can actually increase total blocking time.

9. Make Sure Critical CSS Is Working

Most cache plugins have documentation to check whether critical CSS is working which can improve nearly all core web vitals: LCP, CLS, as well as total blocking time. So make sure it is.

10. Host Fonts Locally And Preload/Inline Them

Fonts can increase total blocking time especially if they’re not optimized.

Host Fonts Locally – instead of serving fonts from third-party domains like fonts.gstatic.com, many plugins have a setting to host fonts locally (like Elementor). FlyingPress and other cache plugins also do it. WP Rocket doesn’t so you may need to use something like Perfmatters/OMGF.

Preload Fonts – see the “avoid chaining critical requests” report and copy high priority fonts.

Preload fonts while testing results in a Waterfall chart (too many can actually have a negative impact). You should only preload fonts loading above the fold or when found in CSS files. Most cache plugins do this, use Perfmatters (shown below), Pre* Party , or you can do this manually.

Fonts should always be preloaded with the crossorigin attribute.

Inline Fonts – prevent requests from extra CSS and loads your fonts faster.

11. Defer JavaScript

Deferring JavaScript improves total blocking time by eliminating render-blocking resources.

Most cache plugins have a setting for this but it can sometimes break your site, in which case you’ll need to find any problematic files causing errors and exclude them from being deferred. Otherwise, you can use Async JavaScript. Install the plugin then click apply defer in the settings.

12. Optimize Images

Optimizing images improves total blocking time by keeping request counts low and transfer sizes small. There are multiple recommendations in PageSpeed Insights for optimizing images.

Having used multiple image optimization plugins, I can tell you CDNs are usually easier, more effective, and  prevents bloat added by image optimization plugins. Cloudflare Pro with image resizing, Mirage, and Polish are excellent and I use this with Rocket.net’s Cloudflare Enterprise. Bunny Optimizer is solid which you can also use on FlyingCDN when using FlyingPress. I don’t recommend RocketCDN (StackPath) which lacks many features – including image optimization.

• Properly size images – avoid huge images and resize them to correct dimensions. For example, my blog width is 765 pixels width so I crop my blog images to those dimensions.
• Defer offscreen images – lazy load them, but make sure all above the fold images are excluded and preloaded (or use fetchpriority). “Preloaded critical images” in FlyingPress and Perfmatters are best where you set a number of images usually shown above the fold.
• Compress images – Lighthouse tests images at 85% compression, so that’s what I’d use.
• Serve images from a CDN – make sure your CDN is serving images (as well as CSS/JS).
• Specify image dimensions – most cache plugins have a “add missing image dimensions” setting or you can manually add a width + height in the image’s HTML. Fixes layout shifts.
• WebP – most images CDN and image optimization plugins can serve images using WebP.
• Resize images for mobile – most image CDNs do this or use an adaptive image plugin. Otherwise, large images are served to mobile which can increase mobile load times/LCP.

13. Add Resource Hints

We already talked about preload in step 10, so what about prefetch and preconnect?

In the past, DNS prefetch was used for third-party domains. But you usually don’t need this anymore because most third-party code should be delayed. The other type of prefetch can be done in plugins like Flying Pages or FlyingPress where it will preload pages in the viewport. While this won’t improve total blocking time, it can make your site appear to load much faster.

<link rel="dns-prefetch" href="https://maps.googleapis.com">

Preconnect should usually only be used for third-party fonts like fonts.gstatic.com and CDN URLs. However, fonts should be hosted locally so there should be no reason to preconnect third-party fonts. CDN URLs are only used by CDNs like BunnyCDN or StackPath (not Cloudflare) which are usually preconnected automatically by your cache plugin when you add the CDN URL to your cache plugin’s settings. Which means again, there’s usually no need to do this manually.

<link rel="preconnect" href="/assets/vendor/gstatic" crossorigin>
<link rel="preconnect" href="https://cdn.yourdomain.com" crossorigin>

14. Remove Unused CSS

If your minimize main-thread work report shows styles are creating long tasks, removing unused CSS can help.

While the following cache plugins support this (WP Rocket, FlyingPress, LiteSpeed Cache, Perfmatters), you should ideally be using one of the last 3 options. When WP Rocket removes unused CSS, they load used CSS in inline HTML which increases HTML size and also means it’s not able to be cached. With the other 3 options, you’ll load used CSS in a separate file which is faster for real users. Therefore, WP Rocket may be better for “scores” but it’s slower for visitors.

15. Fix 4xx And 5xx Errors

If you have red errors in your GTmetrix Waterfall chart, it means there’s an error loading the request. As you see, it adds quite a bit of blocking time and wait time. You want to fix these.

FAQs

Cheers,
Tom

Общее время блокировки (TBT) — это один из показателей, отслеживаемых в разделе Performance отчета Lighthouse. Каждый показатель отражает определенный аспект скорости загрузки страницы.

В отчете Lighthouse TBT отображается в миллисекундах:

Что такое TBT

TBT — это общее время, в течение которого страница не может отвечать на пользовательский ввод, такой как щелчки мыши, касания экрана или нажатия на клавиатуру. Сумма рассчитывается путем сложения блокирующей части всех длительных задач в промежутке между первой отрисовкой контента (FCP) и временем до интерактивности (TTI). Длительной задачей считается любая задача, которая выполняется более 50 мс. Время свыше 50 мс считается блокирующей частью. Например, если Lighthouse обнаруживает задачу длительностью в 70 мс, блокирующая часть будет составлять 20 мс.

Как Lighthouse рассчитывает оценку вашего TBT

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

В этой таблице показано, как интерпретировать оценку TBT:

Как улучшить оценку TBT

Чтобы узнать, как при помощи панели «Производительность» в Chrome DevTools диагностировать основную причину появления длительных задач, см. статью В чем причина появления длительных задач?.

Вот наиболее распространенные причины появления длительных задач:

• Загрузка, обработка или выполнение ненужного JavaScript-кода. В ходе анализа кода при помощи панели «Производительность» может выясниться, что основной поток выполняет работу, которая на самом деле не требуется для загрузки страницы. Улучшить оценку TBT можно посредством сокращения полезной нагрузки JavaScript с помощью разделения кода, удаления неиспользуемого кода или эффективной загрузки стороннего JavaScript.
• Неэффективные JavaScript-инструкции. Например, предположим, что в ходе анализа кода при помощи панели «Производительность» вы обнаружили вызов document.querySelectorAll('a'), возвращающий 2000 узлов. Чтобы улучшить оценку TBT, можно перестроить код, заменив селектор на более избирательный, возвращающий только 10 узлов.

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

How to improve your overall Performance score

Unless you have a specific reason for focusing on a particular metric, it’s usually better to focus on improving your overall Performance score.

Use the Opportunities section of your Lighthouse report to determine which improvements will have the most value for your page. The more significant the opportunity, the greater the effect it will have on your Performance score. For example, the Lighthouse screenshot below shows that eliminating render-blocking resources will yield the biggest improvement:

See the Performance audits landing page to learn how to address the opportunities identified in your Lighthouse report.

Ресурсы

• Исходный код проверки Total Blocking Time (общее время блокировки)
• Увеличено ли у вас время до интерактивности (TTI) из-за длительных JavaScript-задач?
• Оптимизация времени ожидания до первого взаимодействия с контентом (FID)
• Первая отрисовка контента (FCP)
• Время до интерактивности (TTI)
• Сокращение размера полезной нагрузки JavaScript за счет разделения кода
• Удаление неиспользуемого кода
• Эффективная загрузка сторонних ресурсов

Updated on пятница, 4 июня 2021 г. • Improve article

Wondering what’s the Total Blocking Time metric and how it affects the performance of your WordPress site? You are at the right place.

We all love websites that are pleasant, easy to use, and fast. To make sure you provide a great user experience, there are a few metrics you should focus on, and TBT is one of them.

More importantly, as a user experience metric, Total Blocking Time holds up 30% of the global performance score computed by Lighthouse. This makes it a top metric for optimization! 

We are going to explain in detail what Total Blocking Time is, why it’s relevant, how to measure it, and what factors affect its score. We’ll also share some tips on fixing a bad Total Blocking Time grade (TBT longer than 300 ms) to improve your overall performance score and make your visitors happy. 

What is Total Blocking Time (TBT) in Lighthouse?

Total Blocking Time is an important performance metric that measures the load responsiveness of your WordPress site. It is the sum of all time periods between First Contentful Paint (FCP) and Time to Interactive (TTI) when a task length exceeds 50ms. The score is always expressed in milliseconds. It counts for 30% of your total performance grade performed by Lighthouse.

Lighthouse is an open-source, automated tool that assists developers in improving the quality of web pages. The tool considers six metrics to generate your final performance score, including the Core Web Vitals, the Speed Index, the Total Time to Interactive, and the Total Blocking Time: 

Metric	Weight	What’s a good score? (green)
First Contentful Paint	10%	0-2 s
Speed Index	10%	0-4,3 s
Largest Contentful Paint	25%	0-2,5 s
Time to Interactive	10%	0-5s
Total Blocking Time	30%	< 300 ms
Cumulative Layout Shift	15%	0 – 0,1

💡 If you need help to perform your website’s audit, we recommend reading our complete guide that explains how to improve your Lighthouse performance score. 

How to Measure Total Blocking Time

You can measure the TBT score by calculating the total amount of time that a page is blocked from responding to a user action. The total is calculated by adding the blocking time of all long tasks between First Contentful Paint (FCP) and Time to Interactive (TTI). 

Let me explain better.

Every browser has a process that transforms the code into a web page. This action of processing all the code and styles needs to be effective because we want our page to be rendered as quickly as possible for the visitor. (Remember, we want to make a good impression and show the user how fast our website is!)

The browser has many tasks to complete until it can render the page, such as parsing the HTML script, building the structure and the content of a web page (DOM), and executing its CSS and JS code. (That’s a lot to do, right?) 

To avoid a high blocking time, the browser should not encounter the JS and CSS files when parsing the code and rendering the page. To keep your website going fast, we have to “tell” the browser what we want to prioritize and what we want to load first.

Understanding Long Tasks

If the tasks run longer than 50ms, it is referred to as a Long task and considered “blocked.” 

In such a case, your page becomes unresponsive to user inputs like screen taps, keyboard presses, mouse clicks, etc. 

The calculation of Total Blocking Time is based on those Long Tasks. A Long Task significantly monopolizes the web browser (> 50 milliseconds) and blocks the performance of other essential tasks (such as reacting to user actions with a mouse click). The main thread is considered “blocked” any time there’s a Long Task. The computer records this interval for each request as an individual blocking time. The sum of all individual blocking times is called total blocking time.

Let’s see an example. Every time Lighthouse detects a Long Task (>50 ms) then it will also measure the blocking duration: 

As you can see, the Total Blocking Time is a sum calculated by adding the “blocking” portion of the different Long Tasks. The blocking portion of a Long Task is the part of its duration beyond 50 ms (in red on our chart).

Let’s see another task’s breakdown to identify the TBT: 

• The timeline below has five tasks, and three are Long Tasks (duration >50 ms):

• The next graph shows the blocking time for each of the long tasks, respectively 200 ms, 40 ms, and 105 ms (Total: 345 ms):

2 Tools to Measure Total Blocking Time

We recommend two different tools to measure TBT and your performance using the Lighthouse technology.

• Google PageSpeed Insight (PSI):

• GTmetrix:

Both tools provide a TBT score, but the numbers are slightly different, as you may have noticed.  This is mainly due to various factors, including Lighthouse implementation, testing methodology, testing location, etc. 

What’s a Good Total Blocking Time (TBT) Score?

You should always strive to have a TBT of less than 300 ms to ensure a good user experience. Your TBT score is simply a comparison of the TBT time of your page and the TBT times of high-ranking thousands of sites when loaded on mobile or desktop. 

Scoring is classified as:

• Green: 0-300ms (Fast)
• Orange: 300-600ms (Moderate)
• Red: 600+ms (Slow)

Total Blocking Time is often associated with the FID (First Input Delay) metric. Let’s see why. 

What Is the Difference Between Total Blocking Time and First Input Delay?

The difference between Total Blocking Time and First Input Delay is simple: while Total Blocking Time can be calculated without real-world users, First Input Delay is a field-only metric that requires real-user data for computations. 

The FID calculation cannot be simulated in a lab environment. This form of data comes from multiple sources, such as the Chrome User Experience Reports (CrUX), where the data collected are from real-world users. 

When your website does not have enough “real” data to compute the FID score, the alternative is to look at the TBT metric, measured in the lab data section. The lab data has artificial and collected data from a single device based on a fixed set of network conditions. 

In a different way, both TBT and FID measure interactivity and capture a user’s first impression of a site’s interactivity and responsiveness. 

For example, GTmetrix tests TBT instead of FID as it diagnoses almost the same optimizations with the suitable proxies:

By optimizing your Total Blocking Time, you’ll also improve the First Input Delay score, one of the Core Web Vitals metrics — there is a positive correlation between them. Of course, the opposite is also true.

If you keep your FID below 100ms, you’re in great shape: 

What Is the Difference Between Total Blocking Time and Time to Interactive?

The main difference is that Time to Interactive measures how long it takes for a page to become fully interactive, while Total Blocking Time tells you which JS tasks took the longest to execute.  

Time to Interactive is another metric that is related to your page interactivity. It’s one of the six metrics tracked in the Lighthouse report to measure the performance of your website. 

Measuring TTI is vital because some sites focus on content visibility at the expense of actual interactivity. This can create a frustrating user experience: the user thinks that the site is ready, but when he tries to click somewhere,  nothing happens. 

TTI (in orange below) marks a page as fully interactive if the main thread has been free of long tasks for about 5 seconds. 

Here’s a test for you. In the following image, when do you feel like you could interact? When does the blue-button become “clickable” in your mind? 

You should strive to have a Time to Interactive of less than 5 seconds to ensure a good user experience.

What Is the Impact of Total Blocking Time on Performance?

To understand the impact of TBT on performance, once again we should highlight its weight on the Lighthouse Score.

There are several basic principles to follow to keep your TBT under 300ms but first, let’s have a look at the causes of a bad TBT. 

What Causes a High Total Blocking Time? 

There are four reasons that determine a TBT score longer than 300 ms, namely:

1. A messy JavaScript code and unused JS 
2. A high JS Execution time
3. A high main thread work
4. Heavy use of a third-party code

Going to the opportunities and diagnostics section of your Lighthouse report will help in determining what solutions you can implement:

The report shows how much impact each error has on your estimated savings; resolving them will drastically improve your TBT and your site’s performance. 

Here is the list of the PageSpeed Insights recommendations to address if you want to improve your TBT score:

• Remove (or reduce) unused Javascript
• Reduce Javascript execution time
• Minify CSS and JS
• Eliminate render-blocking resources
• Reduce the impact of third-party code
• Enable text compression
• Avoid chaining critical requests
• Avoid enormous network payloads
• Minimize main thread work

(Spoiler alert: the majority of the TBT optimizations can be done using the WP Rocket plugin!)

How to Reduce Total Blocking Time Longer Than 300 ms on Your WordPress Site

To fix your TBT score longer than 300 ms, you should focus on the order and loading preferences of your resources, as well as the number and size of requests. The most effective way to reduce Total Blocking Time in WordPress is to optimize JavaScript files (including third-party code).  

Important: Any good measures going towards JS execution will most likely reduce TBT.

There are eight performance optimizations we recommend you implement if you want to fix Total Blocking Time and improve the speed of your WordPress site.

1. Defer JS
2. Delay JS
3. Prefetch DNS Requests 
4. Minify JS
5. Use GZip Compression
6. Minify CSS Files 
7. Optimize CSS Delivery
8. Reduce Server Response Time and Time to First Byte (TTFB) 

1. Defer JS 

Defer JS means to delay JS loading until a certain time. In this case, the JS files will be loaded after the browser has displayed the most relevant content. By deferring JavaScript files, you’ll make your JavaScript load faster – which is invaluable for improving your WordPress site’s performance. Reducing the amount of time spent in parsing, compiling, and running JS files also helps with improving TBT. 

Lighthouse issue from the diagnostic section: It addresses the “Eliminate render-blocking resources”, “Remove unused JavaScript” and “Avoid chaining critical requests” recommendations.

✅  Manual Solution: 

• Use the  Defer Attribute: When trying to defer JS you can use boolean attributes “defer” for the script tag in HTML:
  <script src=”code.js” defer></script>

 JS files will be executed only after the rest of the page has loaded.

✅  Use a WordPress plugin: 

• Asset CleanUp: this free plugin scans and detects the content to be loaded on the page. When editing a page, all you have to do is to select the CSS or JS code that is not useful. 
  Important Note: the plugin author recommends using Asset CleanUp with a cache plugin like WP Rocket to get the best results. 
• WP Rocket has an option to defer parsing of JavaScript and defer the JS WordPress files:

2. Delay JS

Delayed JavaScript Execution improves performance and TBT by delaying the loading of all JS files until a user interaction happens, such as touching the screen, scrolling, or clicking on a button. 

Lighthouse issue from the diagnostic section: It addresses the “Avoid chaining critical requests” recommendation.

✅ Manual Solution:

• The manual way of creating a delay in JS is to use the setTimeout ()method function. This will call a function after the time you’ll specify in ms. You can find very helpful code snippets to delay any JS functions, but here’s an example you can follow: 

Let’s say you want to achieve the following scenario: 

“User clicks on a button → Wait 2 seconds → the page will display a “Hello, How Are You?”:

<button onclick=”setTimeout(myFunction, 2000)”>Try it</button>

<script>

function myFunction() {

  alert(‘Hello, How Are You? ‘);

}

</script>

✅  Use a WordPress plugin:

• Flying Scripts: a plugin to delay JS and give more resources to critical JS files. It helps to prioritize. 
• WP Meteor: a plugin to postpone JS scripts and greatly improved the perceived speed by visitors (very important for the user experience).
• Gonzales: allows to conditionally disable CSS, JS, and even plugins depending on the page you visit.
• Asset CleanUp (just mentioned in the section above).
• WP Rocket cache plugin: the convenient way. You can easily delay the JS files in one single click.  

3. Prefetch DNS Requests 

DNS-prefetch is an attempt to resolve domain names before resources get requested.

✅ Manual Solution: 

• Use “rel=dns-prefetch” in the “head” section. In other words, you can manually specify the domain for the browser to prefetch:

<link rel=”dns-prefetch” href=”//yourdomain.com”>

✅  Use a WordPress plugin:

• Perfmatters plugin has the DNS prefetch options
• WP Rocket plugin also has a “Prefetch DNS Requests” section in its WordPress dashboard:
   

4. Minify JS 

Minifying your code means removing any clutter and useless punctuation: new lines, spaces, etc. You may always have some sort of content that is not required and consumes a lot of time, hindering your webpage from loading. By eliminating such ‘dead code’ from your script, you free up time for the main thread to focus on many important tasks.

Lighthouse issue from the diagnostic section:  It addresses the “Reduce JavaScript Execution Time“, “Minimize main thread work” and “Minify JS” recommendations.

✅  Manual Solutions:

• Do a backup of your site, or do not edit your JS files directly in a production server. 
• Use a text editor like Sublime Text or Visual Studio Code. We don’t recommend editing your code using Google Docs, for example — it adds some extra formatting.
• Open the file containing your code and remove the comments, white space, new lines, and indentations. Don’t forget to shorten ID, class, or variable names as much as possible and optimize your conditional statement. 

✅  Use a WordPress plugin:

• Closure Compiler by Google itself! It helps with the JS compression.
• Autoptimize plugin can also help you minify JS.
• WP Rocket allows you to minify your JS files in one click. 

5. Use GZIP Compression

GZIP compression enables your code to be compressed so that the files sent from the server to the visitor’s browser are smaller (and your website faster!) You can picture all your HTML, CSS and JS compressed together to obtain a smaller file, reduce TBT, and consequently increase performance.

Lighthouse issue from the diagnostic section: It addresses the “Enable text compression” recommendation.

✅  Use a WordPress plugin: 

• Enable GZIP Compression plugin gives you the possibility to enable and disable Gzip compression on your WordPress site.
• WP Rocket enables GZIP compression automatically. You can read more about GZIP compression in our documentation. 

6. Minify CSS Files 

This lowers your file sizes by removing comments, redundant code, and whitespaces. The idea is that you want to reduce as much time as possible, and these traits are not necessary to run the page. Doing so will reduce CSS load and overall parsing time. 

Lighthouse issue from the diagnostic section: It addresses the “Minimize main thread work” and “Minify CSS” recommendations.

✅  Manual Solutions (for more details, please refer to the JS section above):

• Do a backup of your site, or do not edit your CSS files directly in a production server. 
• Use a text editor like Sublime Text or Visual Studio Code. 

✅  Using a web tool: 

• Go to minifycode.com and click the CSS minifier tab.
• Paste the CSS code into the input box and click the Minify CSS button.

✅  Use a WordPress plugin: 

• Autoptimize
• WP Super Minify 
• CSS Nano
• WP Rocket cache plugin which helps you minify your CSS in one click:

7. Optimize CSS Delivery 

Minimizing the main thread frees up your browser to handle other tasks required for the web page to run efficiently. Some events, such as CSS parsing, can block the main thread from handling other tasks and processes. Therefore, it’s essential to optimize the way CSS is delivered. 

Lighthouse issue from the diagnostic section: It addresses the “Minimize main thread work” recommendation.

✅  Manual Solutions: 

• Combine and compress your CSS scripts
• Prioritize CSS rules for the above-the-fold content
• Avoid using STYLE tags in the HTML body

✅  Use a WordPress plugin: 

• The WP Rocket cache plugin helps you optimize your CSS delivery in one click, thanks to the Remove Unused CSS option.

8. Reduce Server Response Time and Time to First Byte (TTFB) 

Your server needs to be fast, and your TTFB needs to be optimized to improve the TBT score.

Lighthouse issue from the diagnostic section: It addresses the “Reduce initial server response time” recommendation.

✅  Use an advanced cache plugin and a CDN:

• WP Rocket cache plugin and RocketCDN will help you to reduce the TBT score.

How to Fix the TBT Score With WP Rocket

As mentioned previously, the execution of JavaScript is the most important factor that affects the TBT metric. By delaying and deferring JavaScript using WP Rocket, you’ll give your WordPress site a little speed boost.

You can use several WP Rocket features to reduce the impact of TBT and improve its score.

Let’s take a look at a case study.

Running the PageSpeed Insights Audit

We’ve audited the website of a French caterer named “Le point Gourmand…” using Google PageSpeed Insights. 

Let me share with you what we did to get the following performance results:

Lighthouse’s score before WP Rocket: 51/100

• In orange: TBT was 480 ms and TTI 7,0 s 
• In red: Speed Index was 6,0 s and LCP 7,1 s

Lighthouse’s score after using WP Rocket: 95/100

• In orange: Only the LCP needs to be fixed, but we can notice that it has significantly improved.
• In Green: Speed Index, FCP, TTI, CLS, and… TBT! 

The diagnostic and opportunities sections were not so great when I performed my first audit without using the WP Rocket cache plugin. The issues found by Lighthouse were impacting my TBT and my global performance score. 

As seen previously, the TBT score is mainly impacted by issues like messy and unused JS, a high JS Execution time, high main-thread work, and a third-party code that takes up all the resources. 

According to the audit, my website was not in very good health, and many JS/main-thread issues were found: 

Enabling the WP Rocket Features

Upon activation of WP Rocket, I went to the settings section of my WordPress site, and I made sure to activate the following options:

1. Optimization of JS files (Defer and Delay)

2. Optimization of CSS files

3. URLs to prefetch

I’ve added a couple of URLs to prefetch, and it increased my score again:

4. Preload fonts

Lighthouse also found a performance issue regarding the fonts and the icons used on the website. I fixed it using the WP Rocket “Preload fonts” tab:

• Expand the “Preload Key Requests” section in PSI to identify the URLs containing the issues. 
• Copy the URLs provided by Lighthouse.
• Paste them in the “Preload Fonts” section in your WP Rocket dashboard.

Achieving Excellent Performance Results

Finally, my “Passed audits” list has significantly grown, and some issues like “Minify JS”, “Minimize main-thread works,” “Remove unused JS” or “Eliminate render-blocking resources” are gone thanks to WP Rocket.  

I’ve summarized my audit in the table below to highlight the main challenges overcome:

Lighthouse recommendations that impact the Total Blocking Time	Can it be solved by WP Rocket?
JS related issues: Eliminate render-blocking resources and Remove unused Javascript	Yes – In a few clicks, you’ll defer and delay JS and clean up the code.
Minify CSS and Optimize CSS delivery.	Yes – By minifying CSS and use the Optimize CSS Delivery option, you’ll address the PSI recommendations.
Minify third-party usage and Preconnect to required origins	Yes – You can use the Prefetch DNS feature.
Reduce JS Execution Time	Yes – In a few clicks, you’ll minify, delay, and defer JavaScript and improve JS execution time.
Minimize main-thread work	Yes – By deferring, delaying, and minifying JS and CSS, you’ll take care of the PSI recommendation.
Reduce initial server response time	Yes – By using caching and a CDN, you’ll reduce the Time to First Byte.

Wrapping Up 

Hopefully, this guide has helped you to understand how to optimize your TBT score for your WordPress site using some concrete steps. 

Total Blocking Time is an important user-centric performance metric as it counts for 30% of the Lighthouse performance grade. A slow website can drive away potential visitors and customers, hurt your site’s User Experience (UX), and even impact your SEO. 

The easiest and most convenient way to get a great TBT score is by installing WP Rocket which applies 80% of web performance best practices right upon activation. 

You can always count on our 100% money-back guarantee. Although we don’t think you’ll ever want one, we’ll gladly provide a refund if you request it within 14 days of purchase.

🚀 The only risk you’ll be taking with our plugin is speeding up your website!