Скорость загрузки сайта: SEO-руководство по сокращению времени загрузки

Что такое скорость страницы?

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

В конце концов, Google остановился на трех показателях, которые теперь считаются наиболее важными для скорости страницы: наибольшая отрисовка содержимого (LCP), задержка первого ввода (FID) и совокупный сдвиг макета (CLS). Эти показатели, известные под общим названием Core Web Vitals , предназначены для измерения воспринимаемой скорости страницы в отличие от фактической скорости страницы.

Largest Contentful Paint (LSP)

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

First Input Delay (FID) — задержка первого входа

First Input Delay — это задержка между рисованием интерактивного элемента и моментом, когда он становится функциональным. Допустим, на странице нарисована кнопка, вы нажимаете на нее, но она еще не реагирует. Контрольные показатели для этого показателя следующие:

Одна из проблем заключается в том, что некоторые инструменты используют лабораторные данные вместо полевых данных, в то время как Google ранжирует ваши страницы исключительно на основе полевых данных. Вы можете отличить эти инструменты друг от друга, поскольку они заменяют метрику FID только в полевых условиях метрикой TBT (общее время блокировки), измеренной в лаборатории.

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

Из перечисленных выше инструментов Google, вероятно, лучше всего использовать  . Там вы можете перейти в Experience> Core Web Vitals и просмотреть отчет сразу для всех ваших страниц:

Под отчетом есть список всех неудачных показателей:

Возможно, лучший способ измерить скорость страницы — использовать WebSite Auditor . Там вы можете перейти в раздел Структура сайта> Аудит сайта и получить массовый отчет о скорости загрузки всего вашего сайта, а также просмотреть все затронутые страницы — и все это с единой панели инструментов:

Или вы можете переключиться на Аудит сайта> Страницы> Скорость страницы и просмотреть список страниц с противоположными проблемами скорости, которые на них влияют. Щелкните любую страницу, и вы также получите список элементов страницы, которые можно оптимизировать для повышения производительности:

Используя онлайн-компрессор, я сэкономил от 30% до 75% на изображение и 68% в целом (более тяжелые изображения увеличивают вес и искажают процент).

4. Отложите закадровые изображения

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

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

5. Конвертируйте гифки в видео.

Это может показаться нелогичным, но файлы GIF часто имеют больший размер, чем видео. В этом нет смысла, я не знаю, как это произошло, но преобразование большого gif в видео приведет к уменьшению размера до 500% или даже больше. Итак, если в вашем отчете о скорости страницы говорится об  использовании видеоформатов для анимированного контента,  вы можете отнестись к этому серьезно.

Чтобы конвертировать гифки в видео, вы можете использовать любой онлайн-конвертер или скачать такой инструмент, как FFmpeg . На самом деле Google рекомендует создавать два формата видео: WebM и mp4. WebM похож на WebP в том, что он легче, но еще не поддерживается всеми браузерами. Итак, когда вы добавляете свое видео на страницу, вы должны сначала указать версию WebM, а затем версию mp4 в качестве резервной копии:

<video autoplay loop muted playsinline>
<source src=»animation.webm» type=»video/webm»>
<source src=»animation.mp4″ type=»video/mp4″>
</video>

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

6. Отложите неиспользуемый CSS

Неиспользуемый CSS может замедлить построение браузером дерева рендеринга. Дело в том, что браузер должен пройти по всему дереву DOM и проверить, какие правила CSS применяются к каждому узлу. Следовательно, чем больше неиспользуемого CSS, тем больше времени потребуется браузеру для вычисления стилей для каждого узла.

Цель здесь — определить неиспользуемые или некритичные части CSS и либо полностью удалить их, либо изменить порядок их загрузки. Пожалуйста, обратитесь к этому руководству, чтобы узнать, как отложить неиспользуемый CSS .

7. Минимизируйте JS и CSS.

Файлы JS и CSS часто могут содержать ненужные комментарии, пробелы, разрывы строк и фрагменты кода. Их удаление может сделать ваши файлы на 50% легче, хотя в среднем минимизация будет намного меньше. Тем не менее, это незначительный вклад в скорость вашей страницы, и попробовать стоит.

Если у вас небольшой веб-сайт, вы можете минимизировать код с помощью онлайн-минификаторов, таких как CSS Minifier , JavaScript Minifier и HTML Compressor . Или, если ваш веб-сайт построен на платформе CMS, такой как WordPress, определенно есть плагины, которые могут сделать эту работу за вас. Если вы хотите создать собственный веб-сайт, обратитесь к этому руководству по минимизации CSS и к этому по минимизации JS .

8. Извлеките критический CSS.

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

Чтобы решить эту проблему, вы можете извлечь только те стили, которые необходимы для верхней части страницы, и добавить их в <head> вашего HTML-документа. Остальные ваши файлы CSS можно загружать асинхронно. Это значительно улучшит ваши показатели LCP и сделает ваши страницы более быстрыми для пользователей.

Ознакомьтесь с этим руководством по извлечению критического CSS для получения более подробной информации.

9. Увеличьте время отклика сервера.

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

Простым решением этих проблем, не связанным с разработкой, является переход на более качественный хостинг, что во многих случаях означает переход с общего на управляемый хостинг. Управляемый хостинг обычно поставляется с сетями CDN и другими уловками по доставке контента, которые положительно влияют на скорость страницы. Но, если вы хотите запачкать руки, вот более подробное руководство по исправлению перегруженного сервера .

10. Отложенный / асинхронный сторонний JS

Сторонние ресурсы, такие как кнопки обмена в социальных сетях и встраиваемые видеоплееры, как правило, очень сильно потребляют ресурсы. Более того, всякий раз, когда браузер встречает фрагмент JS, он приостанавливает выполнение HTML до тех пор, пока не обработает JS. Все это приводит к заметному снижению скорости страницы.

Если какие-либо из ваших сторонних ресурсов не являются необходимыми, т. Е. Они не имеют значения для внешнего вида или функции верхней части страницы, вам следует убрать их с критического пути рендеринга. Чтобы загружать сторонние ресурсы более эффективно, вы можете использовать атрибут async или defer. Атрибут async более мягкий — он позволяет загружать HTML и JS одновременно, но он все равно приостанавливает HTML для выполнения JS. Атрибут defer сложнее — он не приостанавливает HTML для выполнения JS, который будет выполнен только в самом конце.

11. Предварительно подключитесь к сторонним ресурсам.

Как правило, на установление соединений, особенно защищенных, уходит много времени. Дело в том, что для этого требуются DNS-поиск, SSL-подтверждение, обмен секретными ключами и несколько обращений к конечному серверу, который отвечает за запрос пользователя. Поэтому, чтобы сэкономить это драгоценное время, вы можете заранее подключиться к нужным источникам.

Чтобы предварительно подключить свой сайт к стороннему источнику, вам нужно только добавить тег ссылки на свою страницу:

<link rel = «preconnect» href = «https://example.com»>

После внедрения тега вашему веб-сайту не нужно будет тратить дополнительное время на установление соединения с требуемым сервером, что избавит ваших пользователей от ожидания нескольких дополнительных обходов.

12. Разделите длинные задачи.

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

Вы можете использовать Chrome DevTools для определения слишком длинных задач — они отмечены красными флажками:

Определив длинные задачи на своих страницах, вы можете разделить их на более мелкие задачи, отложить их выполнение или даже переместить их из основного потока через веб-воркер.

13. Предварительно загрузите ключевые ресурсы.

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

С помощью тега <link rel = «preload»> вы можете сообщить браузеру, что ресурс необходим как часть кода, отвечающего за рендеринг содержимого верхней части страницы, и заставить его получать ресурс, как только возможный.

Вот пример того, как можно использовать тег:

<link rel = "preload" as = "script" href = "script.js" />
<link rel = "preload" as = "style" href = "style.css" />
<link rel = "preload" as = "image" href = "img.png" />
<link rel = "preload" as = "video" href = "vid.webm" type = "video / webm" />
<link rel = "preload" href = "font.woff2" as = "font" type = "font / woff2" crossorigin />

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

14. Включите кеширование браузера.

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

Обычно цель состоит в том, чтобы кэшировать как можно больше ресурсов страницы на столько, сколько вы можете, и обеспечить повторную валидацию обновленных ресурсов для кэширования. Фактически вы можете контролировать все эти параметры с помощью специальных заголовков HTTP, которые содержат инструкции кеширования. Хорошее место для начала изучения HTTP-кеша — это руководство от Google .

15. Уменьшите размер DOM.

Слишком большое дерево DOM со сложными правилами стиля может отрицательно повлиять на такие вещи, как скорость, время выполнения и производительность памяти. Лучше всего иметь дерево DOM, которое состоит менее чем из 1500 узлов, имеет максимальную глубину 32 узла и не имеет родительского узла с более чем 60 дочерними узлами.

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

16. Избегайте слишком большого количества переадресаций.

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

Лучше всего вообще не использовать переадресацию. Однако, если вам отчаянно нужно его использовать, очень важно выбрать правильный тип перенаправления. Лучше всего использовать 301 редирект для постоянного перенаправления. Но если, скажем, вы хотите перенаправить пользователей на некоторые краткосрочные рекламные страницы или URL-адреса для конкретных устройств, временное перенаправление 302 — лучший вариант.

Последние мысли

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