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

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

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

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

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

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

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

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

1. Часто уступайте, чтобы разбить длинные задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Загрузите изображение, используя элемент <img> с атрибутом src или srcset . Не используйте нестандартные атрибуты, такие как data-src , для рендеринга которых требуется JavaScript, поскольку это всегда будет медленнее. 9% страниц скрывают свое изображение 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. Это позволяет избежать задержки загрузки, вызванной подтверждением того, что изображение появляется в области просмотра или рядом с ней.
• По возможности отложите некритические ресурсы. Перемещение этих ресурсов в конец документа, отложенная загрузка изображений или iframe или их асинхронная загрузка с помощью JavaScript поможет расчистить путь для более быстрой загрузки более важных ресурсов, таких как изображение LCP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совокупное изменение макета (CLS)

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

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

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

Лучший способ исправить сдвиги макета, вызванные изображениями неразмерного размера, — это явно установить атрибуты width и height или их эквивалентные свойства CSS. На 72% страниц есть хотя бы одно изображение неразмерного размера. Без явного размера эти изображения имеют начальную высоту 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-архива не могут окончательно связать анимацию со сдвигами макета, данные показывают, что страницы, которые анимируют любое свойство CSS, которое может повлиять на макет, на 15% менее вероятно будут иметь «хороший» CLS, чем страницы в целом. Некоторые свойства связаны с худшим CLS, чем другие. Например, страницы, которые анимируют ширину margin или border имеют «плохой» CLS почти в два раза чаще, чем страницы в целом оцениваются как плохие.

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

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

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

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

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

Заключение

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

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

• Оптимизировать INP
• Оптимизация LCP
• Оптимизация CLS

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

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

октябрь 2024 г.

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

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

Январь 2023 г.

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

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

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