Первым шагом в создании быстро загружающегося веб-сайта является получение своевременного ответа от сервера на HTML-код страницы. Когда вы вводите URL-адрес в адресную строку браузера, браузер отправляет запрос GET на сервер для его получения. Первый запрос веб-страницы предназначен для ресурса HTML, и обеспечение быстрой доставки HTML с минимальными задержками является ключевой целью производительности.
Этот первоначальный запрос HTML проходит несколько этапов, каждый из которых занимает некоторое время. Сокращение времени, затрачиваемого на каждый шаг, позволяет сократить время до первого байта (TTFB) . Хотя TTFB не является единственным показателем, на котором следует сосредоточиться, когда речь идет о скорости загрузки страниц, высокий TTFB усложняет достижение назначенных «хороших» порогов для таких показателей, как « Наибольшая отрисовка контента» (LCP) и «Первая отрисовка контента» ( ФКП) .
Минимизировать перенаправления
Когда запрашивается ресурс, сервер может ответить перенаправлением либо постоянным (ответ 301 Moved Permanently ), либо временным (ответ 302 Found ).
Перенаправления замедляют скорость загрузки страницы, поскольку требуют от браузера выполнения дополнительного HTTP-запроса в новом месте для получения ресурса. Существует два типа перенаправлений:
- Перенаправления того же происхождения , которые происходят полностью внутри вашего источника. Эти типы перенаправлений полностью находятся под вашим контролем, поскольку логика управления ими полностью находится на вашем веб-сервере.
- Перенаправления между источниками , инициированные другим источником. Эти типы перенаправлений обычно находятся вне вашего контроля.
Перенаправления между источниками часто используются рекламой, службами сокращения URL-адресов и другими сторонними службами. Хотя перенаправления между источниками находятся вне вашего контроля, вы все равно можете убедиться, что вы избегаете нескольких перенаправлений — например, наличия объявления, которое ссылается на страницу HTTP, которая, в свою очередь, перенаправляет на ее эквивалент HTTPS, или перенаправления из перекрестного источника. который поступает в ваш источник, но затем запускает перенаправление того же источника.
Кэшировать HTML-ответы
Кэшировать ответы HTML сложно, поскольку ответ может включать ссылки на другие важные ресурсы, такие как CSS, JavaScript, изображения и другие типы ресурсов. Эти ресурсы могут включать в соответствующие имена файлов уникальные отпечатки пальцев , которые меняются в зависимости от содержимого файла. Это означает, что ваш кэшированный HTML-документ может устареть после развертывания, поскольку он будет содержать ссылки на устаревшие подресурсы.
Тем не менее, короткое время жизни кэша (а не отсутствие кэширования) может иметь преимущества, например, позволяя кэшировать ресурс в CDN (уменьшая количество запросов, обслуживаемых с исходного сервера), а также в браузере, позволяя повторно проверять ресурсы. вместо того, чтобы загружать снова. Этот подход лучше всего работает для статического контента, который не меняется ни в каком контексте, а подходящее время для кэширования ресурсов можно установить на определенное количество минут, которое вы считаете подходящим. Пять минут для статических HTML-ресурсов — это беспроигрышный вариант, который гарантирует, что периодические обновления не останутся незамеченными.
Если HTML-содержимое страницы каким-либо образом персонализировано (например, для аутентифицированного пользователя), вы, скорее всего, вообще не захотите кэшировать контент по ряду причин, включая безопасность и актуальность. Если ответ HTML кэшируется браузером пользователя, вы не можете сделать кеш недействительным. Поэтому в таких случаях лучше вообще избегать кэширования HTML.
Осторожным подходом к кэшированию HTML может быть использование заголовков ответа ETag или Last-Modified . Заголовок ETag , также известный как тег объекта, представляет собой идентификатор, который уникальным образом представляет запрошенный ресурс, часто с использованием хеша содержимого ресурса :
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
При каждом изменении ресурса необходимо генерировать новое значение ETag . При последующих запросах браузер отправляет значение ETag через заголовок запроса If-None-Match . Если ETag на сервере совпадает с отправленным браузером, сервер отвечает ответом 304 Not Modified , и браузер использует ресурс из кеша. Хотя это по-прежнему вызывает задержку в сети, ответ 304 Not Modified намного меньше, чем весь HTML-ресурс.
Однако задержка в сети, связанная с повторной проверкой актуальности ресурса, по-прежнему является своего рода недостатком. Как и во многих других аспектах веб-разработки, компромиссы и компромиссы неизбежны. Вам решать, стоит ли дополнительных усилий по кэшированию HTML таким способом, или лучше перестраховаться и вообще не беспокоиться о кэшировании HTML-контента.
Измерьте время ответа сервера
Если ответ не кэшируется, время ответа сервера сильно зависит от вашего хостинг-провайдера и стека серверных приложений. Веб-страница, которая обслуживает динамически генерируемый ответ, такой как, например, получение данных из базы данных, вполне может иметь более высокий TTFB, чем статическая веб-страница, которую можно обслуживать немедленно, без значительного времени вычислений на серверной стороне. Отображение счетчика загрузки и последующее получение всех данных на стороне клиента перемещает усилия из более предсказуемой среды на стороне сервера в потенциально непредсказуемую среду на стороне клиента. Минимизация усилий на стороне клиента обычно приводит к улучшению показателей, ориентированных на пользователя.
Если у пользователей наблюдается медленный TTFB в полевых условиях , вы можете предоставить информацию о том, сколько времени было потрачено на сервере, с помощью заголовка ответа Server-Timing :
Server-Timing: auth;dur=55.5, db;dur=220
Значение заголовка Server-Timing может включать в себя несколько метрик, а также длительность каждой из них. Затем эти данные можно собрать у пользователей на местах с помощью API синхронизации навигации и проанализировать, чтобы определить, испытывают ли пользователи задержки. В предыдущем фрагменте кода заголовок ответа включает два тайминга:
- Время аутентификации пользователя (
auth), которое заняло 55,5 миллисекунд. - Время доступа к базе данных (
db), которое заняло 220 миллисекунд.
Вы также можете проверить свою хостинговую инфраструктуру и убедиться, что у вас достаточно ресурсов для обработки трафика, который получает ваш сайт. Поставщики виртуального хостинга часто подвержены высокому значению TTFB, а выделенные решения, обеспечивающие более быстрое время отклика, могут быть более дорогостоящими.
Сжатие
Текстовые ответы, такие как изображения HTML, JavaScript, CSS и SVG, следует сжимать, чтобы уменьшить размер их передачи по сети и ускорить их загрузку. Наиболее широко используемые алгоритмы сжатия — gzip и Brotli. Brotli дает преимущество примерно на 15–20% по сравнению с gzip.
Сжатие часто устанавливается автоматически большинством провайдеров веб-хостинга, но есть несколько важных вещей, которые следует учитывать, если вы можете настроить или настроить параметры сжатия самостоятельно:
- Используйте Brotli, где это возможно. Как говорилось ранее, Brotli обеспечивает довольно заметное улучшение по сравнению с gzip, и Brotli поддерживается во всех основных браузерах . Используйте Brotli, когда это возможно, но если ваш веб-сайт используется большим количеством пользователей в устаревших браузерах, убедитесь, что gzip используется в качестве запасного варианта, поскольку любое сжатие лучше, чем отсутствие сжатия вообще.
- Размер файла имеет значение. Очень маленькие ресурсы — менее 1 КиБ — сжимаются не очень хорошо, а иногда даже не сжимаются вообще. Эффективность любого типа сжатия данных зависит от наличия большого объема данных, с которыми может работать алгоритм сжатия, чтобы найти более сжимаемые биты данных. Чем больше файл, тем лучше работает сжатие, однако не пересылайте очень большие ресурсы только потому, что их можно сжать более эффективно. Большие ресурсы, такие как, например, JavaScript и CSS, требуют значительно больше времени для анализа и оценки после того, как браузер распаковал их, и могут изменяться чаще, даже если они изменились лишь незначительно, поскольку любые изменения приводят к другому хешу файла .
- Понимание динамического и статического сжатия. Динамическое и статическое сжатие — это разные подходы к тому, когда ресурс следует сжимать. Динамическое сжатие сжимает ресурс в момент его запроса , а иногда и каждый раз, когда он запрашивается. С другой стороны, статическое сжатие сжимает файлы заранее , не требуя выполнения сжатия во время запроса. Статическое сжатие устраняет задержку, связанную с самим сжатием, что может увеличить время ответа сервера в случае динамического сжатия. Статические ресурсы, такие как изображения JavaScript, CSS и SVG, должны быть статически сжаты, тогда как ресурсы HTML, особенно если они динамически генерируются для аутентифицированных пользователей, должны быть сжаты динамически.
Самостоятельно обеспечить правильное сжатие сложно, и часто лучше позволить сети доставки контента (CDN), которая обсуждается в следующем разделе, сделать это за вас. Однако знание этих концепций может помочь вам понять, правильно ли ваш хостинг-провайдер использует сжатие. Эти знания могут помочь вам найти возможности улучшить настройки сжатия, чтобы они принесли максимальную пользу вашему веб-сайту.
Сети доставки контента (CDN)
Сеть доставки контента (CDN) — это распределенная сеть серверов, которые кэшируют ресурсы вашего исходного сервера и, в свою очередь, обслуживают их с пограничных серверов, которые физически находятся ближе к вашим пользователям. Физическая близость к вашим пользователям сокращает время прохождения туда и обратно (RTT) , а такие оптимизации, как HTTP/2 или HTTP/3, кэширование и сжатие, позволяют CDN обслуживать контент быстрее, чем если бы он был получен с вашего исходного сервера. Использование CDN в некоторых случаях может значительно улучшить TTFB вашего сайта.
Проверьте свои знания
Какой тип перенаправления полностью находится под вашим контролем?
Заголовок Server-Timing может содержать несколько метрик.
Какой тип сервера, скорее всего, будет физически ближе всего к вашим конечным пользователям?
Далее: понимание критического пути
Теперь, когда вы знакомы с некоторыми аспектами производительности, связанными с HTML вашего веб-сайта, у вас есть больше возможностей обеспечить его загрузку как можно быстрее, но это только начало изучения веб-производительности. Далее рассматривается теория критического пути рендеринга . В этом модуле описываются ключевые понятия, такие как ресурсы блокировки рендеринга и синтаксического анализа, а также роль, которую они играют в максимально быстром первоначальном рендеринге страницы в браузере.