Сегодня я кратко просмотрел «Высокопроизводительные веб-сайты». Китайская версия этой книги называется «Руководство по созданию высокопроизводительных веб-сайтов».
В этой книге также есть расширенная глава «Еще более быстрые веб-сайты», в которой подробно рассматриваются отдельные проблемы, а китайский перевод называется «Расширенное руководство по созданию высокопроизводительных веб-сайтов».
Автор представил его в ссылке Дубана выше, поэтому я не буду копировать его здесь.
В этой книге представлены 14 принципов улучшения производительности веб-сайтов, каждый принцип представляет собой отдельную главу с примерами. Большинство из этих принципов очень практичны и подходят для архитекторов сайтов и интерфейсных инженеров. Это имеет большее значение для фронтенд-инженеров.
На этот раз я посмотрел оригинальную версию. У меня нет практического опыта в веб-разработке, и я читаю ее в спешке, поэтому могут быть пропуски и некорректные выражения. Надеюсь, пользователи сети меня поправят.
Принцип 1. Уменьшите количество HTTP-запросов
Для формирования запроса и ожидания ответа требуется время, поэтому чем меньше запросов, тем лучше. Общая идея сокращения запросов — объединить ресурсы и уменьшить количество файлов, необходимых для отображения страницы.
1. Карта изображений
Установив атрибут usemap тега <img> и используя тег <map>, вы можете разделить изображение на несколько областей и указать на разные ссылки. По сравнению с использованием нескольких изображений для создания ссылок по отдельности количество запросов уменьшается.
2. CSS SPRite (интеграция CSS-текстур/сшивание текстур/позиционирование текстур)
Это делается путем установки стиля фонового положения элемента. Обычно используется для значков интерфейса. Типичные из них могут относиться к маленьким кнопкам над редактором TinyMCE. Несколько маленьких изображений по существу вырезаются из единого большого изображения с разными смещениями. Таким образом, многие кнопки в интерфейсе загрузки фактически нужно запрашивать только один раз (один раз запрашивая большое изображение), что уменьшает количество HTTP-запросов.
3. Встроенное изображение
Не указывайте URL-адрес внешнего файла изображения в src <img>, а напрямую поместите информацию об изображении. Например, src="data:image/gif;base64,R0lGODlhDAAMAL..." полезен в некоторых особых случаях (например, небольшое изображение используется только на текущей странице).
Принцип 2. Используйте многопоточную CDN.
Предоставьте своему сайту доступ к нескольким линиям связи (например, внутренним телекоммуникациям, China Unicom, China Mobile) и нескольким географическим местоположениям (север, юг, запад), чтобы все пользователи могли быстро получить к нему доступ.
Принцип 3. Используйте HTTP-кеш
Добавьте информацию заголовка Long Expires к ресурсам, которые не обновляются часто (например, статическим изображениям). После кэширования эти ресурсы не будут передаваться снова в течение длительного времени.
Принцип 4. Используйте сжатие Gzip.
Используйте Gzip для сжатия HTTP-сообщений, чтобы уменьшить их размер и время передачи.
Принцип 5. Размещайте таблицы стилей в начале страницы.
Сначала загрузите таблицу стилей, чтобы отрисовка страницы могла начаться раньше, давая пользователям ощущение, что страница загружается быстрее.
Принцип 6: Размещайте скрипты в конце страницы
Причина та же, что и 5. Сначала обрабатывается отображение страницы, отрисовка страницы завершается раньше, а логика скрипта выполняется позже, что дает пользователю ощущение, что страница загружается быстрее.
Принцип 7. Избегайте использования выражений CSS
Чрезмерно сложная логика сценария JavaScript, операции поиска и выбора в DOM снизят эффективность обработки страниц.
Принцип 8. Используйте Javascript и CSS в качестве внешних ресурсов.
Кажется, что это противоречит идее слияния в принципе 1, но это не так: учитывая, что каждая страница представляет общедоступный ресурс JavaScript (например, jQuery или библиотеку JavaScript, такую как ExtJS), судя по производительности только одной встроенной страницы. (т. е. встраивание JavaScript в HTML) страницы будут загружаться быстрее (из-за меньшего количества HTTP-запросов), чем исходящие страницы (введенные с помощью тегов <script>). Но если этот общедоступный ресурс JavaScript представлен на многих страницах, то встроенная схема вызовет повторную передачу (поскольку этот ресурс встроен в каждую страницу, эта часть ресурса должна передаваться каждый раз, когда страница открывается, что приводит к потере сетевой передачи данных). ресурсы). Эту проблему можно решить, сделав этот ресурс независимым и ссылаясь на него извне.
Поскольку JavaScript и CSS относительно стабильны, мы можем установить более длительные сроки действия для соответствующих ресурсов (см. Принцип 3).
Принцип 9. Уменьшите количество запросов DNS
Совет автора такой:
1. Используйте Keep-Alive, чтобы оставаться на связи
Если соединение разорвано, при следующем подключении необходимо будет выполнить поиск DNS. Даже если соответствующее сопоставление доменного имени и IP-адреса было кэшировано, поиск займет некоторое время.
2. Уменьшите количество доменных имен
Каждый раз, когда вы запрашиваете новое доменное имя, вам необходимо искать другое доменное имя через DNS, а кэш DNS не может работать. Поэтому вам следует постараться организовать сайт под единым доменным именем и избегать использования слишком большого количества имен поддоменов.
Принцип 10. Минимизируйте свой JavaScript
Используйте инструмент сжатия JS для сжатия вашего JavaScript, он очень эффективен. Просто посмотрите на два разных дистрибутива jQuery, чтобы увидеть разницу:
http://code.jquery.com/jquery-1.6.2.js версия кода jQuery для чтения, 230 КБ
http://code.jquery.com/jquery-1.6.2.min.js сжатая версия кода jQuery (для фактического развертывания), 89,4 КБ
Принцип 11. Старайтесь избегать перенаправлений
Перенаправление означает, что перед тем, как вы фактически получите доступ к странице, которую хотите просмотреть, добавляется дополнительный раунд HTTP-запросов (клиент инициирует HTTP-запрос → HTTP-сервер возвращает ответ перенаправления → клиент инициирует запрос нового URL-адреса → HTTP-запрос). сервер возвращает контент, подчеркнутые части — это дополнительные запросы), поэтому он требует больше времени (что также создает у людей ощущение более медленного ответа). Поэтому не используйте перенаправления без необходимости. Несколько «нужных» ситуаций:
1. Избегайте недействительных URL-адресов
После миграции старого сайта, чтобы старый URL-адрес не стал недействительным, запросы на старый URL-адрес обычно перенаправляются на соответствующий адрес новой системы.
2. Украшение URL
Преобразование между читаемыми URL-адресами и фактическими URL-адресами ресурсов. Например, для панели инструментов Google пользователи запоминают http://toolbar.google.com, который является семантическим адресом для людей, но запомнить http://www.google сложно. .com/tools/Firefox/toolbar/FT3/intl/en/index.html — это реальный адрес ресурса. Поэтому необходимо сохранить первое и перенаправить запросы первого на второе.
Принцип 12. Удаление дубликатов скриптов
Не размещайте один и тот же сценарий на странице повторно. Например, сценарии B и C зависят от A, поэтому на страницах, использующих B и C, могут быть повторяющиеся ссылки на A. Решение состоит в том, чтобы вручную проверять зависимости для простых сайтов и исключить повторные внедрения для сложных сайтов, вам необходимо создать собственный механизм управления зависимостями/контроля версий;
Принцип 13. Обращайтесь с ETag осторожно
ETag — это еще один метод HTTP-кэша, помимо Last-Modified. Определите, был ли ресурс изменен посредством хеширования. Но есть некоторые проблемы с ETag, такие как:
1. Несогласованность: разные веб-серверы (Apache, IIS и т. д.) определяют разные форматы ETag.
2. Расчет ETag нестабилен (из-за учета слишком большого количества факторов), таких как:
1) Одни и те же ресурсы имеют разные ETag, рассчитанные на разных серверах, а крупномасштабные веб-приложения обычно обслуживаются более чем одним сервером. Это приводит к тому, что кэшированные ресурсы клиента на сервере A остаются действительными, но в следующий раз он запрашивает B. Потому что. ETag отличается, он считается недействительным, что приводит к повторной передаче одного и того же ресурса.
2) Ресурс остается неизменным, но ETag меняется из-за изменений некоторых других факторов, например, изменения файла конфигурации. Прямым следствием является то, что после обновления системы происходят масштабные сбои кэша клиента, что приводит к значительному увеличению объема передачи и снижению производительности сайта.
Предложение автора: либо улучшить существующий метод расчета ETag под особенности вашего приложения, либо просто не использовать ETag и использовать простейший Last-Modified.
Принцип 14. Использование HTTP-кэша с помощью Ajax
Ajax — это асинхронный запрос. Асинхронные запросы не будут блокировать ваши текущие операции, и когда запрос будет завершен, вы сразу увидите результаты. Но асинхронность не означает, что ее можно завершить мгновенно, а также не означает, что ее можно терпеть и требовать бесконечное количество времени для завершения. Поэтому на производительность Ajax-запросов тоже нужно обращать внимание. Существует множество запросов Ajax, которые обращаются к относительно стабильным ресурсам, поэтому не забывайте эффективно использовать механизм HTTP-кэша для запросов Ajax. Подробности см. в Принципах 3 и 13.
Автор: Ян Мэндун
Источник статьи: блог Ян Мэндуна. При перепечатке указывайте ссылку на источник.