Улучшение основных веб-показателей, тематическое исследование журнала Smashing Magazine

«Почему мои Core Web Vitals терпят неудачу?» В последнее время многие разработчики задают себе этот вопрос. Иногда достаточно просто найти ответ на этот вопрос, и сайту просто нужно инвестировать в производительность . Иногда, однако, это немного сложнее, и, несмотря на то, что ваш сайт считался отличным по производительности, по какой-то причине он все еще терпит неудачу. Это то, что случилось с нашим собственным smashingmagazine.com, и для выяснения и устранения проблемы потребовалось немного покопаться.

Крик о помощи

Все началось с серии твитов в марте прошлого года с криком о помощи:

Что ж, это меня заинтересовало! Я большой поклонник Smashing Magazine и очень интересуюсь веб-производительностью и Core Web Vitals. Я уже писал здесь несколько статей о Core Web Vitals, и мне всегда интересно узнать, что входит в их ежегодный контрольный список веб-производительности. Итак, Smashing Magazine знает о веб-производительности, и если у них проблемы, то это может быть интересным тестом!

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

Исследование проблемы LCP

Проблема заключалась в том, что LCP был слишком медленным на мобильных устройствах. LCP, или Largest Contentful Paint, является одним из трех основных веб-жизненных показателей, которые вы должны «пройти», чтобы получить полное повышение рейтинга в поиске от Google в рамках их обновления Page Experience. Как следует из названия, LCP стремится измерять, когда самый большой контент страницы отображается (или «рисуется») на экране. Часто это изображение героя или текст заголовка. Он предназначен для измерения того, что посетитель сайта, скорее всего, пришел сюда увидеть.

Предыдущие метрики измеряли вариации первой краски на экране (часто это был цвет заголовка или фона); случайный контент, который на самом деле не является тем, что пользователь действительно хочет получить со страницы. Самый большой контент часто является хорошим показателем или, что наиболее важно. И «содержательная» часть имени показывает, что эта метрика предназначена для игнорирования (например, цвета фона); они могут быть самым большим контентом, но они не «содержательные», поэтому не учитывайте LCP, и вместо этого алгоритм пытается найти что-то лучшее.

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

Есть много способов измерить ваши основные веб-жизненные показатели, но окончательный способ — даже если это не самый лучший способ, как мы скоро увидим — в Google Search Console (GSC). С точки зрения SEO не имеет значения, что говорят вам другие инструменты, GSC — это то, что видит Google Search. Конечно, важно то, что видят ваши пользователи , а не то, что видит поисковый робот, но одна из замечательных особенностей инициативы Core Web Vitals заключается в том, что она измеряет реальный пользовательский опыт , а не то, что видит Google Bot! Итак, если GSC говорит, что у вас плохой опыт, значит, по словам ваших пользователей , у вас действительно есть плохой опыт.

Search Console сообщил журналу Smashing Magazine, что их LCP на мобильных устройствах для большинства страниц нуждаются в улучшении. Достаточно стандартный вывод этой части GSC и довольно легко решается: просто увеличьте скорость прорисовки вашего элемента LCP! Это не должно занять слишком много времени. Уж точно не шесть месяцев (по крайней мере, мы так думали). Итак, сначала нужно выяснить, что такое элемент LCP.

Запуск сбойной страницы статьи через WebPageTest выделил элемент LCP:

Улучшение изображения LCP

Итак, фотография автора статьи — это элемент LCP. Первый инстинкт — спросить, что мы можем сделать, чтобы сделать это быстрее? Это включает в себя изучение водопадов, определение того, когда запрашивается изображение, сколько времени занимает загрузка, а затем принятие решения о том, как это оптимизировать. Здесь изображение было хорошо оптимизировано по размеру и формату (обычно это первый и самый простой вариант улучшения производительности изображений!). Изображение обслуживалось из отдельного домена активов (часто плохо для производительности), но было невозможно изменить это в краткосрочной перспективе, и Smashing Magazine уже добавил preconnect ресурса перед подключением, чтобы ускорить это как можно лучше. мог.

Как я упоминал ранее, Smashing Magazine знает о веб-производительности, только недавно работал над улучшением своей производительности и сделал все правильно здесь, но все равно терпел неудачу. Интересно…

Поступали и другие предложения, в том числе снижение нагрузки, задержка сервисного работника (во избежание конфликтов) или исследование приоритетов HTTP/2, но они не оказали должного влияния на время LCP. Поэтому нам пришлось обратиться к нашему набору инструментов для веб-производительности, чтобы найти все советы и рекомендации , чтобы увидеть, что еще мы можем здесь сделать.

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

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

В последнее время было несколько достижений в форматах изображений, но AVIF вызывает ажиотаж, поскольку он уже здесь (по крайней мере, в Chrome и Firefox) и имеет впечатляющие результаты сжатия по сравнению со старыми форматами JPEG, традиционно используемыми для фотографий. Виталий не хотел встраивать JPEG-версию авторских изображений, но исследовал, будет ли работать встраивание версии AVIF. Сжатие изображения автора с помощью AVIF, а затем преобразование изображения в HTML с помощью base64 привело к увеличению веса HTML-страницы на 3 КБ, что является крошечным и поэтому было приемлемым.

Поскольку в то время AVIF поддерживался только в Chrome (после всего этого он пришел в Firefox) и поскольку Core Web Vitals является инициативой Google, оптимизация для браузера Google казалась немного «неприятной» из-за указа Google. Chrome часто находится в авангарде поддержки новых функций, и это заслуживает похвалы, но он всегда чувствует себя немного не в своей тарелке, когда эти две стороны его бизнеса влияют друг на друга. Тем не менее, это был новый стандартный формат изображения, а не какой-то проприетарный формат только для Chrome (даже если изначально он поддерживался только в Chrome), и это было прогрессивным улучшением производительности (пользователи Safari по-прежнему получают тот же контент, просто не так быстро). ), поэтому с добавлением поворота AVIF Smashing принял предложение и встроил изображение и действительно получил впечатляющие результаты в лабораторных инструментах. Задача решена!

Альтернативный LCP

Итак, мы впустили эту кровать и подождали обычные 28 дней или около того, пока все показатели Core Web Vitals не станут зелеными… но этого не произошло. Они колебались между зеленым и желтым, поэтому мы, безусловно, улучшили ситуацию, но не решили проблему полностью. После долгого пребывания в разделе янтаря «нуждается в улучшении» Виталий обратился к нам, чтобы узнать, есть ли какие-либо другие идеи.

Изображение прорисовывалось быстро. Не совсем мгновенно (в конце концов, для обработки изображения все еще требуется время), но настолько близко, насколько это возможно. Честно говоря, у меня кончились идеи, но я взглянул еще раз свежим взглядом. И тут меня осенила альтернативная идея — оптимизировали ли мы нужный элемент LCP? Авторы, конечно, важны, но разве это то, за чем сюда пришел читатель? Как бы наше эго ни хотело сказать да, и что наши красивые сияющие рожи гораздо важнее, чем контент, который мы пишем, читатели, вероятно, так не думают (читатели, да — что поделаешь!).

Читатель пришел за статьей, а не за автором. Таким образом, элемент LCP должен отражать это, что также может решить проблему с отрисовкой изображения LCP. Для этого мы просто поместили заголовок над изображением автора и немного увеличили размер шрифта на мобильных устройствах. Это может показаться подлым трюком, чтобы обмануть богов Core Web Vital SEO за счет пользователей, но в данном случае это помогает обоим! Хотя многие сайты пытаются быстро и легко взломать или оптимизировать для GoogleBot реальных пользователей, это был не тот случай, и мы были вполне довольны этим решением. Фактически, дальнейшие настройки полностью удаляют изображение автора в мобильном представлении, где место ограничено, и эта статья в настоящее время выглядит на мобильных устройствах так, с выделенным элементом LCP:

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

И это одна из главных вещей, которые мне нравятся в Core Web Vitals: они измеряют пользовательский опыт.

Чтобы улучшить показатели, вы должны улучшить опыт.

“

И СЕЙЧАС мы наконец закончили. Текст рисуется намного быстрее, чем изображения, поэтому проблема с LCP должна быть решена. Всем большое спасибо и спокойной ночи!

Я ненавижу этот график CWV в консоли поиска Google…

Мы снова были разочарованы. Это не решило проблему, и вскоре график Google Search Console стал желтым:

На этом этапе мы должны поговорить немного больше о группах страниц и Core Web Vitals. На приведенном выше графике вы могли заметить, что практически весь график колеблется одновременно. Но была также основная группа из примерно 1000 страниц, которые большую часть времени оставались зелеными. Почему это?

Что ж, Google Search Console классифицирует страницы по группам страниц и измеряет показатели Core Web Vitals этих групп страниц. Это попытка заполнить недостающие данные для тех страниц, которые не получают достаточно трафика, чтобы иметь значимые данные о пользовательском опыте. Есть несколько способов, которыми они могли решить эту проблему: они могли просто не повышать ранжирование таких страниц или, возможно, предположили лучший и полностью повысили рейтинг страниц без каких-либо данных. Или они могли вернуться к базовым веб-данным на уровне источника. Вместо этого они попытались сделать что-то более умное, что было попыткой быть полезным, но во многих отношениях также более запутанным: группы страниц .

По сути, каждой странице назначается группа страниц. Как они это делают, неясно, но URL-адреса и технологии, используемые на странице, упоминались ранее. Вы также не можете видеть, какие группы Google выбрал для каждой из ваших страниц, и правильно ли их алгоритм понял, что является еще одной неприятной вещью для владельцев веб-сайтов, хотя они дают образцы URL-адресов для каждого отдельного балла Core Web Vitals под графиком. в Google Search Console, из которого иногда может подразумеваться группировка.

Группы страниц могут хорошо работать для таких сайтов, как Smashing Magazine. Для других сайтов группы страниц могут быть менее четкими, и многие сайты могут иметь только одну группу. Однако на сайте Smashing есть несколько разных типов страниц: статьи, страницы авторов, руководства и так далее. Если страница статьи работает медленно из-за медленной загрузки изображения автора, изображение LCP, то это, вероятно, будет иметь место для всех страниц статей. Исправление, скорее всего, будет одинаковым для всех страниц статей. Таким образом , группировать их вместе имеет смысл (при условии, что Google может точно определить группы страниц).

Однако это может сбить с толку, когда страница получает достаточно посетителей, чтобы получить свою собственную оценку Core Web Vitals, и она проходит, но она попадает в группу с неудачей. Вы можете вызвать CrUX API для всех страниц на вашем сайте, увидеть, что большинство из них проходят, а затем смутиться, когда эти же страницы отображаются как неуспешные в Search Console, потому что они были объединены в группу с неверными URL-адресами и большинством трафик для этой группы предназначен для отказа. Мне все еще интересно, должна ли Search Console использовать данные Core Web Vital на уровне страницы, когда она есть, а не всегда использовать данные группировки.

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

Вы также можете получить более подробные данные о Core Web Vitals через CrUX API. Это доступно на уровне источника (т. е. для всего сайта) или для отдельных URL-адресов (где существует достаточно данных), но, что раздражает, не на уровне группировки страниц. Я отслеживал LCP исходного уровня с помощью CrUX API, чтобы получить более точную оценку LCP, и это также показало удручающую историю:

Мы видим, что на самом деле мы так и не «решили» проблему, а количество «хороших» страниц (зеленая линия выше) по-прежнему колебалось слишком близко к 75% успешности. Кроме того, оценка p75 LCP (пунктирная линия, которая использует правую ось) никогда не отодвигалась достаточно далеко от порога в 2500 миллисекунд. Неудивительно, что проходящие и исчезающие страницы перелистывались взад и вперед. Немного неудачного дня с еще несколькими медленными загрузками страниц было достаточно, чтобы перевернуть всю группу страниц в категорию «требует улучшения». Нам нужно было что-то большее, чтобы дать нам возможность пережить эти «плохие дни».

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

Но подожди минутку. Smashing Magazine БЫЛ быстрым сайтом. Запуск его с помощью инструментов веб-производительности, таких как Lighthouse и WebPageTest, показал это даже при более низких скоростях сети. И все делал правильно! Он был построен как генератор статических сайтов, поэтому не требовалось какой-либо генерации на стороне сервера, он встроил все для начальной отрисовки, поэтому не было никаких ограничений на загрузку ресурсов, кроме самого HTML, он был размещен Netlify на CDN, поэтому должен находиться рядом с пользователями.

Конечно, мы могли бы рассмотреть вопрос об удалении шрифта, но если Smashing Magazine не может обеспечить быструю работу с учетом всего этого, то как может кто-то другой? Прохождение Core Web Vitals не должно быть невозможным и не требует, чтобы вы находились только на простом сайте без шрифтов или изображений. Что-то еще было здесь, и пришло время узнать немного больше о том, что происходит, вместо того, чтобы просто слепо пытаться провести еще один раунд оптимизации.

Копнем немного глубже в метрики

У Smashing Magazine не было RUM-решения, поэтому вместо этого мы углубились в данные Chrome User Experience Report (CrUX), которые Google собирает для примерно 8 миллионов самых популярных веб-сайтов, а затем делает эти данные доступными для запроса в различных формах. Именно эти данные CrUX управляют данными Google Search Console и, в конечном итоге, влияют на ранжирование. Мы уже использовали CrUX API выше, но решили углубиться в другие ресурсы CrUX.

Мы использовали карту сайта и скрипт Google Sheets, чтобы просмотреть все данные CrUX для всего сайта, где они были доступны (с тех пор Фабиан Крамбхольц создал гораздо более комплексный инструмент, чтобы упростить эту задачу!), и он показал смешанные результаты для страниц . Некоторые страницы прошли, в то время как другие, особенно старые страницы, терпели неудачу.

Приборная панель CrUX на самом деле не сообщила нам многого из того, что мы уже не знали в этом случае: LCP был пограничным и, к сожалению, не имел тенденции к снижению:

Изучение других статистических данных (TTFB, First Paint, Online, DOMContentLoaded) не дало нам никаких подсказок. Однако было заметное увеличение использования мобильных устройств:

Было ли это частью общей тенденции внедрения мобильных устройств? Может ли это повлиять на мобильную LCP, несмотря на сделанные нами улучшения? У нас были вопросы, но не было ответов или решений.

Одна вещь, на которую я хотел обратить внимание, это глобальное распределение трафика. Мы заметили в Google Analytics много трафика из Индии на старые статьи — может ли это быть проблемой?

Связь с Индией

Данные CrUX на уровне страны недоступны на информационной панели CrUX, но доступны в наборе данных BigQuery CrUX, и выполнение запроса на исходном уровне www.smashingmagazine.com показывает большие расхождения в значениях LCP (SQL включен в вторая вкладка этой ссылки, кстати, на случай, если вы захотите попробовать то же самое на своем собственном домене). На основе 10 ведущих стран в Google Analytics у нас есть следующие данные:

Трафик в Индии составляет большую долю для Smashing Magazine (16%), и он не соответствует целевому показателю LCP на уровне источника. Это могло быть проблемой и, безусловно, стоило дальнейшего изучения . Были также данные по Филиппинам и Пакистану с очень плохими оценками, но это был относительно небольшой объем трафика.

В этот момент у меня было подозрение, что здесь может происходить, и потенциальное решение, поэтому Smashing Magazine установил библиотеку web-vitals для сбора данных RUM и отправки их обратно в Google Analytics для анализа. После нескольких дней сбора мы использовали отчет Web Vitals, чтобы получить много данных, которые мы не могли видеть раньше, в частности, разбивку по странам:

И вот оно. У всех ведущих стран в аналитике были очень хорошие оценки LCP, кроме одной: Индии. Smashing Magazine использует Netlify, глобальную CDN, которая присутствует в Мумбаи, поэтому она должна быть такой же производительной, как и другие страны, но некоторые страны просто медленнее, чем другие (подробнее об этом позже).

Однако мобильный трафик в Индии едва превышал лимит в 2500, и это была лишь вторая по посещаемости страна. Конечно, хороших результатов в США должно было быть достаточно, чтобы компенсировать это? Что ж, два приведенных выше графика показывают порядок стран по трафику. Но CrUX считает мобильный и настольный трафик отдельно (и планшетный, кстати, но, кажется, никого это не волнует!). Что произойдет, если мы отфильтруем трафик только для мобильного трафика ? И еще один шаг — только мобильный трафик Chrome (поскольку только Chrome передает CrUX и поэтому только Chrome учитывается в CWV)? Ну тогда получаем гораздо более интересную картину:

Индия на самом деле занимает первое место по количеству посетителей Chrome с мобильных устройств — почти в три раза больше, чем следующее по количеству посетителей (США)! Филиппины с их низкими показателями также поднялись там на третье место, а Нигерия и Пакистан с их низкими показателями также попали в первую десятку. Теперь низкие общие оценки LCP на мобильных устройствах начали обретать смысл.

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

Кроме того, поскольку CrUX измеряет только пользователей Chrome , это означает, что в странах с большим количеством iPhone (например, в США) будет гораздо меньшая доля их мобильных пользователей, представленных в CrUX и, следовательно, в Core Web Vitals, что дополнительно усиливает эффект этих стран.

Основные веб-жизненные показатели глобальны

Core Web Vitals не имеет разных пороговых значений для каждой страны, и не имеет значения, посещают ли ваш сайт представители разных стран — он просто регистрирует всех пользователей Chrome одинаково. Google уже подтверждал это ранее, поэтому Smashing Magazine не получит повышение рейтинга за хорошие оценки в США и не получит его для пользователей из Индии. Вместо этого все пользователи попадают в плавильный котел , и если оценка для этих групп страниц не достигает порогового значения, это влияет на сигнал ранжирования для всех пользователей.

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

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

Следует ли разделить Core Web Vitals по странам?

С одной стороны, кажется несправедливым привязывать веб-сайты к одному стандарту, если инфраструктура так сильно различается. Почему Smashing Magazine должен подвергаться наказанию или предъявляться к более высокому стандарту, чем аналогичный веб-сайт, который читают только дизайнеры и разработчики из западного мира? Должен ли Smashing Magazine заблокировать индийских пользователей, чтобы поддержать Core Web Vitals (я хочу прояснить, что это никогда не обсуждалось, поэтому, пожалуйста, примите это как автор, доказывающий свою точку зрения, а не Sleight на Smashing!).

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

И это не просто дебаты о богатой стране и бедной стране. Возьмем в качестве примера французский веб-сайт, предназначенный для читателей во Франции, финансируемый за счет рекламы или продаж во Франции и имеющий быстрый веб-сайт в этой стране. Однако, если сайт читают многие французские канадцы, но страдает из-за того, что компания не использует глобальную CDN, то должна ли эта компания страдать во французском поиске Google, потому что он не так быстр для этих канадских пользователей? Должна ли компания быть «прикована к выкупу» из-за угрозы Core Web Vitals и должна ли инвестировать в глобальную CDN, чтобы канадские читатели и Google были довольны?

Что ж, если страдает достаточно значительная часть ваших зрителей, то именно это и должна выявить инициатива Core Web Vital. Тем не менее, это интересная моральная дилемма, которая является побочным эффектом инициативы Core Web Vitals, связанной с повышением рейтинга SEO : деньги всегда меняют вещи!

Одна из идей может заключаться в том, чтобы оставить пределы одинаковыми, но измерять их по странам . Французский поисковый сайт Google может дать повышение рейтинга тем пользователям, которые говорят по-французски (поскольку эти пользователи передают CWV для этого сайта), в то время как Google Search Canada может не дать (поскольку они терпят неудачу). Это уравняет правила игры и подсчитает сайты для каждой страны, даже если цели одинаковы.

Точно так же журнал Smashing Magazine может иметь хороший рейтинг в США и других странах, где они проходят успешно, но он может быть ранжирован по сравнению с другими индийскими сайтами (где тот факт, что они находятся в сегменте «требует улучшения», может быть на самом деле лучше, чем многие сайты в этом сегменте, при условии, что все они имеют одинаковые ограничения производительности).

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

Итак, как это исправить?

Итак, теперь мы, наконец, поняли, почему журнал Smashing Magazine изо всех сил пытался обойти Core Web Vitals, но что можно было с этим поделать? У хостинг-провайдера (Netlify) уже есть CDN в Мумбаи, который, следовательно, должен обеспечивать быстрый доступ для индийских пользователей, поэтому была ли это проблема Netlify для улучшения этого? Мы оптимизировали сайт настолько, насколько это было возможно, так что им просто придется с этим жить? Нет, теперь мы возвращаемся к нашей предыдущей идее: еще немного оптимизировать веб-шрифты .

Мы могли бы пойти на радикальный вариант и вообще не предоставлять шрифты. Или, возможно, не доставлять шрифты в определенные места (хотя это было бы сложнее, учитывая характер SSG веб-сайта Smashing Magazine). В качестве альтернативы мы могли подождать и загрузить шрифты во внешнем интерфейсе на основе определенных критериев, но это рисковало замедлить работу других шрифтов, пока мы оценивали эти критерии. Если бы только был какой-нибудь простой в использовании сигнал браузера, когда мы должны предпринять это радикальное действие. Что-то вроде заголовка SaveData, который как раз для этого и предназначен!

SaveData и prefers-reduced-data

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

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

Информация о сохраненных данных доступна двумя (скоро будет тремя!) способами:

1. Заголовок SaveData отправляется при каждом HTTP-запросе. Это позволяет динамическим бэкендам изменять возвращаемый HTML.
2. JavaScript API NetworkInformation.saveData . Это позволяет внешним сценариям проверять это и действовать соответствующим образом.
3. Предстоящий медиа prefers-reduced-data , позволяющий CSS устанавливать различные параметры в зависимости от этого параметра. Это доступно за флагом в Chrome, но еще не включено по умолчанию, пока он завершает стандартизацию.

Итак, вопрос в том, используют ли многие читатели Smashing Magazine (особенно в странах, которые борются с Core Web Vitals) этот вариант, и можем ли мы использовать его, чтобы предоставить им более быстрый сайт? Что ж, когда мы добавили упомянутый выше скрипт web-vitals , мы также решили измерить его, а также эффективный тип подключения. Вы можете увидеть полный сценарий здесь. Через некоторое время, позволив ему собраться, мы можем отобразить результаты на простой панели инструментов /Google Analytics вместе с версией браузера Chrome:

Итак, хорошая новость заключалась в том, что у значительной части мобильных индийских пользователей (около двух третей) была установлена ​​эта настройка. ECT был менее полезен, поскольку большинство из них отображалось как 4g. Ранее я утверждал, что этот API становится все менее и менее полезным, поскольку большинство пользователей классифицируются в соответствии с этой настройкой 4g. Кроме того, эффективное использование этого значения для начальных загрузок чревато проблемами.

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

Ilya from the Smashing team applied the JavaScript API version to their font-loader script so additional fonts are not loaded for these users. The Smashing folks also applied the prefers-reduce-data media query to their CSS so fallback fonts are used rather than custom web fonts for the initial render, but this will not be taking effect for most users until that setting moves out of the experimental stage.

I Love That Graph In Google Search Console

And did it work? Well, we'll let Google Search Console tell that store as it showed us the good news a couple of weeks later:

Additionally, since this was introduced in mid-November, the original level LCP score has steadily ticked downwards:

There's still not nearly enough headroom to make me comfortable, but I'm hopeful that this will be enough for now, and will only improve when the prefers-reduced-data media query comes into play — hopefully soon.

Of course, a surge in traffic from mobile users with bad connectivity could easily be enough to flip the site back into the amber category, which is why you want that headroom, so I'm sure the Smashing team will be keeping a close eye on their Google Search Console graph for a bit longer, but I feel we've made the best efforts basis to improve the experience of users so I am hopeful it will be enough.

Impact Of The User Experience Ranking Factor

The User Experience ranking factor is supposed to be a small differentiator at the moment, and maybe we worried too much about a small issue that is, in many ways outside of our control? If Smashing Magazine is borderline, and the impact is small, then maybe the team should worry about other issues instead of obsessing over this one? But I can understand that and, as I said, Smashing Magazine are knowledgeable in performance and so understand why they wanted to solve — or at the very least understand! — this issue.

So, was there any impact? Interestingly we did see a large uptick in search impression in the last week at the same time as it flipped to green:

It's since reverted back to normal, so this may have been an unrelated blip but interesting nonetheless!

Выводы

So, an interesting case study with a few important points to take away:

• When RUM (including CrUX or Google Search Console) tells you there's a problem, there probably is! It's all too easy to try to compare your experiences and then blame the metric.
• Implementing your own RUM solution gives you access to much more valuable data than the high-level data CrUX is intended to provide, which can help you drill down into issues, plus also give you potentially more information about the devices your site visitors are using to visit your site.
• Core Web Vitals are global, and that causes some interesting challenges for global sites like Smashing Magazine. This can make it difficult to understand CrUX numbers unless you have a RUM solution and perhaps Google Search Console or CrUX could help surface this information more?
• Chrome usage also varies throughout the world, and on mobile is biased towards poorer countries where more expensive iPhones are less prevalent.
• Core Web Vitals are getting much better at measuring User Experience. But that doesn't mean every user has to get the same user experience — especially if they are telling you (through things like the Save Data option) that they would actually prefer a different experience.

I hope that this case study helps others in a similar situation, who are struggling to understand their Core Web Vitals. And I hope you can use the information here to make the experience better for your website visitors.

Удачной оптимизации!

Note: It should be noted that Vitaly, Ilya and others at the Smashing team did all the work here, and a lot more performance improvements were not covered in the above article. I just answered a few queries for them on this specific problem over the last 6 months and then suggested this article might make an interesting case study for other readers to learn from.