Пытается снизить CLS на мобильных устройствах ниже 0,1 с. Не могу воспроизвести на тестах

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

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.birkengold.com%2Frezept%2Fselbstgemachte-zahnpasta

Протестировано на моделированном Galaxy S5 в сети 3G Fast. https://www.webpagetest.org/result/210112_DiK5559_DiK9_0210112_DiK9258_Di_04_Di_06_05

Ни в каком сценарии я получаю где-то около 0,1 в CLS.


person Axos    schedule 12.01.2021    source источник
comment
Ваш CLS из предоставленной вами ссылки только что вышел с 0,04 прогоном и 0,027 во втором прогоне для PSI, и вы связались с тестом, который имеет CLS 0,001 для webpagetest, я не уверен, что вы спрашиваете, поскольку оба из них находятся под 0,1   -  person Graham Ritchie    schedule 12.01.2021
comment
Тесты в порядке, и это причина, по которой я не могу понять полевые данные. Данные поля для CLS этой явной страницы - 0,16 с, а для всей страницы (источника) - 0,12 с.   -  person Axos    schedule 12.01.2021
comment
Хорошо, дайте вам ответ, который, надеюсь, должен объяснить разницу и как ее отследить в реальном мире. Также для ясности «сводка происхождения» - это все страницы сайта, которые имеют достаточно данных в наборе данных CrUX, «полевые данные» предназначены только для этой страницы. Совершенно уверен, что у вас это есть, но комментарий выше заставил меня дважды проверить (как вы сказали, что вся страница для происхождения).   -  person Graham Ritchie    schedule 12.01.2021
comment
Да, я знаю, как работает сводка о происхождении :) Я просто указал на это, потому что большинство просмотров страниц происходит со страниц именно с этим шаблоном. Таким образом, данные о происхождении говорят и об остальных рецептах. Спасибо за Ваш ответ. Я уже знал о библиотеке, но я подумал, что если я использую критический css без lazyload выше сгиба и который отлично загружается на всех размерах экрана, я, возможно, смогу решить его без дальнейших исследований, и кто-то может указать мне на мою ошибку :) Я дам Тогда попробуйте веб-библиотеку.   -  person Axos    schedule 13.01.2021
comment
нужно проверить, что ваши изображения имеют определенные атрибуты ширины и высоты, это часто является причиной того, что люди не замечают, что происходит CLS. дальше по странице. Удачи в реализации проекта, надеюсь, вы найдете причину!   -  person Graham Ritchie    schedule 13.01.2021
comment
Верно. Поскольку они отзывчивы, я решил добавить padding-bottom с соотношением сторон на контейнере-обертке и расположил изображение внутри absolute. Так что это определенно не должно быть причиной.   -  person Axos    schedule 13.01.2021
comment
Просто чтобы вы знали, что CLS очевиден, когда страница загружается, похоже, что ваш встроенный CSS не имеет всех критических стилей, поскольку кнопки меняют форму (становятся больше), а ваш ползунок вверху, который отображает продукты, начинается с одного продукта, показывающего затем показывает два продукта (поэтому я предполагаю, что вам нужно переделать, как для этого работает JS). Это было легко обнаружить, используя методы, описанные в этом вопросе и ответе   -  person Graham Ritchie    schedule 14.01.2021
comment
Как я уже сказал, я изучил проблему глубже с вашей информацией и обнаружил, что большинство моих проблем с cls (90%) возникает из-за моего всплывающего окна согласия, которое загружается при взаимодействии пользователя. Таким образом, я не мог увидеть проблем в общих тестах. Спасибо за вашу помощь и за то, что указали мне верное направление!   -  person Axos    schedule 21.01.2021


Ответы (1)


Полевые данные и сводка происхождения

Полевые данные и сводка по происхождению - это данные реального мира.

Существует ключевое различие между этими показателями и синтетическим тестом, который выполняет Page Speed ​​Insights.

Например: CLS измеряется до тех пор, пока страница не выгрузится в реальном мире, как указано в этом объяснение по CLS от Адди Османи, которая работает в Google Chrome.

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

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

Как найти страницу / основную причину, которая разрушает ваши Web Vitals?

Предположим, у вас есть страница, которая хорошо справляется с синтетическим тестом Lighthouse, но плохо работает в реальном мире при определенных размерах экрана. Как вы можете это определить?

Для этого вам необходимо собрать данные Real User Metrics (RUM).

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

Есть простой способ сделать это самостоятельно, используя библиотеку Web Vitals.

Это позволяет собирать CLS, FID, LCP, FCP и Данные TTFB, которых более чем достаточно, чтобы определить страницы с низкой эффективностью.

Вы можете передать собранные данные в свой собственный API. или в Google Analytics для анализа.

Если вы собираете, а затем объединяете информацию о жизненно важных показателях сети со строками пользовательского агента (для получения браузера и ОС) и информации о размере браузера (для получения эффективного размера экрана), вы можете сузить область, если проблема связана с определенным браузером, определенный размер экрана, определенная скорость соединения (поскольку вы можете видеть более медленные соединения из высоких показателей FCP / LCP) и т. д. и т. д.

person Graham Ritchie    schedule 12.01.2021