Как устранить ресурсы, блокирующие рендеринг

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

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

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

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

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

На самом деле, все преимущества этого процесса включают в себя:

• Быстрее скорость страницы.
• Google требует меньше ресурсов для загрузки вашей страницы.
• Сокращение проблем, вызванных раздуванием кода.
• Меньший общий размер файла вашего DOM (объектная модель документа).
• Меньше файлов JavaScript и CSS для загрузки.
• Лучшее и быстрое развертывание на различных платформах и устройствах.
• Улучшено взаимодействие с пользователем на мобильных устройствах.
• Улучшена производительность в целом.

Очевидно, что выполнение этого типа процесса оптимизации на вашем сайте дает огромные преимущества.

Почему вы должны определять ресурсы, блокирующие рендеринг?

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

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

В 2021 году среднее время, необходимое для полного рендеринга мобильной веб-страницы, составляло 22 секунды. В 2018 году это было 15 секунд.

Очевидно, что это значительно больше, чем рекомендуемое Google время в две-три секунды. Это также значительно выше, чем раньше.

Что может быть причиной этих проблем с ресурсами, блокирующими рендеринг?

Что движет этим увеличением общей скорости рендеринга страницы?

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

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

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

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

Желание полагаться на такие технологии не обязательно ужасно с точки зрения маркетинга.

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

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

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

В любом случае, это то, что нужно учитывать в каждом проекте веб-сайта в рамках аудита Core Web Vitals.

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

Вместо этого речь идет об общем восприятии страницы, измеряемом структурой взаимодействия со страницей Google или Core Web Vitals.

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

Что такое критический путь рендеринга?

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

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

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

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

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

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

Как работает критический путь рендеринга?

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

По сути, браузер должен запрашивать, получать и анализировать все файлы HTML и CSS (плюс некоторые дополнительные действия), прежде чем он начнет отображать любой визуальный контент.

Этот процесс происходит в течение доли секунды (в большинстве случаев). Пользователи будут видеть пустую белую страницу, пока браузер не выполнит эти шаги.

Ниже приведен пример того, как пользователи могут воспринимать загрузку страницы в зависимости от различных этапов процесса загрузки страницы:

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

Как оптимизировать критический путь рендеринга?

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

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

Это включает в себя процесс оптимизации:

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

Делая это, можно улучшить как Core Web Vitals, так и то, как ваша страница физически отображается для пользователя.

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

И этот процесс включает в себя:

• Предварительная загрузка элементов страницы.
• Встраивание критических стилей.
• Отсрочка загрузки файлов JavaScript.
• Ранние подсказки.

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

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

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

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

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

Вы можете предварительно загрузить CSS, JS, шрифты или изображения. Вот примеры того, как их предварительно загрузить:

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

<link rel="preload" as="script" href=" 

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

<link rel="preload" href=" as="style" /> 

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

<link rel="preload" href=" as="font" type="font/woff2" crossorigin /> 

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

<link rel=preload href=" as=image imagesrcset=" 1x, 2x"> 

Это помогает ускорить процесс страницы. Однако это не идеальный метод.

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

К сожалению, это не реальное стремление преследовать.

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

Встраивание критических стилей

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

Как минимум, для этого обычно требуется:

• Любые объявления шрифтов.
• Любой специфичный для макета CSS.
• Все правила стиля CSS для элементов DOM (объектная модель документа) верхней части страницы.

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

Если вы проверите, например, исходный код google.com, вы увидите, что он встраивает важный CSS в раздел <head> HTML.

Есть несколько инструментов, которые могут помочь извлечь критический CSS.

Отсрочка загрузки файлов JavaScript

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

Пример того, как отложить файл JavaScript:

<скрипт отложить источник = " 

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

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

В-третьих, вы также можете создать проблемы с работой сайта в целом.

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

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

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

Хотя это может оказать положительное влияние на скорость страницы, основная проблема заключается в том, что плагин откладывает все КРИТИЧЕСКИЕ файлы до тех пор, пока страница не загрузит HTML-часть документа.

Что это значит? Это означает, что Google не может видеть весь документ так, как он должен отображаться. Это похоже на блокировку ваших файлов CSS и файлов JavaScript с помощью файла robots.txt, который необходим Google, чтобы определить, подходит ли ваш сайт для мобильных устройств.

На официальной странице Google Developer говорится об этом, как упоминалось в другом месте:

«Для оптимального рендеринга и индексирования всегда разрешайте роботу Googlebot доступ к файлам JavaScript, CSS и изображениям, используемым вашим веб-сайтом, чтобы робот Googlebot мог видеть ваш сайт как обычный пользователь.

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

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

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

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

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

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

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

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

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

Итак, как же работают ранние подсказки?

Согласно руководству для разработчиков Google Chrome, «ранние подсказки — это код состояния HTTP (103 Early Hints), который используется для отправки точного предварительного HTTP-ответа перед окончательным ответом».

Что это дает?

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

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

Ранние подсказки — это то, что «помогает браузеру» и ускоряет время обдумывания сервером, заранее обрабатывая эту загрузку.

В результате этот процесс помогает ускорить загрузку страницы.

Инструменты, которые помогут вам оптимизировать ваш критический путь рендеринга

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

Ну, никогда не бойтесь (слишком сильно!). Существуют доступные плагины WordPress, которые могут помочь вам сделать это.

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

• Плагин Critical CSS : этот удобный инструмент позволяет создавать критически важные CSS, которые нужны вашему сайту. Просто добавьте свой URL-адрес, нажмите «Создать» и все готово.
• Плагин Autoptimize Page Speed: этот конкретный плагин является еще одним плагином скорости страницы, который также позволяет откладывать критически важные файлы. Кроме того, он помогает внедрить встроенный CSS в заголовок страницы, переносит скрипты в нижний колонтитул и минимизирует ваши HTML-файлы.
• Плагин WP Rocket Page Speed: этот плагин скорости страницы является одним из самых мощных плагинов кэширования. После установки этот конкретный плагин позволяет вам воспользоваться кэшированием страниц, сжатием GZIP, предварительной загрузкой кеша и кэшированием браузера.
• WP-Optimize: это плагин WordPress, который позволяет вам делать несколько вещей, чтобы лучше оптимизировать ваш сайт для быстрой загрузки. Они включают в себя оптимизацию базы данных, сжатие изображений и кэширование страниц, а также минимизацию и асинхронизацию файлов CSS и JavaScript.

Обратите внимание: у этого автора нет финансовых предубеждений в отношении любого из этих инструментов.

Почему я должен волноваться?

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

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

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

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

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

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

Их объяснение этих факторов, которые они рассматривают, таково:

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

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

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

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

Цели оптимизации ресурсов, блокирующих рендеринг

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

Любые ресурсы, блокирующие отрисовку, должны быть лишены приоритета, а также любые ресурсы, которые мешают быстрой отрисовке страницы.

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

Зачем улучшать блокирующий рендеринг CSS?

Google много раз говорил, что кодирование не обязательно важно для ранжирования.

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

Когда дело доходит до файлов CSS, они считаются ресурсами, блокирующими рендеринг.

Почему это?

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

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

Это означает, что ваша страница будет в основном «голой», из-за отсутствия лучшего термина.

Удаление стилей CSS приведет к тому, что страница станет буквально непригодной для использования.

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

Если мы изучим процесс рендеринга страницы, серое поле ниже представляет время, необходимое браузеру для получения всех ресурсов CSS. Таким образом, он может начать построение DOM CSS (или дерева CCSOM).

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

Это также может варьироваться, что может зависеть от размера, а также от количества этих файлов CSS.

В следующем дереве рендеринга показан пример браузера, отображающего все файлы вместе с CSS в DOM:

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

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

Официальная рекомендация Google гласит следующее:

«CSS — это ресурс, блокирующий рендеринг. Отправьте его клиенту как можно скорее, чтобы оптимизировать время до первого рендеринга».

HTML должен быть преобразован во что-то, с чем может работать браузер: DOM. CSS-файлы такие же. Это должно быть преобразовано в CSSOM.

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

Зачем улучшать блокирующий рендеринг JavaScript?

Знаете ли вы, что загрузка JavaScript не всегда требуется?

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

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

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

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

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

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

JavaScript обладает исключительной властью изменять стили HTML и CSS, так что это имеет смысл.

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

Официальная рекомендация Google:

«JavaScript также может блокировать построение DOM и задерживать отображение страницы. Чтобы обеспечить оптимальную производительность… уберите ненужный JavaScript с критического пути рендеринга».

Как определить ресурсы, блокирующие рендеринг

Чтобы определить критический путь рендеринга и проанализировать критические ресурсы:

• Запустите тест с помощью webpagetest.org и нажмите на изображение «водопад».
• Сосредоточьтесь на всех запрошенных и загруженных ресурсах до зеленой строки «Начать рендеринг».

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

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

В моем примере я заметил некоторые запросы JavaScript, которые могут быть критическими.

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

Есть и другие способы улучшить такие ресурсы.

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

Для некритических файлов CSS вы также можете уменьшить количество имеющихся у вас файлов CSS, объединив их в один файл и сжав их.

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

Как уменьшить количество блокирующих визуализацию элементов на странице

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

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

Одно из возможных решений — не добавлять CSS с помощью правила @import.

Не добавляйте CSS с помощью правила @Import

С точки зрения производительности, несмотря на то, что @import, кажется, делает ваш HTML-файл чище, на самом деле он может создавать проблемы с производительностью.

Объявление @import на самом деле заставит браузер медленнее обрабатывать файл CSS. Почему? Потому что он также загружает все импортированные файлы.

Рендеринг будет полностью заблокирован до завершения процесса.

Действительно, лучшее решение — использовать стандартный метод включения таблицы стилей CSS с помощью объявления <link rel=»stylesheet»> в HTML.

Минимизируйте файлы CSS и JavaScript

Если вы используете WordPress, использование плагина для минимизации файлов CSS и JavaScript может оказать огромное влияние.

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

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

Это займет больше времени, но может стоить того.

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

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

Используйте системные шрифты вместо сторонних шрифтов

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

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

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

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

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

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

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

Однако, если вам абсолютно необходимо использовать сторонние шрифты, есть две вещи, которые вы хотите сделать, чтобы уменьшить проблемы с некоторыми аспектами сторонних шрифтов.

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

Другая проблема при использовании сторонних шрифтов заключается в том, что шрифты невидимы до тех пор, пока не загрузится сам шрифт, что негативно влияет на Core Web Vitals и взаимодействие с пользователем. Чтобы избежать этого, вы можете использовать CSS для замены шрифтов.

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

Новичок в мире: вариативные шрифты

С 2020 года переменные шрифты стали широко поддерживаться в большинстве браузеров. Что такое вариативные шрифты?

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

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

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

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

Улучшите свои методы кодирования и объединения файлов

Если вы сами работаете с кодом, вы можете (или не можете… никто здесь не судит) обнаружить, что методы менее чем оптимальны.

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

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

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

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

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

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

Объединение файлов также может улучшить ситуацию

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

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

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

Ключевые выводы

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

• Шаг 1. Просканируйте свой сайт с помощью Screaming Frog или других инструментов сканирования.
• Шаг 2. Найдите страницы с низкой скоростью загрузки.
• Шаг 2а. Для этой цели вы также можете использовать Google Search Console или Google Analytics.
• Шаг 3. Расположите страницы с наименьшей производительностью, которые вы найдете в списке приоритетов.
• Шаг 4: Просмотрите элементы контрольного списка выше (вы также можете создать электронную таблицу для каждого элемента на странице, если хотите) и найдите, уменьшите или исправьте эти ресурсы, блокирующие рендеринг, по мере необходимости.
• Шаг 5: Промойте и повторите для каждой страницы вашего сайта.

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

С помощью этого процесса вы тоже можете воспользоваться преимуществом, которое у вас будет, и вы также можете получить импульс от Google Core Web Vitals.

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

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

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

И это также приводит к лучшему пользовательскому опыту.

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

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

Дополнительные ресурсы:

---

Рекомендуемое изображение: SuperOhMo/Shutterstock