Блог

Как повысить скорость загрузки страниц от A до Я (ЧАСТЬ 1)

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

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

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

WordPress:

Drupal:

А теперь вернемся к делу. Вот все, что я собираюсь рассказать:
  • Что такое скорость страницы?
  • Почему вам следует заботиться о скорости страницы
  • Как быстро должна загружаться моя страница?
  • Как строится страница
  • Тестирование скорости страницы и инструменты
  • Оценка воздействия изменений

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

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

Почему вам следует заботиться о скорости страницы

Недавно Google вновь обратил внимание на скорость страницы: скорость мобильных устройств стала фактором ранжирования, отчет о скорости в Google Search Console и Chrome объявили, что они могут отмечать медленные сайты, но знаете ли вы, что скорость страницы была фактором ранжирования для Google с 2010 года ?

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

  • Влияет на пользовательский опыт. Вы хотите, чтобы у посетителей был быстрый и удобный опыт. Заметна любая задержка или запаздывание их действий.
  • Влияет на аналитику. Вообще говоря, более быстрый сайт будет регистрировать больше посетителей, потому что тег аналитики загрузится раньше. Если человек уйдет до срабатывания тега, он не будет записан в системе аналитики.
  • SEO раскрутка? Согласно официальному объявлению, обновление скорости влияет только на самые медленные сайты.

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

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

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

Как быстро должна загружаться моя страница?

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

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

Как строится страница

Чтобы понять, как повысить скорость вашей страницы, вам нужно знать, как браузер создает страницу. Для этого мы в основном будем смотреть на диаграммы, чтобы увидеть, какие ресурсы загружаются. Вы также можете увидеть это в своем браузере, щелкнув правой кнопкой мыши > Просмотреть код > и открыв вкладку «Network» при загрузке страницы.

ПРИМЕЧАНИЕ. Я собираюсь использовать https://www.webpagetest.org/ для многих изображений, и я дам ссылку на тесты и перечислю настройки, где это применимо.

Установление соединений

Зеленые, оранжевые и фиолетовые цвета ниже представляют время, необходимое для установления соединения с веб-сайтом. Я рассмотрю каждый цвет ниже и то, что он представляет.


DNS (зеленый)

Система доменных имен (DNS) считается телефонной книгой в Интернете. Вы даете своему браузеру имя веб-сайта, и он проверяет его с DNS- сервером, чтобы получить IP- адрес (метку местоположения), сообщающий ему, где размещен веб-сайт. Это похоже на сохранение контакта на телефоне, поэтому вам нужно знать только имя, а не номер телефона.

В большинстве случаев ваш DNS будет находиться у вашего регистратора домена (у которого вы купили домен) или у вашей сети доставки контента (CDN).

Важно отметить, что не все поставщики DNS одинаковы. Если для вас важна каждая миллисекунда, вы можете подумать об использовании другого поставщика DNS. Согласно DNSPerf, Cloudflare имеет среднюю скорость запроса 12,6 мс, тогда как другие, такие как GoDaddy (46,04 мс) и Rackspace (90,38 мс), в среднем медленнее. Однако эти числа не являются полностью точным представлением, поскольку DNS можно кэшировать (временно хранить) в браузере, когда вы уже посетили веб-сайт. Время, в течение которого он кэшируется, называется TTL (время жизни). Пока кеш все еще активен, браузеру не нужно подключаться к DNS- серверу, чтобы знать, куда перейти, чтобы получить доступ к веб-сайту.

Подключение (оранжевый)

Здесь браузер устанавливает соединение с хост-сервером. Протокол управления передачей / Интернет-протокол (TCP / IP) сложен, но просто подумайте о том, как вы приступите к работе. Скорее всего, это не прямая линия; вам придется делать повороты, и там будут участки с более высокой проходимостью. Вы даже можете изменить маршрут или сделать несколько неправильных поворотов. Вот как это работает; это маршрутизация из вашего браузера на сервер и обратно.

Если время на подключение велико, это может быть одной из многих проблем. При нестабильном подключении может произойти потеря пакета, и его придется отправить повторно. Это все равно, что пропустить поворот на круговом перекрестке и снова объехать. Проблема также могла быть в маршрутизации запроса по сети. Сколько прыжков нужно пройти, как далеко он должен пройти, сколько другого трафика в сети, аналогично тому, сколько поворотов вам нужно сделать, как далеко вы находитесь от работы и сколько других автомобилей на дороге, это может вас замедлить. На сервере также есть ограничение скорости и пропускная способность, что похоже на туннель, который пропускает только определенное количество автомобилей одновременно.
Многие из этих проблем решаются за счет уменьшения расстояния до сервера и использования более интеллектуальной маршрутизации, что могут сделать многие сети CDN. Имея сеть серверов по всему миру, посетители обычно могут подключиться к ближайшему. Некоторые провайдеры CDN также обрабатывают большие объемы интернет-запросов и могут в реальном времени видеть, где могут быть узкие места (трафик). Если они видят более быстрый вариант, они могут перенаправить трафик - точно так же, как GPS перенаправит вас вокруг пробки.

Secure Sockets Layer (SSL) (фиолетовый)

Для сайтов, устанавливающих безопасное соединение (HTTPS), именно здесь браузер и сервер согласовывают версию протокола TLS (Transport Layer Security), набор шифров (уровень безопасности) и проверяют сертификат.

Вы можете подумать, что можете сделать свой сайт быстрее, просто не используя HTTPS. Отчасти это правда - по крайней мере, в части подключения. Но есть и другие преимущества использования HTTPS, например, тот факт, что браузеры не позволяют использовать HTTP / 2 (H2) без HTTPS. H2 имеет некоторые преимущества, такие как постоянные соединения, поэтому ему не нужно постоянно открывать новое соединение для файлов на том же сервере. Заголовки в этих запросах также меньше, чем в HTTP /1.1, и одновременно можно передавать несколько файлов. В большинстве случаев сайты, использующие HTTPS и H2, будут быстрее, чем сайты по HTTP.

Как правило, наиболее значительные выгоды, которые вы получите здесь, связаны с обновлением вашего протокола (например, TLS 1.3 быстрее, чем TLS 1.2) и внедрением HTTP Strict Transport Security (HSTS), который сообщает браузеру всегда использовать безопасное соединение. Браузер меняет запросы с HTTP на HTTPS без необходимости связываться с сервером и выполнять перенаправление. На изображении ниже перенаправление с HTTP на HTTPS и время, которое потребовалось, будут устранены с помощью HSTS.


Возможно, вы даже захотите изучить использование HTTP / 3 для еще более быстрых соединений. Однако поддержка этого протокола все еще находится на начальной стадии и - по крайней мере, на момент написания - вероятно, еще не является жизнеспособным вариантом.

ВАЖНО: УСТРОЙСТВО, МЕСТОПОЛОЖЕНИЕ И СЕТЬ.
Учтите, что подключение к веб-сайту на смартфоне среднего класса с медленным 3G соединением занимает ~ 2 секунды. На том же телефоне с LTE подключением урезано до ~ 0,41 секунды. На настольном компьютере с нормальной скоростью это соединение составляет менее 0,1 секунды.

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

Загрузка и обработка HTML

HTML код страницы является тем, что изначально загружено браузером. Это информация, которую вы видите, когда щелкаете правой кнопкой мыши на веб-сайте и переходите к «Просмотр исходного кода страницы». После того, как соединение установлено и браузер получает первый бит информации от сервера, мы достигаем Time To First Byte (TTFB), который является типичной мерой начального времени ответа. Как показано оранжевыми линиями ниже, это время от начала HTML- запроса (светло-синий) до момента начала загрузки HTML (темно-синий).


Если есть задержка для TTFB, это может быть связано с запросами к базе данных, ресурсами сервера, ожиданием завершения рендеринга на стороне сервера (SSR) или другими вещами, обычно связанными с созданием динамического контента. Время загрузки будет зависеть от таких вещей, как соединение и размер файла.

Здесь же браузер также начинает создавать страницу. Когда HTML-код загружен, браузер анализирует его в объектной модели документа (DOM), которая позволяет компьютеру понимать структуру содержимого. Этот процесс синтаксического анализа использует основной поток браузера для обработки действий пользователя и отрисовки страницы, запуска JavaScript и выполнения макета, перекомпоновки и сборки мусора. На данный момент просто знайте, что этот основной поток существует и выполняет множество различных задач. Мы поговорим об этом чуть позже.

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

Для HTML и других типов файлов, таких как CSS и JavaScript, вы можете сократить время, используя меньше кода, минимизацию ненужных символов, таких как комментарии и пробелы и сжатие для уменьшения размера файлов. Дело в том, чтобы уменьшить размер загружаемого файла, чтобы эта часть загрузки была быстрее. Однако существует не только один способ минификации и сжатия. Во многих случаях это обрабатывается CDN или сервером (распространенными серверами являются Apache или Nginx) или плагином / модулем / пакетом. Вы можете найти больше информации о реализации сжатия здесь и минификации здесь.

Обработка дополнительных подключений

Когда HTML будет загружен, ссылки на другие файлы и другие серверы будут обработаны, и начнутся новые соединения. Обычно сюда добавляются другие файлы, такие как JavaScript, CSS, изображения и шрифты. Здесь можно сойти с ума, поскольку некоторые файлы ссылаются на другие файлы, и мы начинаем связывать соединения и загрузки файлов. Взгляните на карту запросов для Forbes.com ниже. Каждая точка - это индивидуальный запрос файла, а каждая строка - это то место, где один файл ссылается на другой файл, который должен быть загружен. Всего это 363 запроса через 128 подключений.


Источник: RequestMap

По возможности используйте тот же сервер для запросов

Раньше размещали ресурсы домена без файлов cookie, которые не совпадают с основным доменом, и иногда было выгодно использовать несколько доменов (процесс, называемый сегментированием домена) из-за ограничений на запросы подключения, установленных в браузере.

Начиная с HTTP / 2, это не лучшая практика. Если возможно, вы должны использовать тот же сервер для запросов.

Однако, хотя самостоятельное размещение многих файлов, таких как шрифты, может привести к выигрышу, могут быть и другие моменты, такие как кеширование (сохранение копии файла), когда браузеры могут иногда кэшировать общие ресурсы. Например, если я посетил один веб-сайт, который вызвал шрифт из Google Fonts, а затем перешел на другой веб-сайт, используя тот же шрифт, у меня может быть этот файл уже кэширован локально, и мне не придется загружать его снова.

Используйте Preconnect или DNS-Prefetch (если вы используете другой сервер)

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


Пример кода:

<link rel="preconnect" href="https://site.com">

Также есть DNS-prefetch, если вы просто хотите обработать эту часть соединения на раннем этапе. Зеленая (DNS) часть подключится раньше, но остальная часть подключения произойдет позже. Предварительная выборка DNS имеет лучшую поддержку, чем предварительное подключение, но если вы посмотрите на текущую статистику использования, разница будет незначительной. Предварительное подключение обычно лучше, если вы знаете, что с этого сервера что-то необходимо загрузить раньше, дабы страница работала. Однако, поскольку предварительное подключение требует больше работы для маршрутизации и безопасности (оранжевый и фиолетовый), оно также будет немного более ресурсоемким на раннем этапе.

Пример кода:

<link rel="dns-prefetch" href="//asset1.com">

Как браузеры отображают страницу

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

  1. HTML преобразуется в дерево DOM, о котором мы упоминали ранее.
  2. CSS анализируется в объектной модели CSS (CSSOM), которая сообщает браузеру, как все оформлено, дополнено, раскрашено, размер и т. д.
  3. CSSOM + DOM вместе делают то, что называется Рендер Tree.


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


5. На экране закрашиваются пиксели, поэтому вместо белого экрана вы видите цвета, формы, текст и изображения.

ПРИМЕЧАНИЕ. Интересный факт, обнаруженный Мартином Сплиттом из Google, заключается в том, что робот Google экономит время и ресурсы, фактически не раскрашивая пиксели страницы. У них есть необходимая информация после верстки.
Цель должна состоять в том, чтобы получить необходимые элементы как можно раньше, чтобы построить начальное представление как можно быстрее. Видимое время загрузки - это восприятие людьми скорости страницы, т. е. того, как скоро контент появится на экране для них. Больше всего на это влияет то, как загружаются ресурсы. Обычно CMS или JavaScript Framework отвечают за то, чтобы помочь браузеру расставить приоритеты, когда / какие / как загружать ресурсы в каком порядке, чтобы сайт отображался быстрее. Подробнее об этом чуть позже.

Вы также хотите сохранить простоту и избежать сложных вычислений и множества изменений на этапе макета. 

Визуальные показатели нагрузки:

  • First Paint (FP) - браузер отображает что-либо впервые.
  • First Contentful Paint (FCP) - браузер отображает что-то из DOM (объектной модели документа), что может быть текстом, изображением и т. д.
  • First Meaningful Paint (FMP) - наиболее важные элементы, загруженные визуально.
  • Largest Contentful Paint (LCP) - самый большой загруженный элемент над сгибом.
  • Visually Complete - страница загружается визуально.
  • Speed Index - рассчитываемая оценка визуальной нагрузки, учитывающая несколько моментов времени.
  • Cumulative Layout Shift (CLS) - измеряет, сколько элементов перемещается в области просмотра во время загрузки или насколько стабильный макет. Хороший путеводитель по причинам CLS здесь.

Увидеть визуальную нагрузку вместе с диаграммой

В разделе «Summary» в WebPageTest, если вы включили запись, у вас должен быть столбец «Video» в основной таблице с надписью «Filmstrip View». На этом виде красная линия вверху с визуальными снимками находится в той же точке, что и красная линия внизу.


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

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

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


Тип файла CSS

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

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

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

Асинхронная загрузка CSS

Нужно загрузить важный код как можно скорее, и мы поговорим о нескольких вариантах для этого через секунду, но другая часть этого - вы хотите, чтобы CSS не блокировал рендеринг. Для этого надо загрузить таблицы стилей, которые понадобятся позже в процессе загрузки, как другой тип носителя, который затем будет применен ко всем типам. Он обманывает браузер, злоупотребляя тем, как он обрабатывает загрузку определенных атрибутов элемента ссылки. Что он собирается сделать, так это загрузить CSS без блокировки отрисовки (потому что в этом случае мы сообщаем браузеру, что эта таблица стилей предназначена для печати, а не для этой версии страницы), а затем применима ко всем типам мультимедиа после загрузки.

Например, это:

<link rel="stylesheet" href="/my.css">

Становится это:

<link rel="stylesheet" href="/my.css" media="print" onload="this.media='all'">

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

Inline

Inline принимает код, необходимый для отображения содержимого в верхней части страницы, и доставляет его с ответом HTML вместо отдельного файла. Обычно это самый быстрый способ сократить время, необходимое для визуализации исходного вида.
Самый простой способ подумать об этом - взять важные части файлов CSS и JS и поместить их прямо в HTML. Первоначальный HTML занимает немного больше времени для загрузки и анализа, но теперь рендеринг страницы может происходить до того, как все остальные файлы будут загружены.


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

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

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

Встроенный критический CSS в масштабе:

Вам понадобится автоматизированная система, а не делать это для каждой страницы. Возможно, имеет смысл встроить только CSS для домашней страницы в темы WordPress, поскольку у них обычно другая таблица стилей, чем на других страницах. Обычно это какой-то плагин / модуль / пакет или версия Critical или Critical CSS. Эти пакеты существуют для любого диспетчера задач или пакетов, которые вы можете использовать, например Grunt, Gulp, Webpack или Framework, например React, Angular, Vue, и вы даже можете найти учебные пособия, специфичные для WordPress или Drupal, или даже страницы, написанные вручную. Они собираются отправить на страницу безголовый браузер, чтобы определить, какой CSS на самом деле критичен для загрузки страницы в разных размерах, и либо выдает вам код, либо разбивает код на критические и некритические элементы, чтобы вы могли загрузить их соответствующим образом.

Несколько примеров:

Grunt:
https://github.com/filamentgroup/grunt-criticalcss
https://www.npmjs.com/package/grunt-critical-css
https://github.com/bezoerb/grunt-critical

Gulp:
https://github.com/addyosmani/critical
https://www.npmjs.com/package/gulp-critical-css

Webpack:
https://github.com/anthonygore/html-critical-webpack-plugin
https://github.com/GoogleChromeLabs/critters
https://github.com/anthonygore/html-critical-webpack-plugin
https: / /www.npmjs.com/package/critical-css-webpack-plugin

React:
https://www.npmjs.com/package/react-critical-css 
https://github.com/addyosmani/critical-path-css-tools 
https://github.com/sergei-zelinsky/react- критический-css 

Angular:
https://github.com/addyosmani/critical-path-angular-demo 

Vue:
https://github.com/anthonygore/vue-cli-plugin-critical 
https://vuejsdevelopers.com/2017/07/24/critical-css-webpack/ 

Drupal:
https://www.fourkitchens.com/blog/article/use-gulp-automate-your-critical-path-css/ 

WordPress:
https://joe-watkins.io/javascript/inline-critical-css-with-wordpress/ 
https://wordpress.org/plugins/wp-criticalcss/

Hand-coded:
https://www.sitelocity.com/critical-path-css-generator 
https://jonassebastianohlsson.com/criticalpathcssgenerator/ 


ПРОДОЛЖЕНИЕ СТАТЬИ  - Как повысить скорость загрузки страниц от A до Я (ЧАСТЬ 2)
Made on
Tilda