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

pagespeed SEO
Скорость страницы уже давно является фактором ранжирования Google. Начиная с первого объявления еще в 2010 году, затем подкрепив его еще одним обновлением в 2018 году, а затем заключив сделку, представив Core Web Vitals в 2020 году. В этой статье мы рассмотрим, что такое скорость страницы сегодня, как ее измерить, что наиболее важно, как улучшить показатели скорости страницы для вашего веб-сайта.
Содержание
  1. Что такое скорость страницы?
  2. Largest Contentful Paint (LSP)
  3. First Input Delay (FID) — задержка первого входа
  4. Cumulative Lay0ut Shift (CSL) — кумулятивный сдвиг макета
  5. Как измерить скорость страницы на вашем сайте?
  6. Как повысить скорость загрузки страниц на вашем сайте?
  7. 1. Установите размеры изображения.
  8. 2. Размещайте изображения в форматах следующего поколения.
  9. 3. Сжимайте изображения.
  10. 4. Отложите закадровые изображения
  11. 5. Конвертируйте гифки в видео.
  12. 6. Отложите неиспользуемый CSS
  13. 7. Минимизируйте JS и CSS.
  14. 8. Извлеките критический CSS.
  15. 9. Увеличьте время отклика сервера.
  16. 10. Отложенный / асинхронный сторонний JS
  17. 11. Предварительно подключитесь к сторонним ресурсам.
  18. 12. Разделите длинные задачи.
  19. 13. Предварительно загрузите ключевые ресурсы.
  20. 14. Включите кеширование браузера.
  21. 15. Уменьшите размер DOM.
  22. 16. Избегайте слишком большого количества переадресаций.
  23. Последние мысли

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

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

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

Largest Contentful Paint (LSP)

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

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

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

FID можно оптимизировать за счет разделения кода и использования меньшего количества JavaScript.

Cumulative Lay0ut Shift (CSL) — кумулятивный сдвиг макета

Кумулятивное смещение макета определяет, перемещаются ли элементы на странице при загрузке. Скажем, страница выглядит так, как будто она готова к использованию, но затем вверху появляется новое изображение, а остальное содержимое сдвигается вниз — это сдвиг макета. Контрольные показатели для этого показателя следующие:
Тесты CLS
CLS зависит от правильно установленных атрибутов размера и от загрузки ресурсов в указанной последовательности, сверху вниз.

Как измерить скорость страницы на вашем сайте?

Google предоставляет множество инструментов, которые предлагают Core Web Vitals как часть аудита своей страницы:
Инструменты Google для измерения Core Web Vitals

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

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

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

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

Основные проблемы Web Vitals в Google Search Console

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

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

Отчет Core Web Vitals в WebSite Auditor

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

Отчет Core Web Vitals в WebSite Auditor

В целом, я считаю, что WebSite Auditor более удобен для выполнения фактической работы по оптимизации ваших страниц, в то время как Google Search Console является скорее инструментом отчетности.

Как повысить скорость загрузки страниц на вашем сайте?

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

1. Установите размеры изображения.

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

Чтобы избежать этой проблемы, всегда устанавливайте для изображений свойства ширины и высоты, например:

<img src = «pllow.jpg» width = «640» height = «360» alt = «фиолетовая подушка с цветочным узором» />

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

2. Размещайте изображения в форматах следующего поколения.

Не все форматы изображений одинаковы. Наши надежные форматы JPEG и PNG теперь имеют гораздо худшие характеристики сжатия и качества по сравнению с AVIF, JPEG 2000, JPEG XR и WebP.

Из перечисленных форматов WebP, вероятно, стоит рассмотреть в первую очередь. Он поддерживает сжатие как с потерями, так и без потерь, а также обеспечивает прозрачность и анимацию. Кроме того, файлы WebP обычно на 25–35% легче, чем файлы PNG и JPEG аналогичного качества . И хотя в прошлом распространенной проблемой было то, что формат WebP не поддерживается некоторыми браузерами, недавно Safari добавила поддержку WebP в версии 14, так что общая поддержка формата среди браузеров сейчас превышает 90%.

Если ваш веб-сайт построен на WordPress, вы можете легко создать WebP-копию своих изображений с помощью плагина оптимизации изображений, такого как Imagify . Если ваш веб-сайт не построен на платформе CMS или вы не хотите устанавливать слишком много плагинов, вы можете конвертировать свои изображения с помощью онлайн-конвертеров или графических редакторов.

3. Сжимайте изображения.

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

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

Результаты сжатия изображения от TinyPNG

Используя онлайн-компрессор, я сэкономил от 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 для определения слишком длинных задач — они отмечены красными флажками:

Долгие задачи в 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 — лучший вариант.

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

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

Источник
Алексей

Веб-дизайнер и SEO оптимизатор. Занимаюсь созданием сайтов с 2010 года и их продвижение с 2012 года!

Оцените автора
( Пока оценок нет )
Создание, поисковая оптимизация, продвижение и монетизация сайтов. Инструменты для веб-разработчиков, CMS сборки.
Добавить комментарий