Помимо устранения ненужных загрузок ресурсов, лучшее, что вы можете сделать для повышения скорости загрузки страницы, — это минимизировать общий размер загрузки путем оптимизации и сжатия оставшихся ресурсов.
Сжатие данных 101
После того, как вы настроили свой веб-сайт так, чтобы избежать загрузки неиспользуемых ресурсов, следующим шагом будет сжатие всех оставшихся подходящих ресурсов, которые браузер должен загрузить. В зависимости от типа ресурса — текста, изображений, шрифтов и т. д. — на выбор предлагается множество различных методов: общие инструменты, которые можно включить на веб-сервере, оптимизация предварительной обработки для конкретных типов контента и оптимизация для конкретных ресурсов. которые требуют участия разработчика.
Для достижения наилучшей производительности необходимо сочетание всех следующих методов:
- Сжатие — это процесс кодирования информации с использованием меньшего количества битов.
- Удаление ненужных данных всегда дает наилучшие результаты.
- Существует множество различных методов и алгоритмов сжатия.
- Вам понадобятся различные методы для достижения наилучшего сжатия.
Процесс уменьшения размера данных — это сжатие данных . Многие люди внесли свой вклад в алгоритмы, методы и оптимизации для улучшения степени сжатия, скорости сжатия и объема памяти, необходимой для различных алгоритмов сжатия.
Полное обсуждение сжатия данных выходит далеко за рамки данного руководства. Однако важно понимать — на высоком уровне — как работает сжатие и методы, которые вы можете использовать для уменьшения размера различных ресурсов, которые требуются вашим страницам.
Чтобы проиллюстрировать основные принципы этих методов, рассмотрим процесс оптимизации простого формата текстового сообщения, который был изобретен специально для этого примера:
# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA
- Сообщения могут содержать произвольные аннотации, иногда называемые комментариями , которые обозначаются префиксом «#». Аннотации не влияют на смысл сообщения или его поведение.
- Сообщения могут содержать заголовки , представляющие собой пары «ключ-значение» (в предыдущем примере разделенные знаком
":"), которые появляются в начале сообщения. - Сообщения содержат текстовую информацию.
Что можно сделать, чтобы уменьшить размер предыдущего сообщения, которое начинается с 200 символов?
- Комментарий интересный, но на смысл сообщения не влияет. Устраните его при передаче сообщения.
- Существуют хорошие методы эффективного кодирования заголовков. Например, если вы знаете, что все сообщения имеют «формат» и «дату», вы можете преобразовать их в короткие целочисленные идентификаторы и просто отправить их. Однако это может быть неправдой, поэтому лучше пока оставить это в покое.
- Полезная нагрузка представляет собой только текст. Хотя мы не знаем, каково его содержание на самом деле (очевидно, он использует
"secret-cipher"), простой взгляд на текст показывает, что в нем много избыточности. Возможно, вместо того, чтобы отправлять повторяющиеся письма, вы можете просто подсчитать количество повторяющихся писем и более эффективно их закодировать. Например,"AAA"становится"3A", что представляет собой последовательность из трех букв «А».
Сочетание этих методов дает следующий результат:
format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A
Новое сообщение имеет длину 56 символов. Это означает, что исходное сообщение сжато на 72%. Это значительное снижение!
Это игрушечный пример того, как алгоритмы сжатия могут быть эффективными для уменьшения размера передаваемых текстовых ресурсов. На практике алгоритмы сжатия гораздо более сложны, чем показано в предыдущем примере, и в Интернете алгоритмы сжатия можно использовать для значительного сокращения времени загрузки ресурсов. Применяя сжатие к текстовым ресурсам, веб-страница может тратить меньше времени на загрузку ресурсов, поэтому пользователи смогут увидеть эффект от этих ресурсов раньше, чем без сжатия.
Минификация: предварительная обработка и контекстно-зависимая оптимизация.
Первый метод, обсуждаемый здесь, — минификация . Хотя минификация не является строго алгоритмом сжатия, это способ удаления ненужных и избыточных символов, используемых в исходном коде, чтобы сделать ресурсы более читабельными для людей. Однако эта читаемость не обязательна для поддержания функциональности этого исходного кода на рабочих веб-сайтах и может задержать загрузку ресурсов в Интернете.
Минимизация — это тип оптимизации контента, который может значительно уменьшить размер доставляемых ресурсов. Эту оптимизацию лучше всего применять как часть процесса сборки и развертывания. Например, упаковщики — это широко используемый тип программного обеспечения, которое может автоматически минимизировать ресурсы непосредственно перед развертыванием нового производственного кода на веб-сайте.
Лучший способ сжать избыточные или ненужные данные — удалить их. Однако вы не можете просто удалить произвольные данные. Тем не менее, в некоторых контекстах, когда у нас есть специфичные для контента знания о формате данных и его свойствах, можно значительно уменьшить размер полезной нагрузки, не затрагивая ее фактическое значение или возможности.
<html>
<head>
<style>
/* awesome-container is only used on the landing page */
.awesome-container {
font-size: 120%;
}
.awesome-container {
width: 50%;
}
</style>
</head>
<body>
<!-- awesome container content: START -->
<div>
This is my awesome container, and it is <em>so</em> awesome.
</div>
<!-- awesome container content: END -->
<script>
awesomeAnalytics(); // Beacon conversion metrics
</script>
</body>
</html>
Рассмотрим предыдущий фрагмент HTML и три различных типа контента, которые он содержит:
- HTML-разметка.
- CSS для настройки представления страницы.
- JavaScript для обеспечения взаимодействия и других расширенных возможностей страницы.
Каждый из этих типов контента имеет разные правила определения допустимого контента, разные правила указания комментариев и т. д. Однако остается вопрос: «Как можно уменьшить размер этой страницы?»
- Комментарии к коду — лучшие друзья разработчика, но браузеру они не нужны! Удаление комментариев CSS (
/* ... */), HTML (<!-- ... -->) и JavaScript (// ...) уменьшает общий размер передаваемой страницы и ее подресурсов. - «Умный» компрессор CSS может заметить, что мы используем неэффективный способ определения правил для
.awesome-container, и свернуть два объявления в одно, не затрагивая другие стили, экономя больше байтов. В большом наборе правил CSS удаление такого рода избыточности может привести к определенным последствиям, но его нельзя применять агрессивно, поскольку селекторы часто обязательно дублируются в разных контекстах, например, в медиа-запросах. - Пробелы и табуляции — это удобство для разработчиков в HTML, CSS и JavaScript. Дополнительный компрессор может удалить все табуляции и пробелы. В отличие от других методов дедупликации, этот вид оптимизации может применяться довольно агрессивно, если такие пробелы или табуляции не нужны для представления страницы — например, вы хотите сохранить пробелы внутри фрагментов текста в HTML-документе. , поскольку они обеспечивают читаемость контента, который пользователи действительно увидят.
<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>
После применения предыдущих шагов длина страницы увеличилась с 516 до 204 символов, что означает экономию примерно 60%. Конечно, это не очень читаемо, но это не обязательно, чтобы его можно было использовать. Современные методы разработки также позволяют хранить хорошо отформатированные и читаемые версии исходного кода отдельно от хорошо оптимизированного кода, который вы отправляете в производство. В сочетании с исходными картами , которые обеспечивают читаемое представление преобразованного производственного кода и позволяют легче устранять ошибки в рабочей среде, вы можете получить как хороший опыт разработчика, так и оптимизацию производительности ради удобства пользователей.
Предыдущий пример иллюстрирует важный момент: компрессор общего назначения, скажем, предназначенный для сжатия произвольного текста, может довольно хорошо сжать страницу в предыдущем примере, но он никогда не узнает, нужно ли удалить комментарии, свернуть CSS. правила или десятки других оптимизаций, специфичных для контента. Вот почему так важны предварительная обработка, минификация и другие контекстно-зависимые оптимизации.
Аналогичным образом, описанные выше методы могут быть расширены за пределы текстовых ресурсов. Изображения, видео и другие типы контента содержат свои собственные формы метаданных и различные полезные данные. Например, всякий раз, когда вы делаете снимок с помощью камеры, его файл обычно включает много дополнительной информации: настройки камеры, местоположение и т. д. В зависимости от вашего приложения эти данные могут быть критически важными (например, сайт для обмена фотографиями) или могут быть совершенно бесполезными. Вам следует подумать, стоит ли его удалять. На практике эти метаданные могут составлять до десятков килобайт для каждого изображения.
Короче говоря, в качестве первого шага в оптимизации эффективности ваших ресурсов составьте список различных типов контента и подумайте, какие виды оптимизации контента вы можете применить, чтобы уменьшить их размер. Затем — после того, как вы выяснили, что это такое, автоматизируйте эти оптимизации, добавив их в этапы сборки и выпуска, чтобы гарантировать, что оптимизации применяются последовательно для каждого нового выпуска в рабочей версии.
Сжатие текста с помощью алгоритмов сжатия
Следующим шагом к уменьшению размера текстовых ресурсов является применение к ним алгоритма сжатия. Это шаг вперед: агрессивный поиск повторяющихся шаблонов в текстовых данных перед отправкой их пользователю и их распаковка, как только они попадают в браузер пользователя. Результатом является дальнейшее и значительное сокращение этих ресурсов и, как следствие, более быстрое время загрузки.
- gzip и Brotli — это широко используемые алгоритмы сжатия, которые лучше всего работают с текстовыми ресурсами: CSS, JavaScript, HTML.
- Все современные браузеры поддерживают сжатие gzip и Brotli и будут рекламировать поддержку обоих в заголовке HTTP-запроса
Accept-Encoding. - Ваш сервер должен быть настроен для включения сжатия. Программное обеспечение веб-сервера часто позволяет модулям сжимать текстовые ресурсы по умолчанию.
- И gzip, и Brotli можно настроить для улучшения степени сжатия, регулируя уровень сжатия. Для gzip настройки сжатия варьируются от 1 до 9, причем 9 является лучшим. Для Бротли этот диапазон составляет от 0 до 11, причем 11 является лучшим. Однако более высокие настройки сжатия требуют больше времени. Для ресурсов, которые сжимаются динамически , то есть во время запроса, настройки в середине диапазона, как правило, предлагают лучший компромисс между степенью сжатия и скоростью. Однако возможно статическое сжатие , то есть когда ответ сжимается заранее, и поэтому можно использовать наиболее агрессивные настройки сжатия, доступные для каждого алгоритма сжатия.
- Сети доставки контента (CDN) обычно предлагают автоматическое сжатие соответствующих ресурсов. CDN также могут управлять динамическим и статическим сжатием, что дает вам на один аспект сжатия меньше, о чем нужно беспокоиться.
gzip и Brotli — распространенные компрессоры, которые можно применять к любому потоку байтов. Под капотом они запоминают часть ранее проверенного содержимого файла и впоследствии пытаются найти и эффективно заменить повторяющиеся фрагменты данных.
На практике и gzip, и Brotli лучше всего работают с текстовым контентом, часто достигая степени сжатия до 70-90% для больших файлов. Однако использование ресурсов этих алгоритмов, которые уже сжаты с использованием альтернативных алгоритмов, таких как большинство форматов изображений, в которых используются методы сжатия без потерь или с потерями, практически не дает улучшения.
Все современные браузеры объявляют о поддержке gzip и Brotli в заголовке HTTP-запроса Accept-Encoding . Однако хостинг-провайдер несет ответственность за то, чтобы веб-сервер был правильно настроен для обслуживания сжатого ресурса, когда клиент его запрашивает.
| Файл | Алгоритм | Несжатый размер | Сжатый размер | Коэффициент сжатия |
|---|---|---|---|---|
| угловой-1.8.3.js | Бротли | 1346 КиБ | 256 КиБ | 81% |
| угловой-1.8.3.js | gzip | 1346 КиБ | 329 КиБ | 76% |
| угловой-1.8.3.min.js | Бротли | 173 КиБ | 53 КиБ | 69% |
| угловой-1.8.3.min.js | gzip | 173 КиБ | 60 КиБ | 65% |
| jquery-3.7.1.js | Бротли | 302 КиБ | 69 КиБ | 77% |
| jquery-3.7.1.js | gzip | 302 КиБ | 83 КиБ | 73% |
| jquery-3.7.1.min.js | Бротли | 85 КиБ | 27 КиБ | 68% |
| jquery-3.7.1.min.js | gzip | 85 КиБ | 30 КиБ | 65% |
| лодаш-4.17.21.js | Бротли | 531 КиБ | 73 КиБ | 86% |
| лодаш-4.17.21.js | gzip | 531 КиБ | 94 КиБ | 82% |
| lodash-4.17.21.min.js | Бротли | 71 КиБ | 23 КиБ | 68% |
| lodash-4.17.21.min.js | gzip | 71 КиБ | 25 КиБ | 65% |
В предыдущей таблице показана экономия, которую могут обеспечить сжатие Brotli и gzip для нескольких известных библиотек JavaScript. Экономия варьируется от 65% до 86% в зависимости от файла и алгоритма. Для справки: к каждому файлу был применен максимальный уровень сжатия как для Brotli, так и для gzip. По возможности отдавайте предпочтение Brotli, а не gzip.
Включение сжатия — одна из самых простых и эффективных оптимизаций. Если ваш веб-сайт не использует эту возможность, вы упускаете большую возможность повысить производительность своих пользователей. К счастью, многие веб-серверы предоставляют конфигурации по умолчанию, которые позволяют эту важную оптимизацию, и, в частности, CDN очень эффективно реализуют ее таким образом, чтобы сбалансировать скорость и коэффициент сжатия.
Быстрый способ увидеть сжатие в действии — открыть Chrome DevTools, открыть панель «Сеть» , загрузить страницу по вашему выбору и наблюдать за самой нижней частью панели сети.
Как и на предыдущем изображении, вы должны увидеть разбивку:
- Количество запросов, то есть количество ресурсов, загруженных на страницу.
- Размер передачи всех запросов. Это отражает эффективность сжатия, применяемого к любому из ресурсов страницы.
- Размер ресурса всех запросов. Это отражает размер ресурсов страницы после их распаковки.
Влияние на основные веб-показатели
Улучшение производительности невозможно измерить, если нет показателей, отражающих эти улучшения. Инициатива Core Web Vitals существует для создания и повышения осведомленности о показателях, отражающих фактический опыт пользователей. Это контрастирует с такими показателями, как, например, простое время загрузки страницы, которые не отражаются однозначно на качестве взаимодействия с пользователем.
Когда вы применяете оптимизацию, описанную в этом руководстве, к ресурсам вашего веб-сайта, влияние на основные веб-показатели может различаться в зависимости от оптимизированных ресурсов и задействованных показателей. Однако вот несколько случаев, когда применение этих оптимизаций может улучшить основные веб-показатели вашего веб-сайта:
- Минимизированные и сжатые HTML-ресурсы могут улучшить загрузку этого HTML, возможность обнаружения его подресурсов и, следовательно, улучшить их загрузку. Это может быть полезно для самого большого содержимого страницы (LCP) . Хотя подсказки ресурсов, такие как
rel="preload"могут использоваться для влияния на возможность обнаружения ресурсов, использование слишком большого их количества может вызвать проблемы с конфликтом за полосу пропускания. Обеспечивая сжатие HTML-ответа на запрос навигации, содержащиеся в них ресурсы могут быть обнаружены сканером предварительной загрузки как можно скорее. - Некоторые кандидаты LCP также можно загрузить раньше, используя сжатие. Например, для изображений SVG, которые являются кандидатами на LCP , время загрузки ресурсов может быть уменьшено за счет сжатия текста. Это отличается от оптимизации, которую вы выполняете для других типов изображений, которые по своей природе сжимаются с помощью других методов сжатия, например, как изображения JPEG используют сжатие с потерями.
- Кроме того, текстовые узлы также могут быть кандидатами на LCP. Применение методов, описанных в этом руководстве, зависит от того, используете ли вы веб-шрифт для текста на своих веб-страницах. Если вы используете веб-шрифт, применимы рекомендации по оптимизации веб-шрифтов . Однако если вы используете не веб-шрифты, а системные шрифты, которые отображаются без затрат времени на загрузку ресурсов, минимизация и сжатие вашего CSS сокращает время его загрузки, а это означает, что рендеринг потенциальных текстовых узлов LCP может произойти раньше.
Заключение
То, как вы оптимизируете кодирование и передачу текстовых ресурсов, является базовой концепцией производительности, но она имеет большое влияние. Убедитесь, что вы делаете все возможное, чтобы гарантировать, что ресурсы, подходящие для минификации и сжатия, получат выгоду от этой оптимизации.
Что еще более важно, убедитесь, что эти процессы автоматизированы. Для минификации используйте сборщик, чтобы применить минификацию к подходящим ресурсам. Убедитесь, что конфигурация вашего веб-сервера поддерживает сжатие, но более того, используйте наиболее эффективное из доступных сжатий. Чтобы сделать это как можно проще, используйте CDN для автоматизации сжатия, поскольку они не только могут сжимать ресурсы за вас, но и делать это очень быстро.
Закрепив эти базовые концепции производительности в архитектуре вашего веб-сайта, вы можете быть уверены, что ваши усилия по оптимизации производительности находятся на хорошей основе, а последующие оптимизации могут опираться на прочную основу из хороших базовых практик.