Total blocking time как уменьшить

Оп­ти­ми­за­ция мет­рик Web Vitals с по­мо­щью Lighthouse

В этой статье мы рассмотрим новые возможности инструментов Lighthouse, PageSpeed и DevTools, чтобы помочь разобраться с тем, как улучшить ваш сайт по метрикам Web Vitals.

Коротко вспомним, что это за инструменты. Lighthouse — это автоматический, постоянно обновляемый инструмент с открытым кодом для улучшения качества страниц. Вы можете найти его в инструментах разработчика Chrome DevTools и запустить в нём любые страницы: публичные или скрытые за авторизацией. Вы также можете найти Lighthouse в PageSpeed Insights, CI и WebPageTest.

Lighthouse 7.x включает новые возможности, например, скриншоты элементов интерфейса, влияющих на пользовательские метрики, вроде тех, что вызывают смещение раскладки.

Мы также добавили возможность делать скриншоты элементов страницы в PageSpeed Insights, чтобы легче было найти проблемы, которые возникают при разовой загрузке страницы.

Метрики Core Web Vitals Скопировать ссылку

Lighthouse может синтетически измерять метрики Core Web Vitals, включая Largest Contentful Paint, Cumulative Layout Shift и Total Blocking Time (аналог First Input Delay для измерения в лабораторных условиях). Эти метрики отражают загрузку, стабильность раскладки и готовность страницы к взаимодействию. Также есть и другие метрики, такие как First Contentful Paint, с запасом на будущее Core Web Vitals (CWV).

Раздел «Metrics» в отчёте Lighthouse включает лабораторные версии этих метрик. Его можно использовать как обзор аспектов пользовательского опыта, которые требует вашего внимания.

Lighthouse фокусируется на оценке пользовательского опыта при начальной загрузке страницы в лабораторных условиях, эмулируя медленный телефон или десктоп. Если сдвиги макета или длительные JavaScript-таски возникнут на странице уже после её загрузки, лабораторные метрики этого не отразят. Для измерения показателей после загрузки страницы стоит обратиться к вкладке «Performance» инструментов разработчика, Search Console, расширения Web Vitals или RUM.

Полевые метрики, которые вы можете найти в отчёте Chrome User Experience (CrUX) или в RUM, не имеют этих ограничений и полезно дополняют лабораторные метрики. С другой стороны, полевые данные не могут предоставить диагностическую информацию, которую вы можете получить от лабораторных метрик, вот так они и сочетаются вместе.

Где можно улучшить метрики Web Vitals Скопировать ссылку

Largest Contentful Paint (LCP) Скопировать ссылку

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

В Lighthouse есть отчёт «Largest Contentful Paint element», который позволяет выделить такой LCP-элемент. Если навести на элемент в отчёте, он подсветится на странице.

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

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

Предзагрузка картинок для улучшения LCP Скопировать ссылку

Чтобы улучшить метрику LCP, вы можете предзагрузить хиро-картинки (например, обложки статей — прим. редактора), если браузер находит их слишком поздно. Одна из причин позднего обнаружения картинок — если сначала нужно загрузить JS-бандл, чтобы узнать о картинках, которые нужно загрузить.

Предзагрузкой нужно пользоваться аккуратно. Пропускная способность соединения на первом этапе загрузки страницы невелика и предзагрузка картинок может повлиять на загрузку других важных ресурсов. Для эффективной предзагрузки убедитесь, что ресурсы расположены в правильном порядке, чтобы не привести к ухудшению других метрик, когда другие ресурсы тоже считаются важными (например, критический CSS, JS, шрифты). Читайте подробнее о цене предзагрузки (Google Docs).

Начиная с версии 6.5, Lighthouse предлагает возможности для применения этой оптимизации.

Есть несколько популярных вопросов о предварительной загрузке LCP-картинок, которые стоит рассмотреть.

Можно ли предварительно загрузить адаптивные картинки? Да, можно. Скажем, у вас есть набор хиро-картинок для разных размеров экрана, которые описаны с помощью srcset и sizes , например:

Благодаря атрибутам imagesrcset и imagesizes , добавленным в , вы можете предзагрузить адаптивные картинки, используя ту же логику из srcset и sizes :

Подсветит ли отчёт возможности предзагрузки, если LCP-картинка задана с помощью CSS-фона? Да, конечно.

Любая картинка, помеченная как LCP (будь то или фоновая картинка в CSS), это кандидат для аудита, если она обнаружена в водопаде на глубине три уровня и больше.

Поиск влияний на CLS Скопировать ссылку

Кумулятивный сдвиг раскладки (Cumulative Layout Shift, CLS) — это оценка визуальной стабильности. Она показывает, насколько контент страницы визуально сдвигается во время загрузки. Lighthouse содержит специальный отчёт «Avoid large layout shifts» для отладки CLS.

Этот отчёт выделяет элементы DOM, которые вносят основной вклад в сдвиги на странице. В колонке «Element» отчёта Lighthouse вы увидите список таких элементов DOM, а справа — их вклад в CLS.

Благодаря новой возможности Lighthouse делать скриншот элемента мы теперь можем видеть превью ключевого элемента из отчёта и увеличивать его для более детального просмотра:

Для CLS после загрузки страницы, бывает полезно обозначить элементы, которые оказали наибольшее влияние на сдвиг раскладки. Это можно найти в сторонних инструментах, например, в панели Core Web Vitals от SpeedCurve или в Layout Shift GIF Generator от Defaced, который мне очень нравится:

Для анализа сдвигов раскладки для всего сайта мне помогает отчёт Core Web Vitals, который создаёт Google Search Console. Этот отчёт позволяет видеть страницы сайта с высоким значением CLS, что помогает понять, на какие файлы шаблонов мне стоит обратить внимание прежде всего:

Чтобы улучшить показатель CLS для веб-шрифтов, обратите внимание на новый дескриптор size-adjust для @font-face . Он позволяет изменять размер базовых шрифтов для уменьшения значения CLS.

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

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

Читайте статью «Setting Height And Width On Images Is Important Again» для лучшего понимания важности указания размеров и соотношения сторон для картинок.

Поиск влияния на CLS от рекламы Скопировать ссылку

Отчёт «Publisher Ads для Lighthouse» позволит вам найти возможности загрузку рекламы на ваших страницах, включая роль рекламы в сдвиге раскладки и долгих операций, которые могут отложить интерактивность страницы для пользователей. Вы можете включить этот инструмент в Lighthouse с помощью Community Plugins.

Помните, что рекламные баннеры — это элементы, которые по статистике вносят наибольший вклад в сдвиг раскладки. Важно:

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

Избегайте раздельных анимаций Скопировать ссылку

Анимации, не объединённые в общий композитный слой рендеринга, могут дёргаться на слабых устройствах, если исполнение сложных JavaScript-тасков занимает главный поток. Такие анимации могут вызывать и сдвиги раскладки.

Если Chrome обнаруживает, что анимация не может быть выделена в отдельный слой, он сообщает об этом в DevTools. Это позволяет составить список всех элементов, для которых анимация не была композитной и выяснить причину. Вы можете найти эту информацию в отчёте «Avoid non-composited animations».

Отладка метрик FID, TBT, LT Скопировать ссылку

Метрика First Input измеряет время от первой попытки взаимодействия со страницей (например, когда они кликают по ссылке, кнопке или использую JS-контрол), до момента, когда браузер действительно начинает обрабатывать события в ответ на это взаимодействие. Долгие JavaScript-таски могут повлиять на эту метрику и на её прокси-метрику Total Blocking Time.

Lighthouse включает отчёт «Avoid long main-thread tasks», которая перечисляет долгие таски в основном потоке. Это помогает отыскать самое большое влияние на задержку первого взаимодействия. В левой колонке вы можете увидеть адрес скрипта, ответственного за долгие таски в главном потоке.

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

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

Блокировка сетевых запросов в Lighthouse Скопировать ссылку

Инструменты разработчика Chrome поддерживают блокировку сетевых запросов, чтобы увидеть вклад каждого из загружаемых ресурсов, если они доступны или нет. Это может оказаться важным для понимания вклада каждого отдельного скрипта, который может повлиять на такие метрики, как Total Blocking Time (TBT) и Time to Interactive (TTI).

Блокировка сетевых запросов также работает в Lighthouse! Давайте взглянем на отчёт Lighthouse для сайта. Например, «Performance» выдаёт 63 из 100 очков с TBT, равным 400 мс. Покопавшись, мы найдём загрузку полифила Intersection Observer в Chrome, который для этого браузера не нужен. Заблокируем его!

Мы можем кликнуть правой кнопкой на скрипте в инструментах разработчика на панели «Network» и выбрать «Block request URL». Здесь мы сделали это для полифила Intersection Observer.

Затем мы перезапускаем Lighthouse. На этот раз мы видим улучшение показателя Performance (70/100) и Total Blocking Time (с 400 мс до 300 мс).

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

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

Один из способов улучшения скорости загрузки таких виджетов — ленивая загрузка во время взаимодействия. Это может быть реализовано с помощью лёгкой заглушки виджета: полная версия загрузится только тогда, когда начнётся взаимодействие. В Lighthouse есть отчёт, который рекомендует сторонние решения для ленивой загрузки с заглушкой, например, для видео с YouTube.

Напомню, что Lighthouse будет подсвечивать сторонний код, который блокирует основной поток более, чем на 250 мс. Это поможет обнаружить все сторонние скрипты (включая собственные Google), которые стоит отложить или загрузить лениво, если результат их рендеринга прячется за прокруткой.

Не только Core Web Vitals Скопировать ссылку

Помимо использования Core Web Vitals, последние версии Lighthouse и PageSpeed Insights также пытаются обеспечить разработчиков конкретными советами для ускорения тяжёлых JS-приложений, если у вас включены карты кода.

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

За подробностями об инструментах Core Web Vitals следите в Твиттере команды Lighthouse, а также в разделе What’s new in DevTools.

Основные метрики скорости загрузки сайта: TTFB, FCP, LCP и другие

06.12.2022

• Основные метрики скорости загрузки сайта
• Как проверить скорость загрузки сайта
• Как улучшить показатели скорости

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

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

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

Основные метрики скорости загрузки сайта

TTFB (Time To First Byte) — промежуток времени от момента отправки запроса на хостинг, на котором размещен сайт, до первого байта полученной ответной информации. Между двумя фазами происходит немало событий — перенаправление, поиск DNS, согласование по TLS и другие. Все эти процессы лаконично называют «обработкой запроса». TTFB — важный для сайта показатель, который должен составлять не более 2-3 секунд.

FCP (First Contentful Paint) – время до того, как пользователь увидит на сайте первый контент; первичный, частичный рендеринг. Эта метрика не учитывает показатель загрузки iframe, подразумевается текст (включая тот, к которому еще не подгрузились шрифты), изображения или элементы canvas (холст, который выглядит как плашка не белого цвета). Оптимальное время — до 1.8 секунды.

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

FID (First Input Delay) — время от первого взаимодействия пользователя с интерактивными элементами (нажатие кнопки, ввод текста в поле, переход по ссылке) до того момента, когда браузер начинает отвечать на них. Этот процесс должен происходить в течение 1 секунды или менее. Время ожидания ответа также является важной метрикой для репутации сайта, ведь пользователю не нравится, когда он нажимает на кнопку, но ничего не происходит.

TTI (Time To Interactive) — дословно переводится как «время до интерактивности», когда основной контент уже подгрузился и пользователь не только видит интерактивные элементы, но может полностью взаимодействовать с ними.

INP (Interaction to Next Paint) – показатель скорости отклика страницы на действия пользователя, которые происходят уже после полной загрузки сайта. Это промежуток времени, проходящий между кликом по элементу и ответом на него. Оптимальна скорость реакции до 200 миллисекунд.

TTB (Total Blocking Time) — общее время блокировки, которое проходит от начала рендеринга контента (FCP) до интерактивности сайта (TTI). В этот период пользователь уже видит наполнение, но не может нажимать кнопки и другие активные элементы. Хорошим считается показатель в 300 миллисекунд.

CLS (Cumulative Layout Shift) — смещение макета из-за подгрузки более тяжелых элементов. Представим, что пользователь открыл сайт, увидел нужную ссылку и кликнул по ней, но в этот момент выше раскрылся блок (видео или изображение), который долго грузился. Поэтому макет сместился, ссылка «поехала» вниз, пользователь кликнул вместо нее по рекламе, и началась загрузка сайта рекламодателя. Такие скачки макета раздражают, поэтому CLS считается одним из ключевых показателей, который анализируют все основные инструменты измерения скорости. В 2021 году были утверждены новые правила оценки этой метрики, и теперь за основу берется временное окно продолжительностью до 5 секунд, когда происходят смещения с перерывом менее чем в 1 секунду.

Speed Index — демонстрирует скорость отображения контента в процессе загрузки. К примеру, основной контент подгрузился на сайте за 4 секунды. Но в одном случае в течение первых трех секунд пользователь видит только белый экран, а во втором уже на первой секунде начинается рендеринг мельчайших деталей, заголовков, плашек. Вроде в обоих случаях сайт загрузился за одно и то же время, так какая разница, что происходило на экране? Но пользователю лучше видеть хоть какое-то движение на странице, чем просто ждать, созерцая статическое белое поле. Поэтому, даже если в процессе появляются не слишком информативные блоки, они дают понять, что сайт грузится. Это оказывает положительное влияние на пользовательский опыт.

Core Web Vitals — это три основных метрики, которые Google выделяет как наиболее важные. К ним относится рендеринг большей части контента, время первой интерактивности и совокупное смещение контента (LCP, FID, CLS).

Как проверить скорость загрузки сайта

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

Результаты сканирования с помощью расширения Lighthouse

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

Основные инструменты проверки скорости сайта:

• WebPageTest
• GTmetrix
• Pingdom Website Speed Test
• Lighthouse
• Расширение Web Vitals для Chrome
• Google PageSpeed Insights

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

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

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

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

Следуйте советам, предложенным сервисом анализа скорости

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

Оптимизируйте контент, код и базу данных

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

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

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

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

Вы можете использовать для этого различные инструменты или ручные методы, но большинство упомянутых опций есть в модуле PageSpeed, доступном для активации прямо на хостинге. В панели клиентов Cityhost он активизируется в разделе Хостинг 2.0 => Управление => Сайты. Во время активации можно включить все доступные функции, а можно выбрать только нужные вам.

Используйте на CMS только необходимые модули

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

Подключите серверное кэширование

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

Выбирайте качественный хостинг

Для сайта понадобится виртуальный хостинг или аренда сервера (VPS или выделенного) – все зависит от его ресурсоемкости. Но всегда нужно помнить, что техническое состояние серверов влияет на скорость загрузки страниц. Ответственный провайдер использует качественные комплектующие, заботится об их своевременной замене и мониторит работу серверов.

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

Понравилась статья? Расскажите о ней друзьям:

Автор: Богдана Гайворонская

Журналист (с 2003 года), IT-копирайтер (с 2013 года), контент-маркетолог Cityhost.ua. Специализируется на статьях о технологиях, создании и продвижении сайтов.

Технический консультант: Андрей Заровинский

Руководитель команды технической поддержки Cityhost, автор инструкционных материалов в разделе FAQ. Обучает персонал технической поддержки и помогает решать самые сложные запросы от клиентов.

Оптимизируем метрики сайта на Magento 2

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

Преамбула

. о базовых принципах браузеров.

Загрузка каждого файла (в частности JS) состоит из этапов: загрузки, execution (который в свою очередь состоит из парсинга и компиляции).

Загрузка

Загрузка файлов происходит параллельно. Но если сервер или ваш браузер не поддерживает протокол http2, то количество параллельно загружаемых файлов будет ограничено. Все современные браузеры (даже мобильные) уже поддерживают протокол http2. И сейчас все серверы тоже стараются его использовать. Так что, идейно переживать за количество JS файлов (и «лепить» громоздкие bundling-и) не стоит.

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

Мы протестировали наш девсайт на Magento 2.4.

• Суммарный размер JS-файлов: 3.97MB.
• FCP/LCP — 4.088s (это тестовый сайт, так что не обращайте внимания).

С bundling (тестировался разный размер бандла: 50/100/250 KB):

• Суммарный размер JS-файлов: ~7MB.
• FCP/LCP — ~5s.
• Остальные метрики были хуже на ~30-60%.

(если на сервере настроен http2)

Execution

Каждый JS-файл браузеру нужно распарсить и выполнить. И если загрузка может происходить параллельно, то «выполнение» (execution) происходит в основном потоке процессора по очереди. Выполнение JS файлов — самый «прожорливый» процесс и создает основные блокировки по рендеру сайта:

(не считая время загрузки).

Но выполняется не только JS. «Разукрашивает» страницу тоже CPU в том же потоке.

Советы по оптимизации JS execution

Что можно сделать для оптимизации:

1) Чем меньше размер JS файлов в целом на странице, тем меньше время их парсинга. Вы можете не грузить какие-то массивные куски кода, которые редко используются.

Пример: кнопка чата на страницах сайта (вот та назойливая в нижнем углу, на которую кликает процентов а остальные должны грузить ваш скрипт каждый раз на каждой странице). Вам нужно просто создать кнопку «такую же как в чате», по клику на которую будет загружаться в DOM и выполнятся JS вашего чата. Такой чат откроется не моментально, но добавить прелоадер — и пользователь уже не будет нервничать (т. к. он сам вызвал это действие). Да и ждать ему придётся, скорее всего, не больше секунды. И для пользователей (и для метрик) вы улучшите показатели.

Или это может быть сторонний поиск (например, Алголия). Или карты. Вот ещё статья по этому поводу.

2) Также сложные куски JS обрабатывать в отдельном потоке. По данному пункту («однопоточный JavaScript и как с этим бороться») можно долго говорить. Выйдет статья не меньше этой. В двух словах: использовать «webworker». Пару статей:

1. webworker-ы и асинхронность
2. Webworker-ы

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

Не уверен, что асинхронность (описанная в MDN Web Docs) спасёт при самой загрузке страницы. Это более полезно для оптимизации взаимодействия с пользователем.

Также можно трудоемкие куски выносить «в конец» потока. Каждый раз, когда вы используете setTimeout/setInterval — код внутри этих методов помещается в конец потока и будет выполнен только после того, как выполнит весь остальной JS код.

Если в двух словах: можно отложить выполнение JS до тех пор, пока не распарсится весь DOM. Это хорошо для скриптов с domready() и тех, которые не нужны, пока пользователь не кликнет на что-то (скрипты поиска, гугл карты в попапах, да и вообще все что касается невидимого контента). Выполнять такие скрипты во время парсинга самой страницы — нет смысла. Поэтому им смело можно прописывать атрибут «defer». Только не путать с «перенесением JS в footer страницы» (о чём будет дальше).

НО! На деле не всё так просто.

По первому пункту. Как говорится: «из песни слов не выкинешь». Хотя, по-хорошему, желательно стараться писать код «без излишеств». «Краткость — сестра таланта».

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

По третьему пункту. Если вы подключаете JS-файлы «вручную» — то добавить необходимые атрибуты не составит труда. А вот если у вас какой-то фреймворк/CMS, то уже будет зависеть от возможностей самой системы.

Итого

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

• Стараться писать код «сразу нормально». Планировать необходимый код до начала разработки. Что бы не повторять один и тот же код и не писать лишнего в целом.
• Если часто используете один и тот же сторонний ресурс или функциональные блоки (чат, поиск) — есть смысл разработать фичу «отложенной инициализации» (пункт 1). Это может занять время, но вы это сделаете один раз и будете с легкостью применять на следующих проектах.
• Разобраться с инструментами, позволяющими выполнять пункт 3. Это может занять время, но вы это сделаете один раз и далее будет проще применять на следующих проектах. Хотя лично мне больше нравится подход описанный немного дальше («Дополнительно по оптимизации»).

Советы по оптимизации CSS execution

Задействуйте GPU

Отрисовка страницы также происходит посредством CPU. На графическое ядро браузер передаёт только «композитные слои». В композитный слой элементы могут попадать сразу или «по необходимости». Сразу в композитные слоя выносятся:

• 3D-трансформации: translate3d, translateZ и т.д.
• Элементы , , .
• Анимация «transform» и «opacity» через Element.animate().
• Анимация «transform» и «opacity» через CSS Transitions и Animations.
• «position: fixed».
• will-change.
• filter.

Вот визуальный пример того, что когда выполняется JS, всё остальное «замирает».

Но не переусердствуйте, т. к. может закончиться память. Ведь любой элемент это массив пикселей: x x . «Количество байт на пиксель» обычно 3 (RGB). А в случае с прозрачностью, то 4. Т.е. квадрат 100×100 занимает 30 000 байт (если с прозрачностью, то 40 000 байт).

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

Более подробно в статьях тут и тут.

Вообще старайтесь писать компактный CSS.

Используйте поменьше наследования в классах

.page-products .column.main .box-store-locator .store-locator .box-current-store-info .current-store-hours-title <>

Можно сократить (если не ещё больше):

.page-products .store-locator .box-current-store-info .current-store-hours-title <>

Особенно это касается LESS/SASS стилей, где визуально вложенность не кажется «такой громоздкой».

Если вы удалите промежуточные классы для ~ 100 строк, вы сэкономите ~ 1 КБ.

А ещё лучше — используйте методику BEM. Тогда для указания элемента вам понадобится прописать всего один класс.

Не используйте картинки

Часто вижу, что для стрелочек или других простейших иконок используют картинку (svg/jpg/png в виде фона).

Ни одна картинка не будет меньше пары строк CSS. Тем более, что CSS вы потом минифицируете и он ещё сожмётся при передаче.

Группируйте селекторы

Если говорить про Мадженту, то там «из коробки» есть метод «&:extend()».

Аналитика

Где протестировать

Все знают про «PageSpeed insights» от Google. Но помимо него есть и другие способы.

PageSpeed insights

• Удобен тем, что дает много конкретных рекомендаций со ссылками (с учетом платформы, на которой разработан сайт).
• Сразу анализирует мобилку и десктоп.
• Может показать данные с реальных устройств. Если вашу страницу посетили более 500 раз за месяц с Chrome-браузера, то в начале страницы (над лабораторными данными), вы увидите основные метрики «в реальной жизни». Среднее значение за последних 28 дней. (т. к. JS/CSS/картинки кэшируются браузером и показатели на самом деле могут быть лучше).

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

GTmetrix

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

WebPageTest

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

Lighthouse

Плагин для браузера Chrome.

«PageSpeed insights» от Google использует Lighthouse. Так что вы получите такие же данные, только быстрее и без проблем (не будет случаев что анализ «отвалится»). А самый главный бонус: можно тестировать локальные сайты.

Мини вступление

Основные две составляющие программ аналитики:

1. Время отрисовки страницы/контента, которое по факту прямолинейно размеру/вложенности HTML-я, размерам JS/CSS/картинок.
2. Поведение страницы во время загрузки и после.

Поведение страницы во время загрузки и после

Стоит начать со второго т. к. там всё просто: во время и после загрузки страницы, контент должен оставаться на своём месте. В метриках эта характеристика называется «Cumulative Layout Shift (CLS)».

Немаловажная оговорка «. и после». Т. к. при скролле страницы,и взаимодействию с ней элементы по-прежнему должны оставаться на своих местах. При загрузке такие вещи в аналитику не попадут. Но попадут в статистику «реальных данных» в «PageSpeed insights».

Cumulative Layout Shift (CLS)

Контент не должен «прыгать» (менять положение). Например, если на странице есть баннер, но он не загружается сразу, то для него должно быть «зарезервировано» пустое место. Эти «сдвиги» важны даже при прокрутке страницы.

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

new PerformanceObserver(l => < l.getEntries().forEach(e =>< console.log(e); >)>).observe();

new PerformanceObserver(l => < var i = 0, sum = 0; l.getEntries().forEach(e =>< console.log(e); sum +=e.value; i++; >) console.log(’Total’, i); console.log(’Summa’, sum);>).observe();

В консоли будут отчеты обо всех сдвигах.

Одиночные «value» до 0,1 не важны. Но важна общая сумма. У вас может быть 200 сдвигов со значением 0,1, и в итоге вы получите 20% shift. Также в логах будут указаны блоки, которые двигались (это означает, что-либо сам блок движется, либо блок перед ним внезапно «вздулся» и сдвинул нижние).

Начните исправлять CLS сверху. Сдвиги в заголовке очень важны. Реальный пример: удалил этих пару пикселей:

И получил +0,012 балла (1,2%). Также исправил сдвиг на 600 пикселей в нижнем колонтитуле и получил около 1%.

Блоки с позицией «fixed» игнорируются.

Метрики загрузки страницы

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

• First Contentful Paint (FCP). Первая визуализация, когда появляется текст или изображение. Очень важный параметр.
• Largest Contentful Paint (LCP). Показывает, когда появляется самый большой блок. Очень важный параметр.
• Time to Interactive (TTI). Время, когда пользователь уже может взаимодействовать со страницей.
• Total Blocking Time. Время, когда страница не интерактивна из-за того что процессор занят «выполнением» контента страницы (см. Преамбула -> Execution).
• Speed Index. Мнимая величина, которая вытекает из вышеперечисленных.

«Speed Index» отдельно можно не поднимать. Он сам улучшится, когда улучшатся остальные показатели.

«Total Blocking Time» и «Time to Interactive»

Чем быстрее отрисуется страница, тем быстрее она будет доступна для взаимодействия (скролл, клик на интерактивные элементы, анимация).

Для уменьшения «Total Blocking Time» и ускорения «Time to Interactive» нужно разгрузить «основной поток». См. «Советы по оптимизации» выше и следующий абзац и «будет вам счастье»:)

Дополнительно (глобально) по оптимизации

По факту, как уже и говорилось, все показатели метрики напрямую зависят от размера страницы и подгружаемого контента. И вы можете сказать: «Ну не могу же я удалить то или это. Клиент заказал и оно должно быть». Ка бы да, и нет. Вспоминаем пример с кнопкой чата.

И вот ещё интересный пример. У сайта показатели И в основном благодаря тому, что они ВЕСЬ JS загружают с задержкой. По принципу «lazy-load». Теги вместо атрибута «src» содержат атрибут «data-src». И в конце страницы инлайновый JS код, который по истечению определённого времени (или при скроле, если тот будет раньше) создает теги с нужным «src» (и атрибутом «async»). В итоге загружается страница размером 1МБ за пару секунд. А остальные 15 МБ «подтягиваются» позже.

В результате пользователь видит страницу сразу, показатели метрики отличные. Единственный минус — на сайте сразу ничего не накликаешь т. к. ничего толком не работает. Слайдеры, меню, попапы, дропдауны, корзина. Всё станет динамичным только через 10 секунд (или через несколько секунд после скролла, но всё равно не сразу). Но какова вероятность, что пользователь сразу же кинется кликать на слайдеры или меню?

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

Если вдруг кто «первый раз слышит», то немедленно ознакомьтесь. Вот несколько статей тут, тут и тут.

Если говорить про Мадженто, то с версии 2.4 уже есть частичная поддержка «из коробки»: на странице категории изображения продуктов подгружаются «лениво». Но одного каталога, честно сказать, маловато. Обычно на домашней странице и странице продукта тоже много больших картинок. И тут уже придётся либо «что-то придумывать», либо использовать модули (которые для Мадженты есть даже бесплатно).

Про формат/размер изображений, минификации, сжатие данных сервером (Gzip, Deflate) и прочее не будем тоже останавливаться. Если вы с этим ещё не разбирались, то тулзы тестирования сайта вам подскажут.

А теперь разберём ещё две важные метрики (на раду с CLS): FCP и LCP.

First Contentful Paint (FCP)

FCP time(in seconds)	Color-coding	FCP score(HTTP Archive percentile)
Green (fast)
Orange (moderate)
Over 4	Red (slow)

Как уже говорилось: это время до отображения какого либо контента. И зависит напрямую от размера . Ну и, естественно, от времени ответа сервера.

Браузер не будет рендерить страницу, пока не загрузит секцию страницы. И тут всё просто: чем меньше контента в теге head, тем быстрее начнет прорисовываться страница. В частности, это касается FCP (так как с LCP могут быть особенности).

Идеальным размером секции считается до 170 КБ. Т. е. в хедере оставляем только самое необходимое. Всё остальное выносим в футер. Таким JS файлам уже и не нужен атрибут defer.

Выносить можно не только JS. А также стили и шрифты. Но к вашей странице применятся стили и шрифты только когда «до них дойдет дело». Т. е. пользователь увидит сначала блоки и текст без стилей и шрифтов, и только когда выполнение дойдет до конца страницы, то только тогда применятся css/fonts. И в таком случае вы получите очень большой показатель сдвигов (CLS).

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

Так что стили и шрифты зачастую остаются в . А в футер переезжают только JS файлы.

Largest Contentful Paint (LCP)

LCP time(in seconds)	Color-coding
Green (fast)
Orange (moderate)
Over 4	Red (slow)

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

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

Должно быть: «гармошка» или «кнопка с вызовом всплывающего окна» или «ссылка на отдельную страницу».

Не используйте AJAX / «lazy» для объектов LCP!

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

Код для определения «какой блок считается LCP» (чтобы понимать какой блок оптимизировать).

new PerformanceObserver((entryList) => < for (const entry of entryList.getEntries()) < console.log(’LCP candidate:’, entry.startTime, entry); >>).observe();

Также LCP можно увидеть у метрик с временной шкалой (WebPageTest).

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

А вот что работает: если LCP — это баннер в начале страницы, то сделайте его на весь экран. Система может распознать её как фон и тогда LCP станет блок поменьше. Например: текст на баннере или логотип.

Т.е. «Width: 100vw; height: 100vh». А всё что над баннером, должно быть «position: fixed».

Личный опыт

Последний проект. Magento 2.4.

По факту, отнюдь не всё из этой статьи было реализовано на проекте.

«Сдвиги» сразу проверялись на этапе разработки. Так что на выходе нам не пришлось исправлять CLS вообще. И в целом старались стили писать «красиво». Они остались в хедере.

«Lazy load» тоже отдельно не ставили. Просто использовали дефолтный loading=»lazy» . (Правда, поддержка браузерами у него слабая).

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

Прописали «defer» атрибут инстаграмовским виджетом.

Применили «лайфхак» с баннером на мобилке чем увеличили LCP.

Результат:

Хомяк: 22 / 78 поинтов
PLP (Категория): 51 / 94
PDP (страница продукта): 45 / 81

Пару советов «на дорожку»

• Старайтесь избегать инлайновых JS/CSS. Они не кэшируются браузером. Следственно «реальные данные» будут хуже, чем могли бы быть.
• Притча. Пришла пара с младенцем к знахарю и спрашивает: «Как нам вырастить здорового ребёнка?». «А сколько младенцу», — спросил знахарь. «Три месяца», — ответили родители. На что знахарь им ответил: «Вы опоздали на 3 и 9 месяцев. ».
  Пытаться исправить ситуацию после разработки — мало толку. Переписывать CSS на GPU и рефакторить JS займёт неимоверно много времени. Равносильно «написанию с нуля». Или даже больше (т.к. переделывать сложнее чем создавать «сразу нормально»). Этим вы вряд ли будете заниматься. Или вам нужно рефакторить какой-то блок, который встречается на сайте в многих местах. Проще это делать сразу на этапе разработки (до того как блок накопируется). Править копии — лишнее время и возможные баги.
• Если разрабатывать JS код, который подключался «в начале страницы», а потом двинуть его «в конец страницы», то вас будет ждать сюрприз: куча ошибок. «JS оптимизации» нужно настроить сразу, на этапе старта проекта. Тогда ошибки будут решаться по мере появления, а не сразу 100500 и пойди пойми какая от чего.
• После разработки в среднем прогноз такой: «попугаев» за (при условии, что для вашего фреймворка есть готовые решения/модули/плагины).

Спасибо, что прочитали нашу статью! Заходите в наш клуб. Там много интересного.

�� Подобається Сподобалось 22

До обраного В обраному 9

Улучшаем производительность сайта с помощью PageSpeed от Google

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

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

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

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

• оценить производительность;
• оценить доступность для людей с ограниченными возможностями;
• определить, насколько сайт оптимизирован для 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:

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

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

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

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

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

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

• web
• perfomance optimization

• Блог компании Домклик
• Клиентская оптимизация
• Веб-аналитика
• Поисковая оптимизация