Первый шаг в создании быстро загружаемого веб-сайта — это получение своевременного ответа от сервера на HTML-код страницы. Когда вы вводите URL-адрес в адресной строке браузера, браузер отправляет запрос GET на сервер для его получения. Первый запрос веб-страницы — это запрос на HTML-ресурс, и обеспечение того, чтобы HTML приходил быстро с минимальными задержками, является ключевой целью производительности.
Этот первоначальный запрос HTML проходит через несколько этапов, каждый из которых занимает некоторое время. Сокращение времени, затрачиваемого на каждый этап, дает вам более быстрое время до первого байта (TTFB) . Хотя TTFB — не единственная метрика, на которой следует сосредоточиться, когда дело касается скорости загрузки страниц, высокий TTFB действительно затрудняет достижение обозначенных «хороших» порогов для таких метрик, как Наибольшая отрисовка контента (LCP) и Первая отрисовка контента (FCP) .
Минимизировать перенаправления
При запросе ресурса сервер может ответить перенаправлением: постоянным (ответ 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 может включать несколько метрик, а также длительность для каждой из них. Затем эти данные можно собрать у пользователей в полевых условиях с помощью Navigation 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, особенно если они динамически генерируются для аутентифицированных пользователей, должны быть динамически сжаты.
Добиться правильного сжатия самостоятельно — сложная задача, и часто лучше всего позволить Content Delivery Network (CDN), которая обсуждается в следующем разделе, справиться с этим за вас. Однако знание этих концепций может помочь вам определить, правильно ли ваш хостинг-провайдер использует сжатие. Эти знания могут помочь вам найти возможности для улучшения настроек сжатия, чтобы они принесли максимальную выгоду для вашего веб-сайта.
Сети доставки контента (CDN)
Сеть доставки контента (CDN) — это распределенная сеть серверов, которые кэшируют ресурсы с вашего исходного сервера и, в свою очередь, обслуживают их с пограничных серверов, которые физически ближе к вашим пользователям. Физическая близость к вашим пользователям сокращает время приема-передачи (RTT) , в то время как такие оптимизации, как HTTP/2 или HTTP/3, кэширование и сжатие, позволяют CDN обслуживать контент быстрее, чем если бы он был извлечен с вашего исходного сервера. Использование CDN может значительно улучшить TTFB вашего веб-сайта в некоторых случаях.
Проверьте свои знания
Какой тип перенаправления находится под вашим полным контролем?
Заголовок Server-Timing может содержать несколько метрик.
Какой тип сервера, скорее всего, будет физически ближе всего к вашим конечным пользователям?
Далее: Понимание критического пути
Теперь, когда вы знакомы с некоторыми соображениями производительности, связанными с HTML вашего веб-сайта, вы находитесь в лучшем положении, чтобы гарантировать, что он может загружаться как можно быстрее, но это только начало изучения веб-производительности. Далее рассматривается теория, лежащая в основе критического пути рендеринга . В этом модуле описываются ключевые концепции, такие как ресурсы блокировки рендеринга и парсинга, а также их роль в максимально быстром первоначальном рендеринге страницы в браузере.