Самый быстрый и наиболее оптимизированный ресурс — это ресурс, который не отправляется. Вам следует исключить ненужные ресурсы из вашего приложения. Хорошей практикой является подвергать сомнению и периодически пересматривать с вашей командой неявные и явные предположения. Вот несколько примеров:
- Вы всегда размещали ресурс X на своих страницах, но компенсирует ли стоимость его загрузки и отображения ценность, которую он приносит пользователю? Можете ли вы измерить и доказать его ценность?
- Обеспечивает ли ресурс (особенно сторонний) стабильную производительность? Находится ли этот ресурс на критическом пути или он должен быть там? Если ресурс находится на критическом пути, может ли он быть единственной точкой отказа сайта? То есть, если ресурс недоступен, влияет ли это на производительность и удобство использования ваших страниц?
- Требуется ли для этого ресурса соглашение об уровне обслуживания или имеется ли оно? Соблюдает ли этот ресурс рекомендации по повышению производительности: сжатие, кэширование и т. д.?
Слишком часто страницы содержат ресурсы, которые не нужны или, что еще хуже, снижают производительность страницы, не принося особой пользы посетителю или сайту, на котором они размещены. Это в равной степени относится как к собственным, так и к сторонним ресурсам и виджетам:
- Сайт А решил разместить на своей домашней странице карусель фотографий, чтобы посетитель мог просмотреть несколько фотографий одним щелчком мыши. Все фотографии загружаются при загрузке страницы, и пользователь перемещается по фотографиям.
- Вопрос: Вы измеряли, сколько пользователей просматривают несколько фотографий в карусели? Вы можете понести большие накладные расходы, загружая ресурсы, которые большинство посетителей никогда не просматривает.
- Сайт Б решил установить сторонний виджет для отображения соответствующего контента, улучшения социального взаимодействия или предоставления каких-либо других услуг.
- Вопрос: Отслеживали ли вы, сколько посетителей используют виджет или кликают по контенту, который предоставляет виджет? Достаточно ли вовлечения, которое генерирует этот виджет, чтобы оправдать его накладные расходы? Кроме того, возможно ли использовать стратегию загрузки, гарантирующую , что сценарий не будет загружаться до тех пор, пока он не понадобится ?
Решение о том, следует ли исключить ненужные загрузки, часто требует тщательного обдумывания и измерения. Для достижения наилучших результатов периодически проводите инвентаризацию и возвращайтесь к этим вопросам для каждого ресурса на ваших страницах.
Влияние на основные веб-показатели
Инициатива Core Web Vitals была предложена Google для предоставления набора показателей, отражающих то, что испытывают пользователи при использовании Интернета. Хотя существует множество стратегий оптимизации Core Web Vitals, вопрос о том, загружать ли конкретный ресурс на страницу, может указать вам путь к улучшению этих показателей на вашем веб-сайте. Ниже приведены несколько примеров, сгруппированных по каждому из основных веб-важных показателей, которые заслуживают вашего внимания. Хотя это не исчерпывающий список примеров (а их много!), их прочтение может дать вам пищу для размышлений.
Самая большая содержательная краска (LCP)
Самый большой контент (LCP) измеряет момент загрузки самого большого контента (например, главного изображения или заголовка). Это важный показатель восприятия, который создает у пользователя впечатление, что сайт загружается быстро.
В общем, загрузка меньшего количества ресурсов означает, что имеющаяся у пользователя полоса пропускания будет распределена между меньшим количеством ресурсов, что может привести к улучшению LCP. Классическим примером является отложенная загрузка, когда изображения за пределами области просмотра во время загрузки страницы не будут загружаться до тех пор, пока браузер не определит, что пользователь с большей вероятностью их увидит. Если у вас большая галерея миниатюр, скажем, из 50 изображений, ленивая загрузка всех из них, кроме первых десяти, означает, что браузер может более эффективно использовать доступную ему полосу пропускания, и первые изображения, которые увидит пользователь, будут загружаться больше. быстро.
Однако дело не только в обязательной загрузке меньшего количества изображений . Браузер имеет внутреннюю схему определения приоритетов, которая определяет, какую пропускную способность должен получать каждый ресурс. Однако даже при этом все ресурсы, особенно те, которые загружаются с высоким приоритетом, могут лишить потенциальный зависимый ресурс элемента LCP. Это особенно актуально при медленных сетевых соединениях. Этот зависимый ресурс может быть файлом изображения, представляющим элемент LCP страницы, но он также вполне может быть ресурсом веб-шрифта, который необходим браузеру для отображения текстового узла, который может быть определен как элемент LCP страницы.
Если на вашем веб-сайте много текста, возможно, элементом LCP страницы является текстовый узел. Хотя существует множество хороших стратегий оптимизации и загрузки шрифтов , возможно, стоит подумать о том, достаточен ли системный шрифт для нужд вашего веб-сайта, чтобы элементы LCP, являющиеся текстовыми узлами, могли загружаться без зависимости от ресурса веб-шрифта и рисоваться почти сразу же, как CSS и HTML поступают с сервера.
Совокупное изменение макета (CLS)
Каждый загружаемый вами ресурс может внести свой вклад в накопительный сдвиг макета страницы (CLS) , особенно если загрузка не завершилась к моменту первоначальной отрисовки. Для изображений отказ от CLS предполагает такие методы, как установка явных размеров. Что касается шрифтов, управление загрузкой шрифтов и потенциальное сопоставление резервных шрифтов могут свести к минимуму сдвиги во время периода замены веб-шрифта. В случае с JavaScript это может быть управление тем, как этот сценарий манипулирует DOM, чтобы сдвиги макета были уменьшены до приемлемого уровня.
Каждый ресурс, вносящий вклад в CLS страницы, требует определенного объема работы, чтобы обеспечить достаточную стабильность макета страницы. Задаваясь вопросом, нужен ли вам конкретный ресурс, вы не только ускоряете загрузку страниц, но и уменьшаете когнитивные усилия, необходимые для сохранения стабильности макета. Это приводит не только к гораздо менее разочаровывающему пользовательскому опыту, но и к менее разочаровывающему опыту разработчиков, поскольку у вас будет больше времени для достижения других целей в ваших проектах.
Взаимодействие со следующей отрисовкой (INP)
Взаимодействие с следующей отрисовкой (INP) измеряет скорость реагирования на действия пользователя на протяжении всего существования страницы. На INP страницы может сильно влиять загружаемый ею JavaScript, поскольку именно JavaScript обеспечивает большую часть интерактивности в сети. В частности, объем ресурсов сценария, загружаемых во время загрузки страницы, может привести к потенциально дорогостоящей работе, связанной с оценкой и компиляцией сценария . Чем меньше JavaScript вы загружаете во время запуска, тем меньше работы приходится выполнять браузеру в тот критический момент взаимодействия со страницей, когда пользователи могут пытаться с ним взаимодействовать.
Несмотря на то, что существуют стратегии уменьшения размера ресурсов JavaScript, загружаемых во время запуска, такие как разделение кода и встряхивание дерева, стоит проверить пакеты, которые вы используете в своих проектах, чтобы увидеть, нужны ли они вообще. Например, lodash имеет множество методов, которые все еще полезны сегодня, но поставляется с методами, которые браузер предоставляет «из коробки», такими как специфичные для Array
функции для сопоставления , сокращения и фильтрации и многие другие .
Прогрессивное улучшение также является полезным подходом к JavaScript, поскольку оно позволяет вам предоставлять пользователям базовый (но при этом функциональный) опыт, который вы можете добавить для пользователей с более мощными устройствами и более быстрыми сетевыми подключениями. Независимо от того, придерживаетесь ли вы принципа прогрессивного улучшения или нет, суть остается неизменной: каждый ресурс JavaScript, который вы можете избежать загрузки, может привести к более быстрому реагированию на взаимодействие с пользователем, что является жизненно важным аспектом веб-производительности.
Заключение
Аудит вашего веб-сайта на предмет ненужных загрузок может быть лишь одним из аспектов обеспечения быстрого взаимодействия с пользователем, но он может иметь большое влияние. Подведем итоги:
- Проведите инвентаризацию собственных и сторонних ресурсов на своих страницах.
- Измеряйте эффективность каждого актива: его стоимость и технические характеристики.
- Определите, приносят ли ресурсы достаточную ценность.
- Узнайте, как ненужные загрузки влияют на основные веб-показатели и сопутствующие показатели.
Оптимизируя таким образом эффективность контента, вы не только повышаете общую производительность, но и заботитесь о том, чтобы не тратить зря пропускную способность пользователей, а также потенциально улучшаете показатели, ориентированные на пользователя, и обеспечиваете лучший пользовательский опыт.