Наиболее эффективные способы улучшения основных веб-показателей,Наиболее эффективные способы улучшения основных веб-показателей

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

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

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

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

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

Взаимодействие со следующей покраской (INP)

Как новейшая метрика Core Web Vital, Interaction to Next Paint (INP) имеет некоторые из самых больших возможностей для улучшения. Однако, поскольку гораздо меньше сайтов преодолевают порог "хорошего" опыта по сравнению с его устаревшим предшественником , вы можете оказаться среди многих разработчиков, впервые изучающих, как оптимизировать отзывчивость взаимодействия. Начните с этих обязательных для изучения методов для наиболее эффективных способов улучшения INP.

1. Чаще уступайте место длительным задачам

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

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

API Scheduler позволяет вам ставить работу в очередь, используя систему приоритетов. В частности, API scheduler.yield() разбивает длинные задачи, гарантируя, что взаимодействия могут быть обработаны без потери их места в очереди задач.

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

2. Избегайте ненужного JavaScript

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

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

• Используйте базовые широкодоступные функции веб-платформы вместо избыточных реализаций на основе JavaScript.
• Используйте инструмент покрытия в Chrome DevTools, чтобы найти неиспользуемый код в ваших скриптах. Уменьшая размер ресурсов, необходимых при запуске, вы можете гарантировать, что страницы тратят меньше времени на парсинг и компиляцию кода, что обеспечивает более плавный первоначальный пользовательский опыт.
• Используйте разделение кода , чтобы создать отдельный пакет для кода, который не нужен для первоначального рендеринга, но все равно будет использоваться позже.
• Если вы используете менеджер тегов, периодически оптимизируйте свои теги . Старые теги с неиспользуемым кодом можно удалить, чтобы уменьшить объем JavaScript-отпечатка вашего менеджера тегов.

3. Избегайте больших обновлений рендеринга

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

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

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

Самая большая содержательная краска (LCP)

Largest Contentful Paint (LCP) — это Core Web Vital, с которым разработчики, как правило, борются больше всего — 40% сайтов в отчете Chrome UX не соответствуют рекомендуемому порогу LCP для хорошего пользовательского опыта. Команда Chrome рекомендует следующие методы как наиболее эффективные способы улучшения LCP.

1. Убедитесь, что ресурс LCP можно обнаружить из исходного HTML-кода и что он имеет приоритет.

Команда Chrome заметила следующее относительно LCP в Интернете:

• По данным веб-альманаха HTTP Archive за 2024 год , 73% мобильных страниц имеют изображение в качестве элемента LCP.
• Анализ реальных пользовательских данных Chrome показывает, что большинство источников с плохим LCP тратят менее 10% своего времени p75 LCP на загрузку образа LCP.
• На страницах с низким LCP загрузка изображений LCP задерживается на клиенте на 1290 миллисекунд на 75-м процентиле — это больше половины бюджета, необходимого для быстрого взаимодействия.
• Из страниц, где элементом LCP было изображение, 35% этих изображений имели исходные URL-адреса, которые не были обнаружены в первоначальном ответе HTML (например, <img src="..."> или <link rel="preload" href="..."> ), что позволило бы сканеру предварительной загрузки браузера обнаружить их как можно скорее.
• По данным Web Almanac, 15% соответствующих требованиям страниц использовали HTML-атрибут fetchpriority для предоставления более высокого приоритета ресурсам, включая те, которые могли бы улучшить LCP страницы с относительно небольшими усилиями.

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

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

Если ваш элемент LCP является изображением, URL изображения должен быть видимым в ответе HTML, чтобы сократить задержку загрузки ресурса. Вот несколько советов, как это сделать:

• Загрузите изображение с помощью элемента <img> с атрибутом src или srcset . Не используйте нестандартные атрибуты, такие как data-src , для рендеринга которых требуется JavaScript, так как это всегда будет медленнее. 7% страниц скрывают свое изображение LCP за data-src .
• Предпочитайте рендеринг на стороне сервера (SSR) рендерингу на стороне клиента (CSR), поскольку SSR подразумевает, что полная разметка страницы (включая изображение) присутствует в исходном HTML. Решения CSR требуют запуска JavaScript до того, как изображение будет обнаружено.
• Если на ваше изображение необходимо ссылаться из внешнего файла CSS или JS, вы все равно можете включить его в исходный код HTML с помощью тега <link rel="preload"> . Обратите внимание, что изображения, на которые ссылаются встроенные стили, не обнаруживаются сканером предварительной загрузки браузера, поэтому, даже если они находятся в исходном коде HTML, их обнаружение все равно может быть заблокировано при загрузке других ресурсов, поэтому в этих случаях может помочь предварительная загрузка.

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

• Добавьте атрибут fetchpriority="high" к тегу <img> или <link rel="preload"> вашего изображения LCP. Это увеличит приоритет ресурса изображения, чтобы он мог начать загружаться раньше.
• Удалите атрибут loading="lazy" из тега <img> вашего изображения LCP. Это позволит избежать задержки загрузки, вызванной подтверждением того, что изображение появляется в области просмотра или рядом с ней.
• Откладывайте некритические ресурсы, когда это возможно. Перемещение этих ресурсов в конец документа, отложенная загрузка изображений или iframes или асинхронная загрузка их с помощью JavaScript поможет расчистить путь для более важных ресурсов, таких как изображение LCP, для более быстрой загрузки.

2. Стремитесь к мгновенной навигации

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

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

Восстановление ранее посещенных страниц стало возможным благодаря кэшу возврата/передачи (bfcache) . Чтобы использовать его, необходимо убедиться, что ваши страницы соответствуют критериям соответствия bfcache . Распространенные причины, по которым страницы не подходят для bfcache, заключаются в том, что они обслуживаются с директивами кэширования no-store или имеют прослушиватели событий unload .

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

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

3. Используйте CDN для оптимизации TTFB

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

Это время известно как время до первого байта (TTFB) . Лучшими способами уменьшить TTFB являются:

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

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

CDN также могут обслуживать и кэшировать HTML-документы, но, по данным Web Almanac, только 33% запросов HTML-документов обслуживались из CDN . Это означает, что у сайтов есть существенная возможность получить дополнительную экономию.

Вот несколько советов по настройке CDN:

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

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

Накопительный сдвиг компоновки (CLS)

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

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

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

Лучший способ исправить сдвиги макета, вызванные изображениями без размера, — явно задать атрибуты width и height или их эквивалентные свойства CSS. 66% страниц имеют по крайней мере одно изображение без размера. Без явного размера эти изображения имеют начальную высоту 0px , что может привести к сдвигам макета при загрузке этих изображений и обнаружении браузером их размеров. Это представляет огромную возможность для коллективной сети — и эта возможность требует меньше усилий, чем некоторые другие рекомендации, предложенные в этом руководстве.

Изображения не являются единственными источниками CLS. Сдвиги макета могут быть вызваны другим содержимым, которое обычно загружается после первоначального отображения страницы, включая стороннюю рекламу или встроенные видео. Свойство aspect-ratio может здесь помочь. Это базовая широкодоступная функция CSS, которая позволяет разработчикам явно устанавливать соотношение сторон для изображений, а также для элементов, не являющихся изображениями. Это позволяет вам устанавливать динамическую width (например, на основе размера экрана) и автоматически рассчитывать браузером соответствующую высоту, во многом так же, как он делает для изображений с размерами.

Однако не всегда возможно узнать точный размер динамического контента. Даже если вы не знаете точный размер, вы все равно можете уменьшить серьезность сдвигов макета. Установка разумной min-height почти всегда лучше, чем разрешение браузеру использовать высоту по умолчанию 0px для пустого элемента. Использование min-height также обычно является простым исправлением, поскольку оно все еще позволяет контейнеру расти до высоты конечного контента, если это необходимо — оно просто уменьшило этот рост до, как мы надеемся, более терпимого уровня.

2. Убедитесь, что страницы подходят для bfcache

Как уже говорилось ранее в этом руководстве, кэш возврата/перехода (bfcache) мгновенно загружает страницу из более ранней или более поздней версии истории браузера из снимка памяти. Хотя bfcache является существенной оптимизацией производительности на уровне браузера, которая улучшает LCP, он также полностью устраняет сдвиги макета. Фактически, введение bfcache в 2022 году стало причиной самого большого улучшения в CLS, которое мы увидели в том году.

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

Владельцы сайтов должны проверить, подходят ли страницы для bfcache , и устранить все причины, по которым они не подходят. В Chrome есть тестер bfcache в DevTools , и вы также можете использовать API Not Restored Reasons для обнаружения причин несоответствия в этой области.

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

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

Хотя данные HTTP Archive не могут окончательно связать анимацию со сдвигами макета, данные показывают, что страницы, которые анимируют любое свойство CSS, которое может повлиять на макет, на 15% реже имеют «хороший» CLS, чем страницы в целом. Некоторые свойства связаны с худшим CLS, чем другие. Например, страницы, которые анимируют ширину margin или border имеют «плохой» CLS почти в два раза чаще, чем страницы в целом оцениваются как плохие.

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

Что может удивить некоторых разработчиков, так это то, что это верно даже в случаях, когда элемент вынесен за пределы обычного потока документа. Например, абсолютно позиционированные элементы, которые анимируют top или left вызывают сдвиги макета, даже если они не сдвигают другой контент. Однако, если вместо анимации top или left вы анимируете transform:translateX() или transform:translateY() , это не заставит браузер обновить макет страницы, что позволит избежать сдвигов макета.

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

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

Аудит Lighthouse «Избегайте некомпозитных анимаций» предупреждает, когда страница анимирует потенциально медленные свойства CSS.

Заключение

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

Если вы хотите выйти за рамки перечисленных здесь оптимизаций, прочитайте эти руководства для получения дополнительной информации:

• Оптимизировать ИНП
• Оптимизировать LCP
• Оптимизировать CLS

Приложение: Журнал изменений

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

Октябрь 2024 г.

Обновление 2024 года:

• ИНП
  • Мы переключили эту метрику с FID на INP в связи с запуском INP в качестве основной метрики Web Vital и сделали ее верхней метрикой в ​​списке.
  • Мы отменили нашу рекомендацию использовать API isInputPending как часть разбиения длинных задач. Вы можете узнать больше о наших рассуждениях в статье Оптимизация длинных задач .
• ЛКП
  • Мы объединили рекомендации по обнаруживаемости и расстановке приоритетов в одну.
  • Мы добавили новую рекомендацию, направленную на мгновенную навигацию.

Январь 2023 г.

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

• ЛКП
  • Убедитесь, что ресурс LCP можно обнаружить из исходного HTML-кода.
  • Убедитесь, что ресурс LCP имеет приоритет
  • Используйте CDN для оптимизации TTFB документов и ресурсов
• ЦЛС
  • Устанавливайте точные размеры для любого контента, загружаемого со страницы.
  • Убедитесь, что страницы подходят для bfcache
  • Избегайте анимаций и переходов, использующих свойства CSS, влияющие на макет.
• ПИД
  • Избегайте или разбивайте длительные задачи
  • Избегайте ненужного JavaScript
  • Избегайте больших обновлений рендеринга

Вы также можете посмотреть презентацию Google I/O 2023 в виде видеообзора.

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

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

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

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

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

Взаимодействие со следующей покраской (INP)

Как новейшая метрика Core Web Vital, Interaction to Next Paint (INP) имеет некоторые из самых больших возможностей для улучшения. Однако, поскольку гораздо меньше сайтов преодолевают порог "хорошего" опыта по сравнению с его устаревшим предшественником , вы можете оказаться среди многих разработчиков, впервые изучающих, как оптимизировать отзывчивость взаимодействия. Начните с этих обязательных для изучения методов для наиболее эффективных способов улучшения INP.

1. Чаще уступайте место длительным задачам

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

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

API Scheduler позволяет вам ставить работу в очередь, используя систему приоритетов. В частности, API scheduler.yield() разбивает длинные задачи, гарантируя, что взаимодействия могут быть обработаны без потери их места в очереди задач.

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

2. Избегайте ненужного JavaScript

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

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

• Используйте базовые широкодоступные функции веб-платформы вместо избыточных реализаций на основе JavaScript.
• Используйте инструмент покрытия в Chrome DevTools, чтобы найти неиспользуемый код в ваших скриптах. Уменьшая размер ресурсов, необходимых при запуске, вы можете гарантировать, что страницы тратят меньше времени на парсинг и компиляцию кода, что обеспечивает более плавный первоначальный пользовательский опыт.
• Используйте разделение кода , чтобы создать отдельный пакет для кода, который не нужен для первоначального рендеринга, но все равно будет использоваться позже.
• Если вы используете менеджер тегов, периодически оптимизируйте свои теги . Старые теги с неиспользуемым кодом можно удалить, чтобы уменьшить объем JavaScript-отпечатка вашего менеджера тегов.

3. Избегайте больших обновлений рендеринга

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

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

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

Самая большая содержательная краска (LCP)

Largest Contentful Paint (LCP) — это Core Web Vital, с которым разработчики, как правило, борются больше всего — 40% сайтов в отчете Chrome UX не соответствуют рекомендуемому порогу LCP для хорошего пользовательского опыта. Команда Chrome рекомендует следующие методы как наиболее эффективные способы улучшения LCP.

1. Убедитесь, что ресурс LCP можно обнаружить из исходного HTML-кода и что он имеет приоритет.

Команда Chrome заметила следующее относительно LCP в Интернете:

• По данным веб-альманаха HTTP Archive за 2024 год , 73% мобильных страниц имеют изображение в качестве элемента LCP.
• Анализ реальных пользовательских данных Chrome показывает, что большинство источников с плохим LCP тратят менее 10% своего времени p75 LCP на загрузку образа LCP.
• На страницах с низким LCP загрузка изображений LCP задерживается на клиенте на 1290 миллисекунд на 75-м процентиле — это больше половины бюджета, необходимого для быстрого взаимодействия.
• Из страниц, где элементом LCP было изображение, 35% этих изображений имели исходные URL-адреса, которые не были обнаружены в первоначальном ответе HTML (например, <img src="..."> или <link rel="preload" href="..."> ), что позволило бы сканеру предварительной загрузки браузера обнаружить их как можно скорее.
• По данным Web Almanac, 15% соответствующих требованиям страниц использовали HTML-атрибут fetchpriority для предоставления более высокого приоритета ресурсам, включая те, которые могли бы улучшить LCP страницы с относительно небольшими усилиями.

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

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

Если ваш элемент LCP является изображением, URL изображения должен быть видимым в ответе HTML, чтобы сократить задержку загрузки ресурса. Вот несколько советов, как это сделать:

• Загрузите изображение с помощью элемента <img> с атрибутом src или srcset . Не используйте нестандартные атрибуты, такие как data-src , для рендеринга которых требуется JavaScript, так как это всегда будет медленнее. 7% страниц скрывают свое изображение LCP за data-src .
• Предпочитайте рендеринг на стороне сервера (SSR) рендерингу на стороне клиента (CSR), поскольку SSR подразумевает, что полная разметка страницы (включая изображение) присутствует в исходном HTML. Решения CSR требуют запуска JavaScript до того, как изображение будет обнаружено.
• Если на ваше изображение необходимо ссылаться из внешнего файла CSS или JS, вы все равно можете включить его в исходный код HTML с помощью тега <link rel="preload"> . Обратите внимание, что изображения, на которые ссылаются встроенные стили, не обнаруживаются сканером предварительной загрузки браузера, поэтому, даже если они находятся в исходном коде HTML, их обнаружение все равно может быть заблокировано при загрузке других ресурсов, поэтому в этих случаях может помочь предварительная загрузка.

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

• Добавьте атрибут fetchpriority="high" к тегу <img> или <link rel="preload"> вашего изображения LCP. Это увеличит приоритет ресурса изображения, чтобы он мог начать загружаться раньше.
• Удалите атрибут loading="lazy" из тега <img> вашего изображения LCP. Это позволит избежать задержки загрузки, вызванной подтверждением того, что изображение появляется в области просмотра или рядом с ней.
• Откладывайте некритические ресурсы, когда это возможно. Перемещение этих ресурсов в конец документа, отложенная загрузка изображений или iframes или асинхронная загрузка их с помощью JavaScript поможет расчистить путь для более важных ресурсов, таких как изображение LCP, для более быстрой загрузки.

2. Стремитесь к мгновенной навигации

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

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

Восстановление ранее посещаемых страниц стало возможным благодаря кэшу заднего/вперед (BFCACHE) . Чтобы использовать его, вы должны убедиться, что ваши страницы соответствуют критериям приемлемости BFCache . Общие причины, по которым страницы не имеют права на BFCACHE, связаны с тем, что им обслуживаются директивы кэширования no-store или имеют слушателей unload .

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

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

3. Используйте CDN для оптимизации TTFB

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

Это время известно как время до первого байта (TTFB) . Лучшие способы уменьшения TTFB - это:

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

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

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

Некоторые советы по настройке CDN включают:

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

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

Накопительный сдвиг компоновки (CLS)

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

1. Установите явные размеры на любом контенте, загруженном со страницы

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

Лучший способ исправить смены макета, вызванные неостановленными изображениями, - это явно установить width и атрибуты height или их эквивалентные свойства CSS. 66% страниц имеют как минимум одно непостоянное изображение. Без явного размера эти изображения имеют начальную высоту 0px , что может привести к сдвигу макета, когда эти изображения загружаются, и браузер обнаруживает их размеры. Это представляет собой огромную возможность для коллективной сети - и эта возможность требует меньших усилий, чем некоторые другие рекомендации, предложенные в этом руководстве.

Изображения не единственные участники CLS. Сдвиги макета могут быть вызваны другим контентом, который обычно загружается после того, как страница изначально рендерировалась, включая сторонние объявления или встроенные видео. Свойство aspect-ratio может помочь здесь. Это базовая линия, широко доступная функция CSS, которая позволяет разработчикам явно устанавливать соотношение сторон на изображениях, а также элементы без изображения. Это позволяет вам установить динамическую width (например, на основе размера экрана) и заставлять браузер автоматически рассчитывать соответствующую высоту, почти так же, как и для изображений с размерами.

Тем не менее, не всегда возможно узнать точный размер динамического контента. Даже если вы не знаете точного размера, вы все равно можете уменьшить тяжесть сдвигов макета. Установка разумной min-height почти всегда лучше, чем позволяет браузеру использовать высоту по умолчанию 0px для пустого элемента. Использование min-height также обычно является прямым исправлением, так как он все еще позволяет контейнеру расти до конечной высоты контента, если это необходимо,-это просто уменьшило этот объем роста до надежды на более терпимый уровень.

2. Убедитесь, что страницы имеют право на BFCache

Как указывалось ранее в этом руководстве, кеш -кэш (BFCACHE) мгновенно загружает страницу с более раннего или более позднего в истории браузера из моментального снимка памяти. Хотя BFCache является значительной оптимизацией производительности на уровне браузера, которая улучшает LCP, он также полностью устраняет сдвиги макета. Фактически, введение Bfcache в 2022 году было ответственным за самое большое улучшение в CLS, которое мы видели в этом году.

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

Владельцы сайтов должны проверить, имеют ли право страницы на BFCACHE и исправить какие -либо причины, почему они не. Chrome имеет тестер BFCache в DevTools , и вы также можете использовать API не восстановленных причин для обнаружения причин невозможности в этой области.

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

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

В то время как данные архива HTTP не могут окончательно подключить анимации к сдвигам макета, данные показывают, что страницы, которые оживляют любые свойства CSS, которые могут повлиять на макет на 15% менее вероятно, будут «хорошие» CLS, чем страницы в целом. Некоторые свойства связаны с худшими CLS, чем другие. Например, страницы, которые оживляют margin или ширину border , имеют «плохую» CLS почти в два раза превышают показатели, которые страницы в целом оцениваются как плохие.

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

Что может быть удивительным для некоторых разработчиков, так это то, что это верно даже в тех случаях, когда элемент взят за пределы обычного потока документов. Например, абсолютно позиционируемые элементы, которые оживляют top или left смену, даже если они не толкают другой контент вокруг. Однако, если вместо того, чтобы анимировать top или left , вы оживляете transform:translateX() или transform:translateY() , это не приведет к тому, что браузер обновляет макет страницы, что позволяет избежать сдвигов макета.

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

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

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

Заключение

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

Если вы хотите выйти за рамки перечисленных здесь оптимизаций, прочитайте эти руководства для получения дополнительной информации:

• Оптимизировать Inp
• Оптимизировать LCP
• Оптимизировать CLS

Приложение: Изменить журнал

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

Октябрь 2024 г.

2024 Обновление:

• ИНП
  • Мы переключили эту метрику с FID на INP в соответствии с запуском INP в качестве основного интернет -показателя и сделали его главной метрикой в ​​списке.
  • Мы изменили нашу рекомендацию использовать API isInputPending как часть разрыва длинных задач. Вы можете узнать больше о наших рассуждениях в статье Optimize Long Tasks .
• ЛКП
  • Мы объединили рекомендации по обнаружении и расстановке приоритетов в одну.
  • Мы добавили новую рекомендацию, чтобы стремиться к мгновенным навигациям.

Январь 2023 г.

Это первоначальный список рекомендаций:

• ЛКП
  • Убедитесь, что ресурс LCP обнаружен из HTML -источника
  • Убедитесь, что ресурс LCP приоритет
  • Используйте CDN для оптимизации документов и ресурсов TTFB
• ЦЛС
  • Установите явные размеры на любой контент, загруженный со страницы
  • Убедитесь, что страницы имеют право на BFCache
  • Избегайте анимаций и переходов, которые используют свойства CSS-вызывающих макет
• ПИД
  • Избегайте или разбивайте длинные задачи
  • Избегайте ненужного JavaScript
  • Избегайте больших обновлений рендеринга

Вы также можете посмотреть эту презентацию ввода/вывода Google 2023 года для резюме видео.