Маяк обнаруживает невидимые сдвиги в расположении? (невероятно высокий CLS)

Question

Я оптимизирую скорость веб-сайта WordPress (на данный момент только для мобильных устройств), с успехом, за исключением CLS. CLS стал чрезвычайно высоким после оптимизации доставки CSS (с помощью WP-Rocket), но я не вижу никаких сдвигов в макете, даже когда я использую Dev Tools (тест производительности). (на мобильном телефоне)

Вот пример: https://trustmyscience.com/israel-a-pratiquement-eradique-la-covid-19/

1. Результаты здесь с оптимизацией доставки CSS

Таким образом, кажется, что это невидимое изменение макета, которое Lighthouse воспринимает как реальный сдвиг макета. Lighthouse показывает мне, что проблема в <div class="entry-content body-color clearfix link-color-wrap progresson">. Итак, похоже, это связано с некоторой «оберткой» всего содержимого статьи, которая может смещаться на задний план (не быть видимой), может быть, из-за каких-то правил CSS?

2. Здесь элемент с наибольшим сдвигом макета
3. Элемент с наибольшим сдвигом макета (детали)

Когда я деактивирую оптимизацию доставки CSS, CLS возвращается почти к 0 (но LCP слишком высок).

4. Результаты БЕЗ оптимизации доставки CSS

Мне нужна эта оптимизация доставки CSS из-за важности LCP, но теперь мне также нужно решить эту проблему из-за введения CLS в Core Web Vitals, и мне нужно найти то, что Lighthouse обнаруживает как LS. Также, может быть, Lighthouse нужно поправить это? Поскольку это не видимый сдвиг макета ...

Вы знаете, как это решить? Или вы думаете, что мне нужно связаться с разработчиками LS, чтобы показать им это?

Спасибо заранее за вашу помощь.

С уважением,

Answer 1

Вы можете немного повысить производительность, разместив шрифты самостоятельно, вместо того, чтобы обращаться к Google Fonts API, но шрифты здесь не являются главной проблемой. Javascript есть.

На этом веб-сайте много Javascript, поэтому основной поток загружает его, анализирует и выполняет.

Я запустил Lighthouse (с включенным Clear Storage и Simulated ) и ThttlingWebPageTest с профилем Moto 4G.

Как видно из Chrome DevTools и WebPageTest, примерно 56% времени обработки, затрачиваемого на основной поток, связано с написанием сценариев. Вам действительно нужен весь этот Javascript?

Вот что я заметил в Chrome DevTools Performance панель:

• Кажется, 5 front-end.js скрипты (и 1 min-front.js). Они дубликаты?
• Вам нужна анимация с gsap и ScrollTrigger?
• Нет lazyload.min.js а также areimagesloaded.jsделать то же самое? (Я могу быть не прав)
• Вы импортируете всю библиотеку lodash? Если да, попробуйте импортировать только те функции, которые вы действительно используете .
• Вам действительно нужен полифилл для Intersection Observer? Я думаю, что в настоящее время все современные браузеры изначально поддерживают его .

CLS - это, по сути, сумма всех неожиданных сдвигов макета, происходящих на странице. Как видно из оранжевой пунктирной линии на приведенной ниже диаграмме, 4 файла шрифтов .woff2 вносят свой вклад в CLS: первый сдвиг макета происходит, как только шрифты извлекаются.

Но, как я уже сказал, я бы сосредоточился на удалении всего ненужного Javascript. В частности, я бы изучил сторонний JS, например, исходящий от choices.consentframework.com, загрузка которого занимает 1730 мсек и составляет 25% от размера содержимого (см. ниже).

После JavaScript сосредоточьтесь на изображениях .

На панели «Производительность» в Chrome DevTools отображается множество запросов изображений. Вы загружаете только изображения, которые находятся в области просмотра, или все изображения на странице?

Большинство этих изображений являются WebP и кажутся уже оптимизированными, но есть несколько GIF-файлов, которые действительно плохо сказываются на производительности . Кажется, что эти GIF-файлы обслуживаются https://www.viously.com/ (я думаю, это сервер объявлений, я вижу его впервые).

И последнее, но не менее важное: еще раз проверьте, что все ваши <img> а также <video> имеют size а также widthнабор атрибутов. Изображения и видео заменяют элементы с внутренними размерами, и забвение установить размеры изображений в вашем HTML является частой причиной сдвигов макета.

См. Также эту статью Адди Османи, где есть еще несколько советов по оптимизации CLS.

Answer 2

CLS виден, это шрифт.

Разве вы не замечаете, что при посещении страницы размер текста изменяется? Это частая причина CLS.

Как решить?

Подавайте свои шрифты локально. Не используйте плагины вроде OMGF. Сделайте это вручную.

1. Загрузите шрифты. Выберите 2 шрифта, один для основного текста, другой для заголовков. Вам не понадобятся полужирные, курсивные или полужирные + курсивные шрифты. Они будут применяться браузером пользователя.
2. Преобразовать в woff2 (достаточно только woff2, проблем не возникало)
3. Загрузите его на свой сервер
4. Добавьте CSS для шрифта, чтобы объявить шрифты
5. Примените шрифты с помощью элементов CSS
6. Отключите шрифты Google, если вы используете какую-либо тему или конструктор WP.
7. Предварительно загрузите шрифты

Это решит проблему CLS, а также сократит общее время блокировки.