First contentful paint что это
Как измеряются метрики сайта: LCP, FID и CLS
Авторизуйтесь
Как измеряются метрики сайта: LCP, FID и CLS
5 мая 2020 года Google представили Web Vitals — важные метрики сайтов которые позволяют измерить удовлетворенность пользователей и влияют на SEO. В этой статье мы расскажем что это за показатели и как они измеряются.
Основные метрики сайтов
LCP — Largest Contentful Paint
Это время отрисовки самой большой и видимой части содержимого на первом экране вашего сайта. Это может быть картинка, видео или текст (подробнее в блоге Google). Для хорошего пользовательского опыта значение LCP не должно превышать 2,5 секунды.
FCP — First Contentful Paint (Первая отрисовка контента)
Как измерить LCP?
LCP в реальных условиях можно измерить с помощью этих инструментов:
Для лабораторных измерений используют следующие инструменты:
Чтобы измерить LCP с помощью JS и Largest Contentful Paint API, можно использовать следующий код:
В приведенном выше примере, каждое событие largest-contentful-paint представляет текущего кандидата на роль LCP. В общем случае, значение startTime для последнего события является значением LCP, однако это не всегда так. Не все события подходят для измерения LCP.
Результаты работы API и то, как на самом деле рассчитывается метрика сайта, отличаются:
Чтобы не вдаваться в эти подробности можно использовать web-vitals JavaScript библиотеку, которая сделает всё за вас:
Что если самый большой элемент на экране не является самым важным?
В таком случае, для измерения времени загрузки других элементов можно использовать Element Timing API.
FID — First Input Delay
FID — это время через которое пользователь может начать взаимодействовать с сайтом. Значение не должно превышать 100 миллисекунд. В новом PageSpeed этот параметр заменят на TBT (Total Blocking Time), который вычисляет блокировку содержимого сайта.
Как измерить FID?
FID — это метрика сайта, которую можно измерить только в реальных условиях, так как она требует наличия реального пользователя, взаимодействующего с вашей страницей. Вы можете измерить FID с помощью следующих инструментов:
Метрика общего времени блокировки (TBT) измеряется в лабораторных условиях, хорошо коррелирует с FID в реальных условиях, а также фиксирует проблемы, влияющие на интерактивность. Оптимизация, улучшающая TBT в лаборатории, также должна улучшить FID для пользователей.
Чтобы измерить FID можно использовать Event Timing API. Вот примерный код на JS:
Список различный между работой API и реальной метрикой, похож на список для LCP. Поэтому и здесь лучше использовать web-vitals JavaScript library.
CLS — Cumulative Layout Shift
CLS измеряет степень стабильности контента на вашем сайте. Значение будет увеличиваться от элементов сайта (картинок, рекламных блоков и тд.) которые загружаются позже и вызывают смещение контента. Подробнее о CLS в нашем переводе — «Что такое CLS сайта и почему он важен».
Как измерить CLS?
CLS можно измерить синтетически (в лаборатории) или для реальных пользователей (через RUM). Лабораторные измерения могут фиксировать только изменения вёрстки при однократной или многократной загрузке страницы, в то время как измерения RUM будут в большей степени отражать то, что видят реальные пользователи, когда они взаимодействуют с сайтом.
Величина совокупного сдвига вёрстки — это сумма влияния всех неожиданных сдвигов вёрстки, которые происходят с пользователем в течение определенного периода времени. Считаются только сдвиги контента, который виден на экране. Всё, что находится за пределами экрана, не влияет на пользователя. Чтобы рассчитать балл CLS по каждому сдвигу вёрстки, нам нужно рассмотреть две составляющие этого сдвига: его долю воздействия и долю расстояния.
Доля воздействия измеряет, насколько сильно экран изменился от одного кадра (момента) к следующему. Доля расстояния измеряет наибольшее расстояние, пройденное любым из этих нестабильных элементов на экране.
Обычно измерение производится до вызова браузером события onload.
CLS поддерживается множеством JS библиотек для измерения метрик сайта, например boomerang.js и perfume.js.
Каждое вхождение layout-shift это событие, которое происходит, когда элемент меняет своё положение между двумя кадрами. Элемент, просто изменивший свой размер или впервые добавленный в DOM, не обязательно вызовет сдвиг разметки, если он не повлияет на другие видимые элементы DOM.
Сдвиг разметки это не всегда плохо. Например если пользователь нажимает на кнопку на одностраничном сайте, это может быть ожидаемым поведением. Каждое событие layout-shift имеет флаг hadRecentInput, сообщающий, был ли ввод от пользователя за 500мс от сдвига. Если это так, то этот сдвиг разметки, вероятно, можно исключить из CLS.
Открытых библиотек для измерения CLS множество, например, Boomerang или web-vitals.
Флаг buffered: true нужен, чтобы учитывать каждый layout-shift, произошедший до инициализации обсервера. Это особенно полезно для скриптов, библиотек и сторонних систем аналитики, подгружающихся асинхронно.
Каждый коллбек обсервера будет хранить список сдвигов в list.getEntries().
Каждый сдвиг это объект LayoutShift:
Если вам нужно просто посчитать CLS, вы можете добавить value каждого layout-shift, если его hadRecentInput — false.
Для более детальной информации о сдвигах, добавьте sources.
Если вы хотите просматривать веб страницы и в реальном времени наблюдать изменение CLS, попробуйте этот простой скрипт для Tampermonkey и расширение для Chome — Web Vitals.
Для лабораторных измерений можно использовать:
В Chrome Developer Tools у вас есть доступ к аудиту производительности Lighthouse. Перейдите на вкладку Lighthouse и запустите Perfomance Audit:
Кроме CLS верхнего уровня, вы можете просмотреть составляющие его сдвиги:
Здесь видно баг — смещения в IFRAME, которые не влияют на общий балл CLS, но отображаются в списке
Если вы нажмете на кнопку View Original Trace в разделе Аудит, откроется вкладка Perfomance. На вкладке Perfomance теперь есть новый столбец Experience, в котором на временной шкале отображаются отдельные смещения разметки и данные о них.
Помимо трассировки вы можете обнаруживать сдвиги во время просмотра сайта с помощью визуальных индикаторов. Для этого нажмите Rendering в меню More Tools. Затем включите Layout Shift Regions. Теперь во время просмотра страницы сдвиги разметки будут отмечаться голубой подсветкой.
Другие метрики сайтов
Кроме основных метрик, которые Google считает критическими, существуют и дополнительные. Например, метрики: Time to First Byte (TTFB) и First Contentful Paint (FCP) — являются жизненно важными аспектами процесса загрузки и полезны при диагностике проблем с LCP (медленное время отклика сервера или ресурсы блокирующие отрисовку страницы).
3–4 декабря, Онлайн, Беcплатно
Также, такие метрики сайта как: Total Blocking Time (TBT) и Time to Interactive (TTI), измеряются лабораторными методами и помогают обнаружить потенциальные проблемы с интерактивностью страницы.
Core Web Vitals: как Google решил оценивать сайты
Сегодня поговорим о важности пользовательского взаимодействия, ведь совсем скоро придется подготовить свои сайты к максимальному ускорению загрузки. Возможно, вы уже слышали про Core Web Vitals…
В прошлом году Google начал масштабный пересмотр факторов ранжирования в поисковике, чтобы улучшить качество поисковой выдачи. И в ноябре команда Google анонсировала Core Web Vitals — новые факторы оценки качества ресурсов, которые смогут влиять на индексацию и вступят в силу в мае 2021 года. Давайте разбираться.
Существуют сотни факторов ранжирования, однако Core Web Vitals будет анализировать ещё больше информации и иметь непосредственное влияние на дальнейшую индексацию. Нужно отметить, что скорость загрузки напрямую не влияет на индексацию, однако имеет значительное влияние на поведение пользователя, которое является важным сигналом для поисковых алгоритмов Google.
Чем Core Web Vitals отличается от прочих факторов ранжирования?
Положительная сторона Core Web Vitals — в прозрачности: это понятные, публично доступные критерии, которые можно отслеживать и улучшать с помощью специального набора инструментов. Кроме того, с момента анонсирования и до официального запуска есть много времени, чтобы уже начать работать над Core Web Vitals.
Андрей Липатцев, Web Partnerships Google
Core Web Vitals
Среди многих показателей ранжирования (оптимизации для мобильных устройств, безопасный просмотр, безопасность HTTPS и т.д.) Google выделил основные (core), жизненно важные для пользователя. Метрики, составляющие Core Web Vitals, со временем будут развиваться и дополняться.
Текущий набор показателей фокусируется на трех аспектах взаимодействия с пользователем: 
LCP (загрузка)
Для разработчиков всегда было непросто измерить, насколько быстро контент веб-страницы загружается и становится видимым для пользователей.
Старые метрики, такие как load или DOMContentLoaded, не подходят, так как они всегда соответствуют тому, что пользователь видит на экране. А более новые показатели производительности, такие как First Contentful Paint (FCP), отражают только самое начало процесса загрузки.
В ходе исследований обнаружилось, что более точный способ измерить загрузку основного содержимого страницы, – это посмотреть, когда был отрисован самый большой элемент.
Так появилась метрика Largest Contentful Paint (LCP), которая измеряет время рендеринга самого большого элемента на странице. 
Что считается большим элементом?
Как это работает?
Веб-страница загружается поэтапно, и в результате самый большой элемент на ней может измениться.
Чтобы справиться с таким изменением, браузер отрисовывает первый кадр и отправляет PerformanceEntry с параметром large-contentful-paint, который идентифицирует самый большой элемент. Но затем, после рендеринга последующих кадров, браузер будет отправлять PerformanceEntry при каждом изменении самого большого элемента.
Важно отметить, что элемент может считаться самым большим содержимым только после того, как он будет отрисован и виден для пользователя.
Браузер перестает сообщать о новых записях, как только пользователь начнет взаимодействовать со страницей, поскольку взаимодействие может визуально изменить страницу (прокрутка, модальное окно и т.д.).
Рис.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?
Если ваше приложение не дотягивает до идеальных показателей, то нужно заняться вопросом повышения скорости. Итак, что можно сделать:
Библиотеки и инструменты
Самый простой способ измерить все Core Web Vitals — использовать js-библиотеку web-vitals, которая измеряет каждую метрику в соответствии с Инструментами Google.
Или можно использовать расширение Web Vitals для Chrome.
Не забывайте периодически следить за скоростью загрузки своего приложения. Быстрая реакция на любые негативные изменения позволит минимизировать потери и вовремя внести необходимые коррективы. Core Web Vitals влияет не только на индексацию, но и главным образом на конверсию, посещаемость и в результате на прибыль. К счастью, Google предупредил заранее о запуске новых факторов ранжирования, поэтому у вас есть еще время исправить все погрешности к запуску Core Web Vitals (май 2021).
Полезные ссылки и используемые материалы:
«Зелёная» зона в PageSpeed: как оптимизировать сайт и сколько это стоит
Время прочтения: 10 мин.
Скорость загрузки — один из ключевых факторов успешного продвижения сайтов любого типа. Метрика влияет на поведенческие факторы, лояльность аудитории и высокие оценки в поисковиках. В статье разберёмся, как работает PageSpeed, насколько трудно получить высокую оценку в сервисе и сколько денег придётся потратить.
Как PageSpeed определяет скорость загрузки
PageSpeed Insights — инструмент Google, который оценивает оптимизацию и скорость загрузки веб-сайтов. Новички должны сразу понять, что сервис носит рекомендательный характер. Поисковик постоянно говорит об этом, но многие вебмастера в погоне за высокими баллами забывают о его советах.
Алгоритм работы инструмента:
Оптимизацию и скорость загрузки проверяет сервис Lighthouse. За последние несколько лет он стал эталоном в нише. Lighthouse получает данные из средств отладки Chrome. Он измеряет производительность Javascript, количество сетевых запросов и собирает важные метрики в едином документе.
Какие показатели учитывает Lighthouse:
Lighthouse в ходе проверки выставляет для каждой метрики оценку от 0 до 100. К примеру, если время загрузки для взаимодействия (TTI) составит 2,1 секунды — сервис поставит оценку 92/100 для этого критерия.
Lighthouse имитирует загрузку на одном устройстве с определённым набором условий. Данные PageSpeed и других сервисов могут сильно отличаться. У каждого инструмента свои методы и показатели, которые влияют на общую оценку.
В PageSpeed недавно появилась функция раскадровки, которая делает скриншоты экрана на разных этапах имитации загрузки. Слайды показывают, насколько быстро прогружается контент и становится доступен ввод.
PageSpeed делит проверку на три составляющих: оптимизация, диагностика и успешные аудиты. В первом пункте показываются рекомендации по улучшению показателей скорости загрузки. Инструмент наглядно отображает, насколько повысится производительность после выполнения рекомендаций. В разделе «Диагностика» представлены важные проблемы, которые влияют на скорость загрузки страницы. Во вкладке «Успешные аудиты» отображаются пройденные проверки.
Эталоном оптимизации сайта считается оценка от 90 баллов и выше. Это «зелёная» зона, в которую мечтают попасть владельцы контентных проектов. Опытные вебмастера знают, что показатели PSI надо воспринимать критично и анализировать производительность по более понятным метрикам. А вот новички гонятся за высокими оценками. У них включается синдром «отличника» и возникает желание набрать 100 баллов любой ценой.
В некоторых случаях оптимизация производительности влияет на удобство использования. Запомните важное правило — если в процессе ускорения сайта пользователи лишились важных инструментов, поведенческие факторы могут ухудшиться, и работа будет проделана зря.
Три важных особенности, которые надо знать всем вебмастерам
В ноябре 2019 года Google добавил метрику скорости загрузки в Search Console. В связке с Google Analytics можно увидеть, какие страницы загружаются быстро, сколько URL-адресов тянут сайт на дно, и как изменились показатели за неделю или месяц.
Данные поступают из отчёта Chrome User Experience. В него поступает информация об использовании сайта юзерами с разных уголков планеты. Google отмечает, что раздел экспериментальный. Опытные вебмастера понимают, что поисковики не делают ничего просто так. Отчёт появился в Search Console, чтобы владельцы сайтов видели проблемы и оперативно их решали.
Важно понимать, что Google не оценивает быстродействие проекта по конкретной странице или одному показателю. Время до получения первого байта показывает, как быстро сервер отвечает на запрос браузера, но этого недостаточно для оценки пользовательского опыта. Поисковая система оценивает метрики в совокупности, поэтому надо улучшать известные параметры по максимуму.
Инструменты для проверки быстродействия сайта
Для оценки быстродействия используйте традиционный набор инструментов:
GTmetrix собирает данные PageSpeed, Yslow в одном интерфейсе. Он показывает оценку по 100-бальной шкале для каждого пункта и даёт полезные рекомендации.
Зарегистрированным пользователям открываются дополнительные привилегии: тайминги загрузки и видео проверки. Во вкладке с историей отображаются показатели с привязкой к датам проверки.
Tools Pingdom после проверки показывает важные метрики: оценку быстродействия, вес страницы, скорость загрузки и количество запросов. В отдельном блоке доступны рекомендации для улучшения производительности, статистика контента по типам, запросы по доменам.
Loading Express агитирует заказать ускорение сайта у профессиональных специалистов, но при этом даёт полезные цифры: время ответа сервера, полной загрузки, выполнения Javascript и первой отрисовки страницы. Сервис показывает, сколько пространства можно сэкономить после добавления отложенной загрузки картинок, кэширования и оптимизации картинок.
Влияет ли скорость на позиции?
В среде SEO-специалистов и вебмастеров постоянно идут споры по поводу связи между скоростью загрузки проекта и позициями в поисковиках. Участники дискуссии традиционно делятся на два лагеря. Первые говорят, что быстродействие влияет только на удобство использования сайта и скорость загрузки не является фактором ранжирования. Вторые утверждают, что скорость — основа поведенческих факторов. Чем быстрее грузится контент, тем лучше. Есть много аргументов в пользу двух мнений.
Точно известно, что никто не любит медленные сайты:
Владельцам контентных проектов надо сделать так, чтобы контент на первом экране грузился почти сразу после запроса браузера. Это одно из главных требований поисковой системы к производительности.
Второй важный критерий — оптимизация мобильной версии сайта. С 2019 года Google перевёл сайты на Mobile-first index. Это значит, что независимо от того, с какого устройства пользователь делает запрос, ему показываются результаты мобильной выдачи. Раньше алгоритм работал иначе — поисковая система определяла девайс и показывала соответствующую выдачу. Поисковая система после введения нового алгоритма отметила, что сайты, оптимизированные под мобильные устройства, получат преимущество в ранжировании.
Если проверите вкладку «Уведомления» в Search Console, скорее всего, там будет письмо с переводом сайта на Mobile-first. Это логично, доля мобильных устройств с каждым годом увеличивается. Десктопы остаются незаменимыми помощниками для решения рабочих задач, но пользователи уже давно общаются, читают новости и делают покупки с телефона. С активным развёртыванием 5G-сетей по всему миру тенденция увеличится ещё больше. Уже сейчас в статистике систем аналитики мобильный трафик значительно превышает десктопный. Иногда соотношение доходит до 90/10%.
Некоторые вебмастера часто говорят, что в топе выдачи много медленных сайтов с устаревшим дизайном и большим количеством рекламы. Это действительно так. Всегда есть проекты, которые хорошо ранжируются, несмотря на серьёзные проблемы. А сайты с современным оформлением и 1-2 секундной загрузкой остаются за бортом.
Не надо делать сайт быстрее в надежде получить бонусы от поисковых систем. Любой проект разрабатывается под конкретную целевую аудиторию. Из этого плавно вытекает формула успеха:
Быстрый сайт с полезным контентом = любовь аудитории.
Оптимизация производительности положительно повлияет на поведенческие факторы. Значит, есть шанс улучшить позиции по тематическим запросам и общую видимость проекта в нише.
Чтобы закрепить уверенность в том, что скорость влияет на ранжирование в поисковиках, посмотрите результаты исследования западной компании SparkToro. Команда проекта опросила больше 1500 SEO-специалистов и составила рейтинг факторов в порядке важности.
На первом месте по традиции находится релевантность контента намерениям пользователей. 5 место специалисты отдали удобству мобильной версии, а скорость загрузки расположили на 12 месте. При этом Google AMP и возраст сайта находятся в конце рейтинга.
Как ускорить сайт на WordPress
В статье мы не будем зацикливаться на том, как набрать 100 баллов по PageSpeed Insights. Расскажем, что влияет на скорость загрузки и как решить задачу своими силами. Рассмотрим процесс оптимизации на примере WordPress, некоторые рекомендации будут актуальны для сайтов на других CMS.
Сократить время ответа сервера
Первое, что надо сделать — проверить время ответа сервера. Если браузер слишком долго ждёт получения контента, это влияет на общую производительность.
На ответ сервера влияют следующие факторы:
Если сайт размещён на виртуальном хостинге, свяжитесь с техподдержкой, чтобы вместе найти решение. При использовании VPS и физических серверов пригодится помощь опытного системного администратора. Настроить оборудование без опыта и знаний не получится. Неправильная конфигурация может негативно повлиять на скорость работы и поведенческие факторы.
Вариантов два — оптимизировать программное обеспечение на текущем хостинге или переехать к другому провайдеру на более мощный тариф. У сервера всегда должен быть запас производительности, чтобы выдержать скачки посещаемости. Например, на время пандемии коронавируса в России ввели дистанционное обучение, многие начали работать из дома. Вместе с повышением трафика на образовательных проектах увеличилась нагрузка. Если сайт будет слишком долго грузиться или периодически «падать», поисковые системы могут ввести санкции.
Настроить кэширование
Новичкам следует знать, что есть несколько видов кэширования. При настройке серверного кэша время ответа сокращается в несколько раз. Серверу не надо каждый раз генерировать страницу целиком, он показывает сохранённую версию и экономит мощность. Кэширование в браузере работает иначе: при посещении веб-сайтов на устройстве сохраняется «снимок» контента. На компьютерах и смартфонах резервируются тексты, картинки, скрипты.
На многих хостингах предлагаются две технологии кэширования: Redis и Memcached.
Работают они примерно одинаково и при правильных настройках можно использовать оба инструмента одновременно. Почти у всех хостинг-провайдеров обе услуги платные. К примеру, у Hostland Memcached на 1024 МБ предоставляется за 120 рублей в месяц.
Сторонние разработчики сделали большое количество плагинов кэширования под WordPress.
Самые популярные:
WordPress и большинство готовых CMS динамически генерируют страницы на лету. Для этого надо делать запросы к базе данных, чтобы получить разные части контента. Кэширование через плагины позволяет юзерам видеть обычные HTML-страницы. Такое решение значительно снижает время загрузки и разгружает сервер.
Сделать базовую настройку среды
Оптимизацию сайта надо делать до публикации проекта в открытый доступ. Чтобы люди и поисковые системы оценили конечный результат.
Что надо сделать:
Оптимизировать изображения
Главная проблема многих проектов — «тяжелые» картинки. Пейзажи в 4K, неоптимизированные JPG и принудительное изменение размеров. Решать задачу надо в комплексе. В результате вес страницы уменьшится, а время загрузки и быстродействие увеличатся.
Что надо сделать:
Некоторые эксперты советуют использовать формат WebP, который обеспечивает в среднем на 30% большее сжатие по сравнению с JPEG и PNG. Проблема в том, что его поддерживают только 80% браузеров.
Сжать HTML, CSS и Javascript
Смысл оптимизации или минификации кода в том, что в итоге уменьшается их вес и время обработки данных. Некоторые плагины под WordPress умеют объединять скрипты в один файл. Они собирают участки кода в одном месте и уменьшают количество запросов.
Самое популярное решение для оптимизации WordPress сайта — плагин Autoptimize. Он умеет:
При правильной настройке Autoptimize даёт значительный прирост производительности, но есть и минус — может нарушиться работа некоторых модулей. Часто возникает проблема с плагинами кэширования. После установки Autoptimize тщательно проверьте сайт и добавьте в исключения Javascript файлы, если найдёте «поломки».
Отложенная загрузка скриптов
Скрипты — слабое место многих сайтов. Если установлено 5-10 плагинов и каждый подгружает 3-5 Javscript файлов получается большой объём данных. Autoptimize частично решает проблему, но можно пойти дальше и отложить загрузку скриптов на определённое время. Для этого в код подключения скрипта надо добавить тег asynс. Можно вручную отредактировать все файлы, но лучше использовать решение, которое добавит тег автоматически. Это можно сделать через плагин или код.
Оптимизация базы даных
Скорость работы БД влияет на производительность сайта и обработку запросов. Со временем в базе данных собирается «мусор». Плюс некоторые плагины после удаления оставляют таблицы. Оптимизировать БД можно вручную или с помощью плагинов. Подойдите к решению задачи ответственно, чтобы не нарушить работоспособность проекта.
Стоимость оптимизации силами фрилансеров
Некоторые готовые темы под WordPress попадают в «красную» зону PageSpeed и грузятся больше 5-10 секунд. Если добавить к этому 10-20 плагинов, производительность упадёт ещё сильнее.
На биржах фриланса много предложений оптимизировать показатели PageSpeed до 90-100 баллов. Большинство исполнителей просто установят Autoptimize и в лучшем случае настроят CDN. Стоимость услуг от 500 рублей до 10 тысяч рублей.
Что надо проверить после ускорения сайта фрилансерами:
Улучшать скорость загрузки и быстродействие информационных сайтов однозначно надо, но делайте это правильно и не в ущерб пользовательскому опыту.
Если захотите оптимизировать проект своими силами — посмотрите полезный вебинар от канала WPlovers. Во время 6-часового стрима разработчик снизил TTFB в 5 раз, вес страницы в 8 раз, показатели PSI на 50 баллов в мобильной версии и 25 в десктопной.