Largest contentful paint как уменьшить
Разбираем методы оптимизации скорости сайта и его загрузки по параметрам Core Web Vitals. Все, что касается стилей.
В 2021 году Google сформировал Web Vitals — представление о сигналах качества сайта, отражение того, насколько удобно пользователям с ним взаимодействовать. Core Web Vitals — набор показателей для количественного измерения этого удобства.
Кратко самое важное про Core Web Vital
В набор показателей Core Web Vitals входит измерение времени загрузки элементов страницы, отзывчивость контента на действия пользователей и стабильность этого контента во время загрузки.
LCP (Largest Contentful Paint) — загрузка самого большого видимого объекта на видимой пользователю области экрана. Хорошим показателем считается 2,5 секунды с начала загрузки страницы.
CLS (Cumulative Layout Shift) — визуальная стабильность, смещение макета страницы во время загрузки элементов. Приемлемый показатель CLS — 0,1 или меньше.
FID (First Input Delay) — интерактивность, время реакции страницы на первое действие пользователя. Хороший уровень FID — до 100 миллисекунд.
Подробнее Core Web Vitals мы разбирали в материале.
CSS тоже могут влиять на Core Web Vitals, особенно это касается показателей LCP — отрисовки самого большого видимого элемента, и CLS — сдвига макета.
Проверить скорость загрузки страницы и посмотреть на процесс ее загрузки можно в бесплатном инструменте от PR-CY.
Как оптимизировать CSS для быстрой загрузки страниц:
Для удобства методы разбиты по элементам, с которыми нужно работать: макет, изображения, шрифты, анимация — все касается работы со стилями. За основу взяли статью «CSS для Web Vitals» Кэти Хемпениус и Уны Кравец, перевели и дополнили полезными решениями.
1. Критические и некритические CSS
При обработке CSS по умолчанию блокируется рендеринг — визуализация страницы. Пока браузер не загрузит и не проанализирует таблицу стилей, он не будет загружать другие ресурсы. Если файлы CSS большие или есть проблемы с сетью, показатель LCP может ухудшиться, потому что затянется загрузка наибольшего видимого объекта.
Как оптимизировать CSS
Производительность можно повысить, если разделить CSS на критически важные для загрузки первого экрана и остальные, которые можно отложить.
Верхняя строка отображает загрузку страницы с CSS, блокирующим рендеринг. Нижняя — загрузка той же страницы со встроенным критическим CSS:
Сравнение загрузки страницы
Как работать с CSS страницы
Критические CSS вынести в head
CSS, нужные для загрузки верхней части первого экрана, нужно как можно быстрее отобразить пользователям. Встройте их в head, чтобы для получения этих стилей не требовался дополнительный запрос.
Некритические CSS загрузить асинхронно
Остальную часть CSS, которая не требуется для начального рендеринга страницы, можно загрузить асинхронно с помощью loadCSS или отложить в footer.
Неиспользуемые CSS
Ненужные CSS удалить или переместить в другую таблицу стилей, если для других страниц сайта они все-таки нужны. Лучше не делать это вручную, можно удалить что-то нужное.
В статье про оптимизацию LCP мы разобрали, как автоматизировать этот способ оптимизации стилей. Смотрите раздел «Блокировка рендеринга JavaScript и CSS»
У способа есть и недостатки: браузер не будет кэшировать встроенный в head CSS, так что каждый раз он будет загружаться заново. Проверьте, возможно, у вас нет проблем с рендерингом, так что и разделять CSS вам не нужно.
Еще можно минифицировать CSS, то есть сократить, тем самым уменьшив размер файла. После минификации в файле не будет лишних пробелов и ненужных символов. Бесплатные инструменты для этого собрали в статье об ускорении загрузки.
2. Изображения
Рассмотрим не оптимизацию изображений в целом, а только проблемы, связанные с CSS и картинками.
Изображения и LCP
LCP — показатель загрузки самого большого элемента на видимом экране. Чаще всего это изображение, хотя самым большим элементом может быть и текст, и видеоролик.
Более того, самый большой элемент страницы может меняться по мере загрузки и появления новых объектов. Или в зависимости от устройства просмотра, как в этом примере. Здесь главными объектами выступают обложка статьи, фон уведомления о файлах cookie и текст статьи:
Варианты самого большого объекта в зависимости от устройства
Как оптимизировать
В примере на планшете самый большой элемент — это фоновое изображение уведомления о файлах cookie. Вместо него можно нарисовать градиент в CSS, чтобы не тратить время на загрузку изображения для фона. Это улучшит LCP.
Измените .banner CSS, чтобы использовать градиент CSS, а не изображение.
Сдвиги макета CLS
Если картинка загружается после отрисовки страницы, а под ее параметры не было зарезервировано место, макет сдвинется. Это будет заметно при медленном интернете или при большом размере файла.
Нужно зарезервировать место в DOM для элемента, появление которого смещает макет.
Можно зарезервировать нужное для картинки пространство с помощью полей соотношения сторон CSS. Если ширина изменится, изменится и высота, сохранив пропорции.
Если известно одно измерение изображения, можно определить второе по его пропорциям. Если картинка шириной 640 пикселей имеет соотношение сторон 16:9, то его высота составит 640 x (9/16) = 360 пикселей. Чтобы не считать самим, есть калькулятор.
Для предотвращения сдвигов макета как раз полезно использовать способ, учитывающий соотношение сторон. Об этом способе есть материал на английском.
Современные браузеры устанавливают соотношение сторон изображений по умолчанию на основе атрибутов ширины и высоты, благодаря CSS. Разработчикам нужно установить width и height как обычно:
И использовать каскадные CSS для всех браузеров, которые добавят соотношение сторон по умолчанию на основе существующих атрибутов width и height:
В этом случае браузер вычислит пропорцию картинки, основанную на атрибутах width и height, до загрузки изображения, в самом начале расчета макета. Если изображение имеет определенную ширину (например width: 100%), с помощью соотношения сторон он вычислит его высоту.
Адаптивные изображения
Современный подход к загрузке изображений — использование srcset атрибутов в сочетании с атрибутами width и height. Способ дает дополнительное преимущество в производительности, потому что позволяет обслуживать изображения разного размера на разных устройствах.
Для примера это выглядит так:
Изображение в контейнере
Если изображение находится в контейнере, вы можете использовать CSS, чтобы изменить размер изображения до ширины этого контейнера. Прммер: установили height: auto, чтобы высота изображения не была фиксированным значением:
3. Реклама, скрипты, фреймы
История такая же, как в предыдущем пункте про изображения. Если какой-то элемент появляется в DOM после того, как окружающая страница уже отрисована, он сдвинет контент под ним. Типичные примеры — появление в верхней части страницы рекламы, фреймов, в целом сторонних скриптов, когда элементы ниже уже загрузились.
Как реклама может портить CLS:
сайт вставляет рекламный контейнер в DOM;
сайт меняет размер рекламного контейнера с помощью собственного кода;
рекламное объявление заполняет контейнер, но оказывается другого размера.
Динамические элементы тоже могут смещать контент. К примеру, это часто происходит из-за форм и баннеров «подпишитесь на рассылку», «другой контент по теме», «установите наше приложение», «закажите у нас» и других.
Посмотреть, какие элементы влияют на смещение макета страницы можно в бесплатном инструменте для проверки скорости. Он анализирует загрузку страницы поэтапно и дает подсказки, как оптимизировать каждый этап.
Фрагмент результатов теста
Как решить проблему
Рекламные блоки и фреймы
Зарезервировать место для рекламы или фрейма, чтобы никакой контент не занял этот слот, пока элементы не загрузились.
Если слот для рекламы есть, но само объявление не появилось, не стоит сворачивать этот рекламный слот на странице. Лучше показывать там заглушку, чтобы не сдвигать контент.
Если в слоте под рекламу появляются объявления разного размера, ориентируйтесь на максимально возможный размер, когда резервируете место, чтобы не обрезать объявления. Максимально возможный из тех, что когда-либо появлялись в этом блоке.
Динамический контент
Не стоит загружать новый контент над уже загруженным и прочитанным пользователями. Скорее всего появление нового блока сверху будет для них неожиданностью. Исключением могут быть элементы, которые появились в ответ на действие пользователя и ожидаются вверху экрана.
Если такой блок нужен вверху, также зарезервируйте для него место на странице.
Уведомления cookie
Бывает, что источником сдвигов макета выступают уведомления о согласии на использование файлов cookie, если они находятся в верхней части экрана. Как можно с ним поработать:
Использовать липкий колонтитул или модальное окно для уведомления о файлах cookie. При этих подходах уведомление появится наложением поверх остальной части страницы и тогда оно не будет вызывать смещение макета при загрузке.
Само уведомление лучше перенести вниз и настроить фиксированное или абсолютное позиционирование. При фиксированном элемент закрепится и во время прокрутки страницы будет всегда виден посетителю, а при абсолютном будет перемещаться с документом при прокрутке. Такое уведомление перекроет статичные элементы, даже если будет находиться ниже в коде.
- Скрипты, которые загружаются не асинхронно, будут задерживать загрузку страницы и портить показатель LCP. Поэтому нужно настроить асинхронную загрузку, чтобы она не влияла на основной поток рендера. Для этого нужно добавить async в тег элемента:
4. Шрифты
Увидеть шрифты, которые загружаются на определенной странице, можно в браузерном режиме просмотра кода страницы. Перейдите на вкладку Network и выберите фильтр по Font:
Просмотр шрифтов на странице
Узнать, сколько времени требуется для запроса шрифта, можно на вкладке «Timing». Чем раньше запрошен шрифт, тем скорее его можно будет загружать и использовать. Цепочка запросов на шрифт отображается на вкладке «Initiator», чем она короче, тем быстрее можно будет запросить шрифт.
Цепочка запросов для шрифта
Применение шрифтов может задерживать рендеринг текста и вызывать сдвиги макета. Посмотрим, какие проблемы могут возникнуть и как их решать.
Как работать со шрифтами
Как оптимизировать рендеринг
Есть два варианта рендеринга шрифтов:
Резервный невидимый шрифт —> основной шрифт
Текст рендерится с доступным системе шрифтом, но он не видим пользователю до загрузки. Когда основной шрифт загружается, текст становится виден на странице. В это время может быть заметно FOIT — мигание невидимого текста.
В этом случае сдвиг макета минимальный, но скорость загрузки будет ниже, может задержаться первая отрисовка содержимого — FCP, а иногда и отрисовка самого большого объекта — LCP.
Системный шрифт —> основной шрифт
Текст рендерится с доступным шрифтом, но видимым пользователям, а после загрузки шрифт подменяется. Может быть заметно ощутимое мигание нестилизованного текста — FOUT.
При этом способе загрузка быстрее, но сдвиг более вероятен.
У PageSpeed Insights есть замечание «Настройте показ всего текста во время загрузки веб-шрифтов», то есть инструмент советует второй вариант.
Для этого в CSS шрифта нужно добавить свойство «font-display:swap», чтобы до загрузки файла вашего шрифта текст отображался системным шрифтом.
В нужном CSS-файле шрифта будут правила font-face с прописанными путями к файлам шрифта. Внутрь этого правила и нужно вставить «font-display:swap».
Стили внешних Google-шрифтов редактировать не получится. Нужно сделать правку в файле, где записан адрес шрифта: в конец адреса добавить параметр display=swap.
Для сайтов на WordPress есть плагины.
Полезный сервис: Transfonter в ответ на файл шрифта выдаст архив со всеми форматами и корректный CSS.
Как избежать смещения макета
Замена резервного шрифта на основной может повлиять на CLS — смещение макета, если основной и резервный шрифты занимают разное пространство на странице. В этом примере замена шрифта привела к смещению элементов страницы вверх на пять пикселей:
Смещение макета из-за шрифтов
Минимизировать эти сдвиги можно, если подобрать шрифты с одинаковыми пропорциями букв.
Предзагрузка
Без предзагрузки браузер сначала прочитает страницу, увидит указание на CSS, скачает его, разберет, найдет блок с описанием шрифтов и только потом начнет их загружать. Из-за этого могут быть сдвиги макета и в целом замедление загрузки.
Файлы шрифтов можно предзагрузить. Если браузер увидит объявление о предзагрузке шрифта, он будет загружать и его, и параллельно CSS. К моменту, как он разберет CSS, шрифт уже будет доступен для рендера.
Для WordPress есть плагины, либо можно использовать link rel = "preload" as = "font".
В примере есть версия шрифта v=4.5.0. Ее нужно использовать в preload, если Google показывает версию в адресе.
Что касается Google Fonts, то он предоставляет возможность загружать шрифты с помощью тегов link или операторов @import. Подсказка preconnect в теге link должна привести к более быстрой загрузке таблиц стилей, чем при использовании @import.
Удалите из таблицы стилей этот оператор @import:
И добавьте в head документа эти теги link:
Эти теги подсказывают браузеру, что нужно установить раннее соединение с источниками, используемыми Google Fonts, и загрузить таблицу стилей шрифтов Montserrat и Roboto.
Есть и другие способы ускорить загрузку страницы и оптимизировать все параметры, входящие в Core Web Vitals. Но эти улучшения, касающиеся CSS, тоже могут сделать страницу значительно удобнее и приятнее для пользователей.
В 2021 году Google не просто измеряет скорость, а отдельно оценивает этапы загрузки. Для измерения он использует набор показателей — Google Core Vitals. Он стал фактором ранжирования Google с середины июня 2021 года.
В Google Core Vitals входят три основных параметра:
Скорость появления контента
LCP, Largest Contentful Paint — время, за которое браузер отрисовывает самый крупный видимый объект в области просмотра.
Отзывчивость
FID, First Input Delay — время между первым взаимодействием пользователя со страницей и ответом браузера.
Визуальная стабильность
CLS, Cumulative Layout Shift — оценка сдвигов макета во время загрузки страницы.
Google рекомендует использовать пороговые значения этих трех параметров для оценки удобства пользователей. Если страницы получают оценки выше пороговых значений LCP, FID и CLS, то они проходят оценку Core Web Vitals.
Как проверить скорость и этапы загрузки страницы
Для каждого пункта есть пояснения и советы, что можно улучшить, с примерным подсчетом экономии скорости при выполнении.
Фрагмент проверки
Как оптимизировать показатели Core Web Vitals
Разберем каждый параметр по отдельности.
LCP: как ускорить отрисовку контента
Показатель LCP определяет, когда закончилась загрузка основного содержимого страницы, ее самого крупного элемента. Чем ниже LCP, тем лучше, тем быстрее пользователи смогут изучать контент.
Самым большим элементом могут быть разные части страницы, появляющиеся по мере загрузки. В этом примере таким элементом сначала был заголовок, а потом стала картинка.
Этапы отрисовки
Нужно стремиться к тому, чтобы отрисовка самого большого элемента на странице не занимала больше 2,5 секунд от начала загрузки. Это считается оптимальным показателем сайта, на котором удобно работать.
На LCP влияют четыре фактора, их можно оптимизировать:
ускорить время ответа сервера;
решить блокировку рендеринга JavaScript и CSS;
ускорить загрузку ресурсов;
оптимизировать рендеринг на стороне клиента.
FID: как ускорить время реакции страницы
Показатель оценивает, насколько страница задержалась с ответом на первое действие пользователя. К примеру, на странице появилось изображение, на которое пользователь кликнул, чтобы открыть картинку целиком. Картинка должна открыться сразу после клика. FID измеряет, насколько она задержалась.
Чем меньше времени тратится, тем лучше. Оптимальный показатель FID — не дольше 100 миллисекунд.
Для ускорения реакций страницы есть несколько решений:
сократить время выполнения JavaScript;
разбить длинные задачи на части;
отложить неиспользуемый JavaScript;
следить за размером подгружаемых библиотек JavaScript;
оптимизировать выполнение сторонних скриптов;
CLS: как убрать сдвиги макета страницы
Контент на странице может сдвигаться, если какие-то элементы загружаются в асинхронно: это бывает, если веб-мастер не отвел достаточно места под загружаемый элемент вверху страницы. В этом случае его загрузка сдвинет весь контент вниз.
Из-за сместившихся кнопок пользователь промахнулся
Сдвиги могут быть нормальными, если они ожидаемы для пользователя и появляются в ответ на его действие. К примеру, если он кликнул на блок в списке и развернулась расшифровка.
CLS измеряет совокупный сдвиг макета из-за неожиданных сдвигов, которые появляются из-за тормозящей загрузки элементов.
Для вычисления нужны два компонента:
общая область на экране, которую занимает элемент до и после сдвига;
расстояние, на которое он сдвинулся.
Оптимальный показатель CLS —не больше 0,1 на 75% сессий.
Что еще влияет на загрузку страницы: оптимизируем CSS
Стили страницы влияют на скорость отрисовки самого большого видимого элемента и визуальные сдвиги макета.
Например, блокировка рендеринга при обработке CSS тормозит загрузку остальных ресурсов на странице. Чтобы такого не происходило, можно ускорить процесс и разделить CSS на критические и некритические для выполнения.
Для сравнения на верхней строчке загрузка страницы с блокирующими рендеринг CSS, на нижней с разделением CSS:
Сравнение загрузок страницы
Кроме критических и некритических CSS можно поработать со стилями изображений, рекламой, скриптами, фреймами и шрифтами.
Все эти возможности разобрали в отдельном материале.
Как уменьшить вес страниц сайта и ускорить загрузку
Другие возможности повлиять на скорость.
Как оптимизировать код верхней части страницы
Есть еще способ сделать загрузку быстрее — поработать с кодом верхней части страницы, которую пользователь видит первым делом, как заходит на сайт. Если верхняя часть страницы загружается быстро, пользователь как можно раньше увидит загружающийся контент. А остальное можно подгрузить попозже.
Есть несколько методов:
удалить лишние символы и скрипты из верхней части кода;
настроить асинхронную загрузку с jQuery;
ускорить получение первых байтов (TTFB);
объединить и сократить JavaScript и CSS;
настроить загрузку из кэша на стороне пользователя;
Как внедрить gzip, brotli, использовать кэширование, минификацию и другие способы сжатия
Картинки, видео и разные интерактивные элементы много весят и тормозят сайт. Можно сжать тяжелые элементы, для это есть алгоритмы, самые популярные сейчас — это gzip и brotli. Brotli сжимает сильнее, чем gzip, у него больше уровней. Но на высоких уровнях его скорость меньше.
Способы ускорить загрузку:
- уменьшить размер HTML;
- использовать сжатие gzip или brotli;
- использовать минификацию, то есть сократить HTML, CSS и JS;
- использовать кэш браузера для ускорения;
- сжать фотографии, иллюстрации и другую графику: подобрать разрешение, уменьшить количество цветов, прописать параметры в CSS и сжать сами файлы.
К примеру, при уменьшении количества цветов качество этой картинки почти не страдает, зато сильно уменьшается вес. Слева направо: 32 бита (16M цветов), 7 бит (128 цветов), 5 бит (32 цвета).
Три варианта сжатия
Способы нагружают сервер из-за операций архивирования, но в целом с ними получается быстрее из-за уменьшения размера загружаемых данных.
Что используют самые быстрые страницы интернета: исследование 5,2 млн страниц
Команда блога Backlinko во главе с Брайаном Дином провели исследование страниц из выдачи Google и проверили, какие способы ускорения используют самые быстрые страницы. В выборке было 5,2 млн страниц из десктопной и мобильной выдачи, так что результат стоит посмотреть.
- Общая скорость загрузки
- Как CDN влияет на скорость загрузки
- Какие фреймворки самые быстрые
- Как сжатие файлов влияет на скорость
- Какое сжатие изображений эффективнее ускоряет загрузку
- Сайты на каких CMS грузятся быстрее
Несколько интересных тезисов:
Средняя скорость загрузки первого байта (TTFB) — 1,286 секунды на десктопе и 2,594 секунды на смартфоне. Среднее время полной загрузки страницы — 10,3 секунды на десктопе и 27,3 секунды на мобильном.
Как ни странно, лучшие варианты — либо минимально сжать файлы перед отправкой с сервера, либо максимально. У таких страниц более высокая производительность по сравнению со средним уровнем сжатия.
Для загрузки на десктопе на скорость сильнее влияет использование CDN, на мобильных — количество запросов HTML.
Если сравнивать разные способы оптимизировать картинки, использование адаптивных изображенийвыходитна первое место.
Как оптимизировать и сжать картинки
Изображения много весят и дольше всего загружаются, используем все возможности для облегчения и ускорения файлов.
Как сжимать картинки и заполнять SEO-атрибуты
Изображения много весят и сильно влияют на загрузку сайта. Чтобы они не сильно замедляли загрузку и приносили пользу в SEO, нужно учитывать эти факторы:
- количество картинок на странице, размеры, уникальность, тематика;
- правильная оптимизация;
- правильное заполнение SEO-атрибутов изображений.
Нет данных, что количество картинок на странице влияет на попадание в топ. Но есть рекомендация использовать несколько вариантов одной картинки в разных форматах для превью на разных устройствах.
Качество картинок важно, оно должно быть не хуже, чем у конкурентов. Минимум 1080 px по высоте для полного изображения и минимум 640 px в ширину для превью.
Не стоит использовать тег picture для настройки разных форматов картинок для разных устройств. Это увеличит количество узлов в DOM-дереве.
Эти и другие моменты о сжатии картинок, оптимальном формате, размере, содержании, о требованиях к заполнению метатегов и о других важных аспектах есть в большой подробной статье.
Большая часть советов основана на вебинаре специалиста технического SEO и реверс инжиниринга Деми Мурыча (Demi Murych). Речь не только о сжатии и уменьшении веса, но и о требованиях по размерам, качеству, уникальности и актуальные советы по заполнению метатегов.
Как настроить отложенную загрузку картинок — lazy loading изображений
Отдельный материал с подробным описанием настройки ленивой загрузки изображений, еще ее называют отложенной. При такой реализации пользователю не придется ждать, пока загрузится весь контент, потому что картинки будут подгружаться по мере просмотра страницы.
Есть несколько вариантов настройки:
- Пока пользователь скролит: когда он дойдет до места, где должна быть картинка, она загрузится.
- Когда пользователь кликнет на элемент: картинка загрузится, если он перейдет по ссылке или щелкнет на превью.
- В фоновом режиме: контент будет загружаться постепенно, например, когда пользователь открыл документ и оставил его. Обычно применяют для больших чертежей и схем.
Картинки загружаются по мере просмотра:
Отображение картинок с отложенной загрузкой
Выбор варианта зависит от поведения пользователей на сайте.
Нужно ли использовать формат изображений WebP
WebP — это формат графических изображений, его разработали в Google в 2010 году. Получилась альтернатива PNG и JPEG, но с меньшим размером при таком же качестве изображения. При этом в WebP можно сохранить прозрачность фона или анимацию.
Сравнение свойств популярных форматов изображений
Формат выгоднее с точки зрения ускорения загрузки сайта, но не все браузеры его поддерживают.
В статье мы собрали все самое важное о формате WebP: исследования качества и веса, достоинства и недостатки формата, поддержку браузерами, способы конвертирования и другие темы.
Эти материалы позволят разобраться с оптимизацией страниц, чтобы ускорить загрузку и привести показатели Core Web Vitals в норму. Как вы ускоряете сайт, какие способы используете? Поделитесь в комментариях!
В мае Google определил новый способ оценки пользовательского опыта. Показатель называется Google Core Vitals, он связан со скоростью загрузки сайта и появления на нем контента.
Google Core Vitals состоит из трех метрик:
- FID — First Input Delay — время между первым взаимодействием пользователя со страницей и ответом бразуера.
- CLS — Cumulative Layout Shift — показатель смещения элементов во время загрузки страницы.
- LCP — Largest Contentful Paint — определяет время, за которое браузер отрисовывает самый крупный видимый объект в области просмотра.
Про CLS у нас есть подробный материал «Как оптимизировать CLS: сдвиги макета страницы, которые мешают пользователям», в этой статье поговорим о показателе LCP и способах его улучшить.
Что такое LCP — показатель Largest Contentful Paint
Largest Contentful Paint — время рендеринга самого большого элемента, видимого в области просмотра пользователем — изображения, текстового блока, видео или другого контента. Учитываются те размеры элементов, которые видны пользователю. Если элемент частично скрыт за областью просмотра, эти невидимые части не берутся в расчет.
Самый аккуратный способ определить время отображения основного содержимого страницы — использовать API Largest Contentful Paint (LCP).
Как это происходит:
При загрузке страницы контент может меняться, поэтому каждый раз, когда появляется новый большой элемент, браузер отправляет PerformanceEntry c типом largest-contentful-paint. Когда пользователь начинает взаимодействовать со страницей, отправка метрики прекращается. Нужное значение — время самого последнего отправленного события.
Отрисовка самого большого элемента может происходить и до полной загрузки страницы. К примеру, логотип Instagram — самый большой элемент, он загружается относительно рано и остается самым большим элементом, пока постепенно отображается остальной контент.
Самый большой элемент загрузился до конца загрузки остального контента
В следующем примере самый большой элемент изменяется по мере загрузки содержимого — сначала им был текст, потом самым большим объектом стала картинка.
Самый большой элемент менялся по мере загрузки
Как измерить LCP: инструменты веб-мастера
Инструменты, которые позволяют измерить показатель LCP:
Проверка скорости сайта от PR-CY бесплатно анализирует загрузку страницы по ключевым параметрам, проверяет десктопное и мобильное отображение. Сервис дает рекомендации и прикидывает, сколько можно сэкономить, если их внедрить на сайте.
Интерфейс проверки скорости сайта
Какой показатель LCP считается хорошим
Нужно стремиться, чтобы отрисовка самого большого контента происходила не дольше, чем за 2,5 секунды после начала загрузки страницы. Тогда пользователям будет удобно работать на сайте.
Инструменты для измерения показывают сводный показатель LCP для 75 % посещений URL.
Как улучшить показатель LCP
На LCP влияют четыре фактора:
- время ответа сервера;
- JavaScript и CSS с блокировкой рендеринга;
- время загрузки ресурса;
- рендеринг на стороне клиента.
Рассмотрим эти факторы, сопутствующие им проблемы и способы оптимизировать показатели.
Медленный ответ сервера
Чем быстрее браузер получает контент с сервера, тем быстрее загрузка страницы и тем лучше показатель LCP.
Вы можете улучшить TTFB — время до первого байта. Какие есть способы:
Можно использовать оба варианта для разных браузеров.
Блокировка рендеринга JavaScript и CSS
Браузер преобразовывает разметку HTML в дерево DOM, а потом уже отображает контент. Он не сможет продолжать работу, если обнаружит ресурсы, блокирующие рендеринг: внешние таблицы стилей link rel="stylesheet" и сценарии JavaScript script src="https://pr-cy.ru/news/p/main.js". Чтобы ускорить загрузку содержимого страницы, нужно отложить все некритические JavaScript и CSS.
Неиспользуемый JavaScript и CSS можно найти с помощью Chrome DevTools на вкладке Coverage.
Поиск неиспользуемого CSS и JavaScript
Найденный неиспользуемый CSS можно вообще удалить или переместить в другую таблицу стилей, если он нужен на других страницах сайта.
Если CSS не нужен для начального рендеринга, можно использовать loadCSS для асинхронной загрузки файлов, который использует rel="preload" и onload.
Как улучшилось LCP после откладывания некритического CSS
Критический CSS можно включить в head, если он нужен для верхней части страницы. Встраивание стилей таким образом позволит не делать двусторонний запрос для получения критического CSS.
Как автоматизировать добавление встроенных стилей на сайт:
-
, CriticalCSS и Penthouse извлекают и встраивают верхний CSS; встраивает критический CSS и загружает остальные в отложенном режиме.
Для JavaScript также можно использовать асинхронную загрузку.
Еще полезна минификация или минимизация кода CSS и JavaScript — удаление символов, которые не нужны браузеру для чтения кода. Минификаторы удаляют отступы, интервалы, разделители и комментарии, файл по сути не меняется, но становится легче.
Список бесплатных инструментов для минимизации CSS, JS, HTML-файлов есть в статье.
Как улучшилось LCP после минификации CSS
Долгая загрузка ресурсов
Время, которое требуется контенту для загрузки, влияет на LCP, так что имеет смысл поработать с элементами на странице.
Что можно сделать:
- Оптимизировать изображения.
Если на сайте много больших по размеру изображений, которые замедляют загрузку страниц, попробуйте lazy loading картинок — постепенную подгрузку, которая обычно зависит от действий пользователя на странице. Еще можно сжать изображения, если они много весят, попробовать новый формат WebP, обратиться к CDN. - Загрузить важное сначала
Критически важные ресурсы, например, шрифты, изображения или видеозаписи, нужно загрузить первым делом. Для придания ресурсу приоритета есть < link rel = "preload" >. - Использовать сервис-воркеры
В предыдущем пункте упоминали сервис-воркеры для выборочного кэширования, их можно использовать и для изображений и других элементов, которые редко обновляют на странице. - Использовать gzip или brotli
Эти виды сжатия могут значительно уменьшить размер файлов HTML, CSS и JavaScript при их передаче между сервером и браузером. Об настройке в статье «Как ускорить сайт с помощью gzip, brotli, минификации и других способов».
Рендеринг на стороне клиента
Есть сайты, которые работают через рендеринг на стороне клиента (CSR) — то есть рендеринг страниц происходит в браузере с использованием JavaScript, все обрабатывается на стороне клиента, а не на сервере.
Основной недостаток такого подхода в том, что по мере роста сайта, добавления новых библиотек и кода начинает страдать скорость загрузки и отображения контента для пользователя.
Что можно сделать:
- минифицировать код JavaScript — сократить и сжать файл;
- выявить неиспользуемые элементы JavaScript, удалить или отложить их;
- минимизировать неиспользуемые полифиллы, которые используют для работы сайта в старых браузерах. Сведите к минимуму неиспользуемые полифилы и ограничьте их использование средами, где они необходимы.
В некоторых случаях можно использовать предварительный рендеринг. В таком способе рендер выполняется в headless браузере типа Chrome, который генерирует статические файлы HTML, а их уже подставляют в ответ сервера.
Предварительный рендеринг не нагружает реальный сервер и позволяет улучшить показатель LCP, но не подходит для страниц с изменяемым или с введенным пользователем контентом.
Как улучшилось LCP после предварительного рендеринга
Скорость загрузки ресурса на компьютере и мобильных устройствах можно проверить в Анализе сайта от PR-CY. Он проверяет сайт по 70+ параметрам, включая скорость загрузки и отображения контента, анализирует, что реализовано на сайте для ускорения, и дает советы, что еще можно улучшить.
Проверка скорости в Анализе сайта
Некоторые подробные тесты и графики, а также проверка внутренних страниц и отслеживание позиций доступны на платных тарифах. Но мы даем новым пользователям неделю на бесплатный тест сервиса — оставайтесь, если понравится!
В комментариях напишите, о чем еще вам было бы интересно почитать по теме оптимизации и работы с техническими характеристиками сайта.
В прошлом году Google начал масштабный пересмотр факторов ранжирования в поисковике, чтобы улучшить качество поисковой выдачи. И в ноябре команда Google анонсировала Core Web Vitals — новые факторы оценки качества ресурсов, которые смогут влиять на индексацию и вступят в силу в мае 2021 года. Давайте разбираться.
Существуют сотни факторов ранжирования, однако Core Web Vitals будет анализировать ещё больше информации и иметь непосредственное влияние на дальнейшую индексацию. Нужно отметить, что скорость загрузки напрямую не влияет на индексацию, однако имеет значительное влияние на поведение пользователя, которое является важным сигналом для поисковых алгоритмов Google.
Чем Core Web Vitals отличается от прочих факторов ранжирования?
Положительная сторона Core Web Vitals — в прозрачности: это понятные, публично доступные критерии, которые можно отслеживать и улучшать с помощью специального набора инструментов. Кроме того, с момента анонсирования и до официального запуска есть много времени, чтобы уже начать работать над Core Web Vitals.
Андрей Липатцев, Web Partnerships Google
Исследования показали, что 47% пользователей ожидают загрузки страницы до 2 секунд. Согласно отчету Google, если это время увеличивается с 1 до 3 секунд, количество отказов возрастает на 32% . А при увеличении с 1 до 6 секунд — на целых 106% .
Если ресурс будет отвечать пороговым значениям Core Web Vitals, покидать сайт будут на целых 24% пользователей меньше.
Core Web Vitals
Текущий набор показателей фокусируется на трех аспектах взаимодействия с пользователем:
- Largest Contentful Paint (LCP) — определяет скорость загрузки страницы и ее крупных визуальных элементов. Хороший показатель – до 2,5 с.
- First Input Delay (FID) — измеряет интерактивность сайта, то есть насколько быстро он становится доступным к взаимодействию после загрузки. Желательным будет показатель до 100 мс.
- Cumulative Layout Shift (CLS) — показывает скорость визуальной стабилизации, то есть насколько быстро всё становится на свои места. Идеальным будет показатель меньше 0,1.
LCP (загрузка)
Для разработчиков всегда было непросто измерить, насколько быстро контент веб-страницы загружается и становится видимым для пользователей.
Старые метрики, такие как load или DOMContentLoaded, не подходят, так как они всегда соответствуют тому, что пользователь видит на экране. А более новые показатели производительности, такие как First Contentful Paint (FCP), отражают только самое начало процесса загрузки.
В ходе исследований обнаружилось, что более точный способ измерить загрузку основного содержимого страницы, – это посмотреть, когда был отрисован самый большой элемент.
Так появилась метрика Largest Contentful Paint (LCP), которая измеряет время рендеринга самого большого элемента на странице.
Что считается большим элементом?
- тег img
- элементы image внутри тега svg
- постер в теге video
- фоновое изображение, загруженное с помощью url() (не считая CSS градиента) , содержащие текстовые узлы или другие дочерние элементы.
Как это работает?
Веб-страница загружается поэтапно, и в результате самый большой элемент на ней может измениться.
Важно отметить, что элемент может считаться самым большим содержимым только после того, как он будет отрисован и виден для пользователя.
Браузер перестает сообщать о новых записях, как только пользователь начнет взаимодействовать со страницей, поскольку взаимодействие может визуально изменить страницу (прокрутка, модальное окно и т.д.).
Рис.1. Изменение самого большого элемента по мере загрузки содержимого
Как определяется размер самого большого элемента?
Размер элемента определяется в области видимости пользователя: если элемент выходит за её пределы (обрезан или имеет overflow: hidden), то эти части не учитываются.
Если у изображения видимый и исходный размеры отличаются, то будет учитываться меньший из них. Например, если изображение сжали до меньшего размера, чем его исходный, то передается видимый размер, а если растянули — исходный.
Для текстовых элементов учитывается только размер их текстовых узлов.
Для всех элементов любые margin, padding или border не рассматриваются.
FID (интерактивность)
Метрика First Input Delay (FID) помогает измерить первое впечатление пользователя об интерактивности и быстродействии вашего сайта.
FID измеряет время с момента, когда пользователь впервые взаимодействует со страницей, до того, как браузер действительно может начать обработку событий в ответ на это взаимодействие.
Задержка ввода возникает из-за того, что основной поток браузера занят чем-то другим (синтаксическим анализом или выполнением большого бандла), поэтому он (пока) не может ответить пользователю.
FID можно измерить только в реальных условиях.
Почему рассматривается именно первый ввод?
- Первое впечатление пользователя формирует общее впечатление о качестве и надежности сайта.
- По статистике, самая распространенная проблема с интерактивностью возникает во время загрузки страницы. Улучшение первого взаимодействия окажет наибольшее влияние на общую интерактивность.
CLS (визуальная стабильность)
Cumulative Layout Shift — важный, ориентированный на пользователя показатель для измерения стабильности верстки и элементов, не препятствующих взаимодействию с контентом.
Например, вы переходите на сайт, почитать статью. Пока сайт прогружался, на странице появилось ещё несколько элементов и положение скролла неожиданно изменилось. Неприятно.
Рис.2. Пример Cumulative Layout Shift
Первая ассоциация при виде этого примера — реклама. Думаю, что каждый хотя бы раз сталкивался с таким неожиданным появлением элемента.
Это может происходить из-за асинхронной загрузки ресурсов или динамического добавления DOM-элементов на странице. Причиной может быть изображение или видео с неизвестными размерами, сторонняя реклама или виджет, которые динамически изменяют размер.
CLS измеряет общую сумму всех показателей визуальной стабильности верстки в течение сессии страницы.
Показатель визуальной стабильности определяет Layout Instability API, который отправляет layout-shift каждый раз, когда существующий элемент меняет свое начальное положение между двумя кадрами.
Обратите внимание, что визуальная стабильность не учитывается, когда новый элемент добавляется в DOM или существующий элемент меняет размер.
Чтобы вычислить коэффициент визуальной стабильности, браузер смотрит на размер области просмотра и перемещение нестабильных элементов между двумя визуальными кадрами. Коэффициент вычисляется двумя показателями: коэффициентом воздействия и расстояния.
Рис.3. Коэффициент воздействия
На изображении выше есть элемент, который занимает половину области просмотра в одном кадре. Затем в следующем кадре элемент смещается вниз на 25% от высоты экрана. Красный пунктирный прямоугольник указывает на объединение видимой области элемента в обоих кадрах, которая в данном случае составляет 75% от экрана.
Рис.4. Доля расстояния
Доля расстояния — это наибольшее расстояние, на которое любой нестабильный элемент переместился в кадре (по горизонтали или вертикали), деленное на размер экрана.
В приведенном примере наибольшим размером экрана является высота, а нестабильный элемент перемещается на 25%.
Коэффициент визуальной стабильности = 0.75 * 0.25 = 0.1875
Как улучшить показатели Core Web Vitals?
Если ваше приложение не дотягивает до идеальных показателей, то нужно заняться вопросом повышения скорости. Итак, что можно сделать:
- Сжимать, оптимизировать (бандл, картинки и т.д.).
- Включить кеширование – это позволит ускорить доступ к страницам, которые пользователь посещал ранее.
- Использовать потенциал технологии AMP.
- Уменьшить редиректы или использовать SPA.
- Использовать CDN – это позволит распределить контент между несколькими серверами, снижая количество маршрутизаторов между конечными файлами и пользователем.
- И т.д.
Библиотеки и инструменты
Самый простой способ измерить все Core Web Vitals — использовать js-библиотеку web-vitals, которая измеряет каждую метрику в соответствии с Инструментами Google.
Или можно использовать расширение Web Vitals для Chrome.
С июля 2018 Google начали учитывать скорость страниц в выдаче. В ноябре 2019 года они добавили отчет о скорости страниц в личный кабинет Web Search Console. В июне 2021 они ужесточили критерии PageSpeed, подняв влияние Total Blocking Time (TBT) с 25% до 30% и Cumulative Layout Shift (CLS) с 5% до 15%.
Я когда-то, как и многие это делают и по сей день, искал штуку, которая бы закрыла все потребности в оптимизации своего WordPress сайта. Даже пару лет назад делал сравнительное исследование различных плагинов и их сочетаний, чтобы другим было проще ориентироваться, за что получил много положительных отзывов и благодарностей, спасибо вам за теплые слова.
Но почему-то, что в совокупности, что по отдельности не было идеального решения. У кого-то что-то лучше сделано, у кого-то хуже (сразу приходит на ум аналогия с процессом выбора автомобиля). Поскольку я разработчик, то ещё тогда закралась мысль о создании решения, закрывающего все потребности.
Решение
Оно увидело свет в этом году. Плагин написан полностью с нуля.
Проведенный тест на 72 различных сайтах (легких и тяжелых, с кучей рекламы, Elementor и т.д.) показал увеличение балла Google PageSpeed в среднем с 37% до 94% на мобильных устройствах и с 82% до 99% на десктопах. В тестах были использованы конфигурации с PHP 7.0.33, 7.1.33, 7.2.34, 7.3.28, 7.4.19, 7.4.3, 8.0.2, 8.0.5, 8.0.7 и веб-серверами Nginx 1.14.0 (Ubuntu x64), 1.20.1 (Ubuntu x64), Apache 2.4.6 (CentOS x64), 2.4.41 (Ubuntu x64), 2.4.35 (Windows x86), 2.4.46 (Windows x64).
Один нюанс, который можно отнести к недостаткам – решение платное. Но цена весьма скромна в сравнении с другими платными решениями. Да и функциональность получилась шире.
Далее о ключевых особенностях.
Никаких внешних сервисов и зависимостей
Максимальная работоспособность без настроек
Хорошо и правильно, когда работает сразу. Многие плагины приходится долго мучительно настраивать, чтобы поучить стабильное поведение и какой-то результат. Настройки подобраны так, чтобы максимально охватить все конфигурации, минимально вмешиваться в структуру сайтов и сразу увидеть результат оптимизации. Но сами настройки гибкие и большие.
Необходимое использование сторонних библиотек
Чем меньше кода, тем лучше. Использованы внешние библиотеки только по явной необходимости.
Ленивая загрузка
Фронтенд. Он должен быть легким, надежным и достаточно быстрым. Выбор пал на LazySizes.
Минификация JS
Бекэнд. Используется проверенная временем JsMin-Php.
Минификация CSS
Бекэнд. Используется проверенная временем YUI CSS compressor PHP port.
Разбор CSS
Бекэнд. Также используется для минификации. Выбрана актуальная и хорошо поддерживаемая с аккуратным кодом библиотека PHP CSS Parser. Используется взамен предыдущей. Но предыдущая быстрее, т.к. там нет полного парсинга структуры. В планах проведение сравнительного тестирования скорости обеих, чтобы понять можно ли оставить только эту, т.к. она более универсальная. В идеале её вообще сделать нативной, как следующую.
Разбор HTML
Бекэнд. Используется встроенный в PHP DOMDocument как надежный и самый быстрый в силу своей нативной реализации.
Производительность в критических по времени местах
Важные и критические к быстродействию части кода были отдельно протестированы на скорость. Например:
json_decode() или unserialize()
Сравнивались, когда выбирался формат хранения данных для дескрипторов страниц. Последнее на 5% быстрее (предположительно из-за наличия длин полей).
unserialize(gzdecode()) или unserialize()
Последнее быстрее на 20%, но размер данных у первого меньше на ~40%. Т.к. дескрипторы страниц занимают мало места по сравнению с основными данными (почему так – в следующем разделе), то решено было сжатие не использовать в угоду скорости. Пример сайта с 14000 страницами в кэше: суммарный размер дескрипторов ~170 МБ и суммарный размер данных ~1500 МБ, т.е. примерно 10%.
substr($s, 0, 3) === 'abc' или strpos($s, 'abc') === 0
Используется при проверке исключений. Очень часто встречается PHP код, где для проверки начала строки используется substr. Понятно, что если строка длинная, то первый способ будет быстрее. Но на малых длинах строки $s (примерно до 100-130 символов) второй способ уже будет быстрее. Например, при длине строки в 30 символов, быстрее будет на 25%. Скорее всего, по этой причине в PHP 8 добавили str_starts_with.
Формат данных важен, т.к. на продакшене его изменить гораздо тяжелее, чем алгоритм. Замеры делались на PHP 7.4.20 и PHP 8.0.7, CPU Intel Core i7 3.4 ГГц, RAM 1600 МГц.
Оптимизация размера кэша
За место на хостинге мы платим почти всегда. Да и чем меньше данных, тем быстрее к ним доступ. А значит загрузка страниц будет быстрее.
Выделение одинаковых блоков
Т.к. страницы сайта похожи друг на друга – имеют общие части такие как хедер, футер, то хранение таких блоков в единственном экземпляре сильно экономит место. Это позволяет эффективно кэшировать зависящие от параметров страницы (например переключение валюты) или пользовательские сессии. Настраивается тут.
Сжатие
Также, по умолчанию кэш хранится в сжатом виде. Используется для:
- экономии места;
- для ускорения отдачи заранее сжатого контента.
Настраивается тут.
Также, небольшой размер кэша позволяет эффективнее использовать технологии кэширования в памяти, такие как Redis и Memcached. Это актуально для высоконагруженных сайтов. Их поддержка планируется в скором будущем. Напишите, пожалуйста, кому это важно – это позволит поднять в приоритете реализацию.
Распределение по нескольким CDN
Задавая несколько серверов, можно, например, разделить нагрузку на основной хостинг и (или) сэкономить на их тарифе. Настраивается тут.
Эффективное обновление данных
Кэш нужно обновлять, т.к. данные меняются. И делать это надо с минимальными затратами. Сильно влияет на First Contentful Paint (FCP), т.к. определяет время до получения первого байта от сервера.
Устойчивость к высоким нагрузкам
Когда запросов к сайту много, то обновление страницы может привести к сильной загрузке хостинга. Для предотвращения этого сделано так, что когда страница обновляется, то параллельные запросы к той же странице используют кэшированные данные. Но запрос, инициирующий это обновление, ждет окончания обновления. А избежать и этого помогает следующий пункт.
Ленивое обновление страниц
Позволяет страницам всегда браться из кэша, даже когда идет обновление данных. Очень полезно, когда поисковые системы (особенно Google и Yandex) постоянно мониторят скорость страниц, т.к. всегда быстро возвращается оптимизированная страница. Настраивается тут.
Оптимизация изображений и видео
Как показывает опыт SEO, наличие видео очень хорошо сказывается на времени нахождения пользователей на страницах. Да и красивые картинки делают просмотр приятнее. Но это не должно негативно влиять на скорость загрузки контента.
Ленивая загрузка изображений
Она реализована через обозначенную выше библиотеку с добавлением встроенного прозрачного изображения того же размера, чтобы при загрузке не было «скачков» элементов, что положительно влияет на показатель Cumulative Layout Shift (CLS). Сам подход влияет в основном на Largest Contentful Paint (LCP) и на First Contentful Paint (FCP).
Ленивая загрузка видео и фреймов
Очень важная штука, т.к. фреймы (особенно видео) сразу грузят большое количество скриптов, что сразу уводит рейтинг скорости сильно вниз баллов на 25-30, влияя на все показатели, кроме разве что Cumulative Layout Shift (CLS). Сделано так, что внедрение подменного быстрого блока вообще не ломает разметку исходной страницы в отличие от других плагинов.
Уменьшение размера изображений
Т.к. изображения подгружаются лениво, то это сильно снижает влияние на результат. Поэтому реализация отложена в следующие версии плагина. Пока можно использовать сторонние, например, бесплатный EWWW Image Optimizer (у него правда под Windows плохо работает конвертация в WebP).
Встраивание мелких изображений
По умолчанию изображения менее 2 КБ встраиваются в HTML и CSS. Это максимально ускоряет их загрузку. Настраивается тут.
Оптимизация стилей (CSS)
Выделение критических частей
Это очень сильно влияет на показатель First Contentful Paint (FCP). Т.к. чем быстрее загрузятся первоначальные данные страницы, тем быстрее она нарисуется. Обычно, у сайтов много некритичных стилей, которые могут быть отложено загружены. По опыту прибавляет в среднем 10-15 баллов к показателю.
Группировка
Снижает количество запросов к серверу, тем самый уменьшает время загрузки страницы. По опыту прибавляет в среднем 5-10 баллов к рейтингу, влияя на показатель Total Blocking Time (TBT), важность которого подняли с 25% до 30% в 8 версии PageSpeed.
Отложенная загрузка шрифтов
Делается стандартно через добавление font-display:swap атрибута. Плюс они не попадают в критические стили, что снижает размер страницы, особенно когда используются объемные Google Fonts. Настраивается тут.
Минификация
Делается через специальную библиотеку, обозначенную выше.
Оптимизация скриптов (JS)
И наконец, скрипты – сама сложная часть страниц, которая хуже всего поддается оптимизации. Встречаются скрипты, которые зависят от своего местоположения (например, рекламные от Google AdWords). Поэтому оптимизация по умолчанию делает минимальные изменения. Большинство оптимизирующих плагинов как раз чаще всего «ломают» скрипты.
Группировка
По аналогии с CSS, снижает количество запросов к серверу, тем самый уменьшает время загрузки страницы. Но по опыту, т.к. скрипты в основном грузятся отложено, то ощутимого прироста рейтинга это не дает, а вероятность нарушить их работу повышает. GTMetrix показывает количество запросов, и включением этого режима можно попробовать увеличить на нём балл.
Минификация
Делается через специальную библиотеку, обозначенную выше.
Отложенная загрузка
Очень сильно влияет на показатели Total Blocking Time (TBT) и Time to Interactive (TTI). Потеря может достигать 30 баллов (прямо пропорционально объему скриптов). Самым эффективным способом оптимизации скриптов является задержка их загрузки. Но скрипты нужны для корректного отображения страницы. Поэтому они разделены на 3 группы:
Критичные
Сюда попадает всё что должно быть загружено до содержания главной страницы. Обычно тут пусто.
Некритичные
Всё что можно загрузить после содержимого главной страницы с задержкой. Здесь обычно все основные скрипты сайта.
Специальные
Всё, что можно загрузить ещё позже и не влияющее на основной рендеринг страницы. Сюда относятся, например, скрипты трекинга, рекламы, соц-сетей и т. д.
По умолчанию времена задержек загрузки некритичной и специальной групп выставлено для наибольшей совместимости и наилучшего показателя скорости. Для конкретных сайтов эти значения опытным путём можно уменьшать.
Что дальше
Решение протестировано с самыми популярными плагинами, не "ломает" рекламные скрипты, скрипты аналитики, видео-фреймы, и директивы Яндекса. По статистике, около 20% сайтов требуют дополнительной настройки, большая часть которых конечно-же скрипты.
Оптимизация изображений
Для ещё большего ускорения и доведения решения до полной комплектации. Как отмечалось выше, приоритет этой функции был понижен – надо было, чтобы продукт увидел свет.
Предварительный прогрев страниц
В обычном режиме плагин ставится и сайт должен сразу стать быстрым. Сейчас страницы оптимизируются только при первом к ним обращении. Поэтому сейчас в начале присутствует инерционность, если сайт не имеет большого трафика.
Кэширование пользователей
Оно и сейчас уже работает, но пока в состоянии «бета» - совместимость только с некоторыми плагинами. Нужно провести полное тестирование на различных популярных плагинах, для которых это критично, например, онлайн курсов, онлайн магазинов, поддержки аффилиата и прочих. Напишите, пожалуйста, какие плагины вам актуальны.
Расширение статистики
Сейчас в статусе отображается самый минимум. Нужно добавить больше данных для мониторинга, например эффективность сжатия, включены ли все нужные подсистемы на хостинге и прочее. Вообще нужно показывать некое «здоровье» оптимизации.
Использование кеширования в памяти
Поддержка, например, Redis и Memcached, упомянутая выше.
Заключение
Тема оптимизации ещё больше набирает обороты – возникает много решений в этой области. Тем более, что сам WordPress уже имеет 60 млн установок (что уже более 40% от общего количества сайтов) и продолжает расти. Да и Google будет и дальше изменять критерии, может, и Yandex тоже чем-нибудь подобным займется.
Также, в ближайших планах сделать отдельно анализ влияния различных оптимизаций на скорость страниц и итоговое влияние на PageSpeed score. Это позволит понимать при выборе кэширующего/оптимизирующего решения, на какие фичи обращать внимание и что актуально для конкретных сайтов. Например, для статичных сайтов с HTML, где страницы уже оптимизированы, можно просто задать кэширование браузера.
По любым вопросам я почти всегда на связи. Есть скидки для тех, кто с Хабра. Рассматриваются различные варианты сотрудничества.
Читайте также: