Оптимизация для улучшения времени загрузки страниц

Коди Линдли (Cody Lindley) | 11 июня 2010 г.

Актуальный на сегодняшний день вопрос: каковы наиболее существенные механизмы оптимизации, которые можно реализовать при конструировании веб-страниц? Эту область веб-разработки лучше всего описывает термин «оптимизация времени загрузки». В этой статье изучаются наиболее важные методы оптимизации времени загрузки для создания быстрых веб-страниц.

В другой статье я буду рассматривать методы оптимизации времени выполнения. Оптимизации времени выполнения делают упор на производительность веб-страницы после ее загрузки клиентом (например веб-браузером). В частности, они больше относятся к взаимодействию с пользователем, когда тот приступает к работе после загрузки страницы. Однако в этой статье мы займемся оптимизациями времени загрузки. Оптимизации времени загрузки связаны с сокращением времени, необходимого для загрузки веб-страницы и всех последующих загрузок страниц.

Прежде чем приступить к рассмотрению некоторых оптимизаций времени загрузки, я хочу дать рекомендацию. Используйте измерительный инструмент для проверки времени загрузки! Я знаю, что такая очевидная рекомендация может выглядеть глупо, но измерение исключительно важно. Исходя из моего опыта, слишком много разработчиков воздерживается от измерения производительности страницы. Итак, проще говоря, сделайте измерение производительности веб-страницы частью ежедневной работы в качестве веб-разработчика.

Выбранный мной измерительный тест находится на сайте http://www.webpagetest.org. В качестве краткого обзора этого инструмента взгляните на тест веб-страницы, выполненный для главной страницы этого сайта.

Web Page Test (тест веб-страницы) используется для измерения времени загрузки веб-страницы. Кроме простого измерения времени загрузки, этот тест можно использовать для диагностики причин медленной работы веб-страницы. Вкратце, он предоставляет сведения, необходимые для понимания наиболее затратных частей архитектуры страницы HTML, относящиеся к размерам файлов, запросам HTTP и отрисовке документов.

В частности, интерактивный инструмент Web Page Test подробно рассматривает все действия HTTP, которые возникают во время загрузки веб-страницы. Затем этот инструмент захватывает эти действия и предоставляет различные диаграммы, графики, визуальные элементы и отчеты для объяснения, что происходит во время каждого запроса HTTP. Кроме того, он предоставляет подробности того, как запросы HTTP в целом влияют друг на друга, а также какое это имеет отношение к итогу, то есть к общему времени загрузки.

Честно, чтобы разобраться в этом инструменте, достаточно посетить сайт и начать им пользоваться. Если вы читаете эту статью и ищете ответы, относящиеся к производительности, тогда функциональность и сведения, предоставляемые этим инструментом, приобретут особенное значение, как только вы начнете его использовать. Я настоятельно рекомендую открыть окно браузера прямо сейчас и воспользоваться инструментом Web Page Test для тестирования веб-страницы. Если нужно небольшое руководство по использованию этого инструмента, можно извлечь демо-ролик от Дейва Артца (Dave Artz). Дейв — директор по оптимизации веб-сайтов в компании AOL.  Следовательно, он может знать пару вещей, которые могут оказаться полезными.

То, что этот инструмент является моим предпочитаемым измерительным инструментом, не значит, что он также будет и вашим. Существуют разные доступные инструменты, которые предоставляют если не идентичные, то очень похожие измерения.

Далее приводится список некоторых наиболее хорошо известных инструментов для измерения времени загрузки веб-страниц. Я сам использую многие из этих инструментов вместе с упомянутым выше Web Page Test от компании AOL.

  • YSlow от Yahoo (дополнительный компонент Firefox)
  • Page Speed от Google (дополнительный компонент Firefox)
  • Pingdom Tools — полный тест страницы (инструмент в Интернете)
  • FireBug — сетевая вкладка (дополнительный компонент Firefox)
  • Средства веб-разработчика (встроенные в Safari и Chrome)

Теперь, когда у нас есть измерительный инструмент, и мы можем тестировать оптимизации и находить возможности оптимизации, перейдем к изучению некоторых методов оптимизации страниц.

Я хочу дать несколько простых и легко усваиваемых описаний. Поэтому мы сосредоточимся только на пяти категориях в безбрежном океане методов оптимизации. Это следующие категории: сокращение числа запросов HTTP; уменьшение размеров файлов; включение упорядочивания для скорости; распределение загрузки; проверка времени отклика сервера.

Сокращение числа запросов HTTP

Этот метод сводится просто к уменьшению количества файлов, которые требует веб-страница. Уменьшая зависимости для изображений, таблиц стилей и скриптов, можно избежать узких мест, которые могут возникать из-за занятости браузера загрузкой активов (запросов HTTP).

При построении веб-страниц необходимо стараться сократить зависимости, а следовательно и число запросов HTTP. Далее приводятся способы, которыми это можно сделать.

  1. Использование спрайтов CSS. С помощью спрайта CSS можно включить несколько графических элементов в файл изображения. В результате исключаются запросы HTTP, извлекающие только один элемент изображения. Используя спрайты, можно загружать несколько элементов изображений в одном запросе HTTP.
  2. Объединение аналогичных внешних зависимостей в один файл для рабочего кода. При разработке файлов CSS и JavaScript может быть логично сохранять файлы в модульной архитектуре. Однако когда код перемещается из среды разработки в производственную среду, необходимо объединить эти модули в один файл (или в минимально возможное число файлов), чтобы сократить число запросов HTTP. Многие из средств, используемых для уменьшения CSS и JavaScript, также предоставляют возможность сцеплять файлы вместе. Конечно, объединение можно сделать вручную. Однако в моих проектах я использую средство Minify для автоматического объединения.  

Уменьшение размеров файлов

Надеюсь, это не является неожиданностью. Загрузка и анализ маленьких файлов выполняются быстрее, чем больших. Зная это, мы всегда должны сокращать размеры файлов (изображений, CSS, JS, HTML) до минимально возможных, дающих желаемый результат. Далее мы изучим пять способов, с помощью которых можно уменьшить размер файла.

  1. Уменьшение файлов CSS и JavaScript. После объединения файлов CSS и JavaScript их необходимо уменьшить. Уменьшение включает удаление комментариев, пробелов, а также сокращение имен переменных. Разные средства предоставляют разные алгоритмы уменьшения, но главное в том, что необходимо использовать некоторое уменьшение на некотором уровне, чтобы уменьшить размер файлов CSS и JavaScript. Лично я использую Minify, YUI Compressor, ShrinkSafe и Closure Compiler. Эти средства довольно сложные, и хотя я рекомендую их использование, простые средства также часто могут решить проблему. Например, многие такие средства доступны как онлайн-решения в Интернете (ShrinkSafe и YUI Compressor).
  2. Выбор наиболее подходящих форматов изображений и сжатие изображений до минимально приемлемого размера. Не все форматы изображений одинаковы и не все форматы наилучшим образом подходят для конкретного типа изображения. Знание того, когда следует использовать GIF, JPEG или PNG, может быть видом искусства. Добавьте дополнительные сложности при работе с изображениями, содержащими прозрачность, в сочетании с браузерами, по-разному поддерживающими прозрачные изображения, и получите множество сложных вопросов, которые необходимо решить. Объем сведений, необходимый для принятия правильных решений при создании и выборе формата изображений для веб-браузера, выходит далеко за рамки данной статьи. Я предлагаю выполнить поиск в Интернете по теме и изучить, когда, почему и как следует использовать конкретный формат для веб-страниц. После принятия решения о том, какой формат использовать, следующий этап состоит в уменьшении файла до минимального приемлемого значения. Для этого я использовал такие средства, как Ppngcrush и Smush.it. Конечно, Photoshop и Fireworks также могут это делать. Исходя из моего опыта, Fireworks фактически лучше всего сжимает изображения. Ключевая идея в том, чтобы убедиться, что изображения сжаты, и что выбранный формат является идеальным.
  3. Не используйте Flash, если это не необходимо. Flash — это отличное средство, когда совершенно ясно, что его использование оправданно. Использование Flash только ради использования Flash может быть затратным решением, поскольку требуются затраты на подключаемый модуль браузера (проигрывателя Flash Player) для выполнения SWF-файлов. В соответствующей ситуации Flash является спасением. Однако необходимо учитывать, что использование Flash связано с дополнительными издержками. По моим наблюдениям размер SWF-файлов обычно гораздо больше, чем размер всех зависимостей. Кроме того, обычно для включения Flash в веб-страницу требуется некоторое количество дополнительного кода, чтобы иметь дело с теми пользователями, у которых отсутствует соответствующий проигрыватель Flash Player. Поясню, я не являюсь ненавистником Flash. Я только рекомендую сначала исчерпать другие решения (например решения JavaScript), которые меньше по размеру файлов, прежде чем использовать Flash.
  4. Не следует излишне усложнять модель DOM. Если вы еще разворачиваете HTML с помощью табличных макетов, этот раздел для вас. Я не пытаюсь тут быть догматичным. Однако размер документа HTML действительно влияет на время загрузки. Не следует упускать из виду возможности уменьшения размера самих элементов HTML. Это уменьшение в основном происходит в форме сохранения простоты модели DOM. Поэтому используйте минимальное количество разметки, необходимое чтобы оставить удобную семантику и SEO, но чтобы при этом работа была сделана.
  5. Удаляйте ненужные пробелы из документов HTML.  Да, как ни странно, я собираюсь упомянуть это. Я видел страницы HTML, содержащие столько пробелов, что после их удаления размер страницы HTML уменьшался на 90 КБ. Не раздувайте страницы HTML, удаляйте пробелы или хотя бы помните о том, что они утяжеляют страницы. Мы уменьшаем CSS и документы JavaScript для оптимизации; почему бы также не уменьшать документы HTML путем удаления пробелов?
  6. Сжимайте все текстовые файлы с помощью Gzip. Употребляя термин Gzip, мы говорим только о сжатии контента, содержащегося в текстовых файлах, чтобы передавался меньший объем данных. Файлы HTML, CSS и JavaScript являются текстовыми файлами. Их можно сжимать на сервере и отправлять закодированными в формате Gzip, чтобы веб-браузер их распаковывал. Для использования Gzip необходимо некоторое понимание того, что происходит на стороне сервера. Дополнительные сведения см. в этой более подробной статье на сайте betterexplained.com или как обычно без колебаний воспользуйтесь поиском в Интернете, чтобы найти темы, связанные с Gzip.

Включение упорядочивания для скорости

Представьте себе, порядок включения зависимостей в веб-страницу может напрямую влиять на то, сколько времени займет отрисовка и полная загрузка веб-страницы браузером. Это связано с алгоритмами управления запросами HTTP в браузере, и особенно важно то, как запрос HTTP браузера обрабатывает разные типы зависимостей (CSS, VC, JS). Далее подробно рассматриваются два метода включения зависимостей, которые могут улучшить время загрузки страницы.

  1. Включение JavaScript внизу страницы.  Веб-браузер останавливает отрисовку страницы, пока ожидает загрузки и выполнения файлов JavaScript. Это может привести к существенному замедлению отрисовки страницы браузером. Если переместить JavaScript вниз страницы, то пользователь начинает видеть отрисованную страницу быстрее. В связи с этим мы надеемся, что пользователь воспримет нашу страницу как достаточно быструю.
  2. Включение CSS вверху страницы (в заголовке). Главное — предоставить пользователю максимально возможный объема визуальных сведений максимально быстро. При сохранении файлов CSS вверху страницы становится возможной прогрессивная отрисовка страницы, т. е. контент отображается максимально быстро.

Распределение загрузки

Распределение загрузки может быть очень сложной темой. Как правило, количество подключений к одному имени узла в веб-браузере ограничено. Однако при распределении зависимостей на 3 или 4 имени узла браузер может открывать больше подключений, вытягивая зависимости с нескольких серверов одновременно. Конечно, существуют ограничения. Отличный обзор того, что поддерживают разные браузеры, см. на сайте browserscope. Чтобы распределять загрузку и получать одновременные подключения, работающие в нашу пользу, мы можем использовать следующие решения.

  1. Использование CDN. Чтобы распределять загрузку веб-браузера, можно использовать сеть доставки содержимого (CDN). Это не только распределяет загрузку, но также предоставляет ряд веб-серверов, расположенных в разных местах, обслуживающих контент для пользователей на основе их географической близости.
  2. Использование дочерних доменов для симуляции CDN. Альтернативой использованию CDN или заказу дополнительных услуг размещения является симуляция CDN с помощью дочерних доменов. Использование дочерних доменов обеспечивает необходимые уникальные URL-адреса, что позволяет открыть больше одновременных подключений.
  3. Использование бесплатных средств из бесплатной CDN.  По возможности используйте зависимости, размещенные в бесплатных CDN. Например, Google совершенно бесплатно предоставляет размещенные в CDN версии многих популярных решений JavaScript. Когда это актуально, следует пользоваться преимуществами этих бесплатных служб для распределения загрузки.

Проверка времени отклика сервера

Не все сводится к тому, как быстро клиент (то есть веб-браузер) может загружать и анализировать страницу HTML. Сервер также играет роль. Перед тем как приступить к оптимизации клиента, возможно имеет смысл проверить, нет ли узких мест на стороне сервера. Эти проблемы могут иметь широкий диапазон причин: сложные запросы SQL, плохие модели баз данных, перегруженные серверы и непродуманная архитектура приложений, а также многие другие.

В целом, если веб-страница загружается медленно, проверьте, не вызвано ли это сервером. Я был в ситуации, когда какие бы оптимизации ни применялись, сервер просто не отвечал в течение приемлемого времени. Это было вызвано проблемами на сервере. Наша оптимизация на стороне клиента помогала уменьшить время загрузки, но когда серверу требуется от 7 до 8 секунд для ответа на запрос HTTP, наши оптимизации на стороне клиента мало влияют на улучшение времени загрузки. В этом проекте много времени было потрачено на решение неправильной проблемы. После этого проекта, сталкиваясь с проблемами производительности загрузки, я всегда сначала проверяю, насколько быстро сам сервер отвечает на запросы HTTP.

Производительность веб-страниц стала гораздо более сложной областью изучения. В этой статье только намечена сфера этой области знаний. В действительности инженер по оптимизации — это сама по себе должностная обязанность. Фактически сейчас компании набирают инженеров по оптимизации и создают целые департаменты, специализирующиеся на оптимизации кода, поставляемого на компьютеры и мобильные устройства.

Если вы хотите глубже освоить то, что рассматривалось в этой статье, и продолжить изучение методов оптимизации времени загрузки, я настоятельно рекомендую изучить следующие ресурсы: