Недавно я изучаю книгу «Руководство по строительству высокопроизводительных веб -сайтов». Эта статья представляет собой учебную записку. Я разберу то, что я узнал для легкого просмотра позже.
Золотое правило производительности объясняет, что только от 10% до 20% от времени отклика конечного пользователя принимается запрашиваемые документы HTML-пользователя, в то время как оставшиеся от 80% до 90% времени тратится на HTTP-запросы на все компоненты (изображения, сценарии, таблицы стилей и т. Д.), На ссылки на HTML-документ, и время отклика конечного пользователя проводится на страницы.
-Стивщики
1 слияние файла (уменьшите количество HTTP -запросов)
CSS спрайты
Используйте спрайты CSS, чтобы объединить изображения, используемые на веб-сайте, в одно изображение, и используйте значок с помощью фоновой позиции, ширины и высоты, чтобы управлять положением фонового изображения. Этот метод может уменьшить несколько запросов изображения до одного раза. Есть много инструментов для создания спрайтов CSS. Есть связанные плагины в Grunt и Gulp, и CSSGAGA также хороша.
Merge JS и CSS
Как и карта спрайта, слияние файлов CSS и JS также является важным способом сокращения HTTP -запросов. В настоящее время нет противоречия по поводу слияния файлов CSS, но для текущей распространенности модульности JS объединение всех файлов JS в один файл, по -видимому, является отсталым. Правильным способом состоит в том, чтобы соблюдать скомпилированный языковой шаблон, поддерживать модульность JS и генерировать целевые файлы только для файлов JS, используемых в начальном запросе во время процесса генерации.
2 Используйте контент для публикации сети (сократите время запроса HTTP)
Еще один фактор, влияющий на время запроса HTTP, - это расстояние, которое вы находитесь на веб -сервере веб -сайта. Очевидно, чем дольше расстояние, тем дольше требуется запрос, который может значительно улучшиться через CDN.
CDN - это веб -сервер, распространяемый в нескольких географических местах, используемый для более эффективной публикации контента для пользователей. Основной функцией CDN является хранение статических файлов для конечных пользователей, а также предоставляет загрузку, службы безопасности и другие функции.
3 Установите кеш браузера (избегайте дублирующих HTTP -запросов)
Использование истечения срока действия/контроля кеша
Браузеры могут избежать повторяющихся запросов каждый раз, используя кэш. HTTP 1.0 и HTTP 1.1 имеют различные методы реализации кэша, истекает (1,0) и контроль от кэша (1.1). Срок действия веб -сервера истекает, чтобы сообщить клиенту, что все кэшированные копии файла будут использоваться в течение указанного времени и больше не дают запросов на сервер, например:
Истекает: Чт, 01 декабря 2016 г. 16:00:00 по Гринвичу (формат GMT)
Эта настройка означает, что по состоянию на 1 декабря 2016 года кэшированная копия доступна без каких -либо дополнительных запросов.
Срок действия истекает ограничение на путь передачи крайних целей: он требует строгой синхронизации между клиентскими и серверными часами, в то время как контроль кэша, представленный HTTP 1.1
Контроль кэша: максимальный возраст = 31536000
Этот параметр означает, что время кэша составляет один год, и рекомендуется использовать контроль от кэша, но когда HTTP 1.1 поддерживается, еще одна вещь, чтобы отметить: контроль от кеша и истечение срок действия существуют в то же время, контроль Cache имеет более высокий приоритет.
Настроить или удалить ETAG
Использование истечения срока действия/контроля кэша может избежать второго посещения, используйте локальный кэш, чтобы избежать дублирующих HTTP-запросов и улучшить скорость веб-сайта. Однако, если пользователь нажимает на обновление или истечение срока действия браузера, запрос HTTP GET все еще будет выдан на сервер. Если файл не изменяется в настоящее время, сервер не вернет весь файл, но вернет 304 не измененный код состояния.
Для сервера есть два базиса, чтобы определить, изменился ли файл: последняя модифицированная (последняя дата изменения) и ETAG (тег объекта);
ETAG (теги сущностей) были введены в HTTP 1.1 и имеют более высокий приоритет, когда он существует в то же время, что и на прошлой модифицированной. Сервер сравнивает ETAG (if-none match), отправленный клиентом с текущим ETAG, и возвращает 304, не модифицированный, если то же самое верно, в противном случае весь файл и 200 OK будут возвращены.
Существует проблема с ETAG: когда браузер отправляет запрос GET на один сервер, а затем запрашивает компонент с другого сервера, ETAG не совпадает. Конечно, если ваш веб -сайт размещен на одном сервере, и теперь многие веб -сайты используют несколько серверов, существование ETAG значительно снижает частоту успеха достоверности проверки.
Решением этой проблемы является настройка ETAG, удаление значения Innode Server и сохранить только метку модификации и размер в качестве значения ETAG, или непосредственно удалить ETAG и использовать последнюю модифицированную для проверки достоверности файла.
4 компонента сжатия (уменьшите размер запроса HTTP)
Сжав HTTP-передаваемые файлы, уменьшая размер HTTP-запросов и улучшая скорость запроса, GZIP является наиболее часто используемым и наиболее эффективным методом сжатия в настоящее время.
Однако не все файлы ресурсов должны быть сжаты. Стоимость сжатия включает в себя, что сервер должен тратить циклы процессоров на сжатие, а клиент также должен распаковать сжатые файлы, которые должны быть взвешены в сочетании с его собственным веб -сайтом. Теперь большинство веб -сайтов сжимают свои документы HTML, а некоторые веб -сайты предпочитают сжать JS и CSS. Почти никакие веб -сайты не используют сжатие GZIP для изображений, PDF -файлов и других файлов. Причина в том, что эти файлы были сжаты, и использование HTTP для сжатия вещей, которые были чрезмерны, не могут сделать его меньше. Фактически, добавление заголовков, сжатие словарей и проверка тела ответа фактически делает его больше, а также тратить процессор.
Как включить GZIP на веб -сайте требует настройки на веб -сервере (IIS, Nginx, Apache и т. Д.).
5 файлов CSS размещены в первую очередь
Размещение файла CSS в первое и последнее не влияет на HTTP -запросы, поэтому он согласуется с точки зрения времени запроса. Тем не менее, с точки зрения пользовательского опыта, размещение файла CSS в первом даст вам лучший пользовательский опыт.
Причина в том, что браузер анализирует HTML -документ сверху вниз и помещает файл CSS в голову. Страница сначала сделает запрос в файл CSS, затем загрузите дерево DOM и отобразит его. Страница будет постепенно представлена пользователю.
Напротив, если файл CSS размещен в конце, страница загружает полный DOM и запрашивает файл CSS, а затем отображает все дерево DOM и представляет его пользователю. С точки зрения пользователя, прежде чем запрос файла CSS, вся страница находится в состоянии белого экрана. Белый экран - это поведение браузера. Объяснение Дэвида Хаятта для этого
Перед тем, как дерево стиля будет полностью загружено, рендеринг дерева DOM является пустой тратой, потому что оно будет снова отображаться после загрузки дерева стиля, и возникает проблема FOUC (без содержимого стиля).
Еще одна вещь, которую следует отметить, это использовать ссылку вместо @Import, чтобы представить таблицы стилей CSS. Даже если стиль, представленный @import, написан в заголовке, он будет загружен в конце документа.
6 файл JS размещен в конце
HTTP -запросы параллельны, а количество параллельных загрузок разных браузеров отличается (2, 4 или 8). Параллельные загрузки улучшают скорость HTTP -запросов. Помещение файла JS в первую очередь не только заблокирует загрузку последующего файла, но и заблокирует рендеринг страницы.
Почему это происходит? Есть две причины:
Document.Write может существовать в файле JS для изменения содержимого страницы, поэтому страница не будет отображаться после выполнения сценария.
Различные файлы JS могут иметь зависимости независимо от размера, поэтому они должны быть выполнены по порядку, поэтому они запрещены при загрузке сценариев.
Следовательно, лучший способ - разместить файл JS в конце и подождать, пока все визуальные компоненты страницы не будут загружены, прежде чем сделать запросы на улучшение пользовательского опыта.
Выше приведены некоторые предложения по улучшению производительности веб -сайта JavaScript, которые редактор представил вам (1). Я надеюсь, что это будет полезно для вас. Если вы хотите узнать больше, пожалуйста, обратите внимание на wulin.com. В следующей статье редактор представит вам предложения по улучшению оптимизации производительности веб -сайта JavaScript (II)