Разгони свой сайт - читать бесплатно онлайн полную версию книги автора Николай Мациевский (Глава 1. Что такое клиентская оптимизация?) #3

Глава 1. Что такое клиентская оптимизация?

1.1. Цели и задачи оптимизации

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

Рис.1.1. Тенденция изменения размера страницы и числа объектов для сайтов, проверяемых через Web Optimizator в 2008 году

В настоящее время на каждой странице вызывается несколько десятков внешних объектов, а размер исходного файла составляет не более 5% от общего размера. Как показали многочисленные исследования, размер веб-страницы за последние 5 лет увеличился втрое, а число объектов на ней — почти в два раза. При этом темпы роста средней пропускной способности канала лишь немного выше данных показателей. Если учитывать расслоение пользователей по скоростям доступа, то стремление уменьшить число пользователей, превышающих допустимый порог ожидания на 1–5%, заставляет применять все более сложные и передовые технологии.

Естественно, что технологии эти не ограничиваются сжатием текстовых (HTML, CSS, JavaScript) файлов на стороне сервера. Как несложно понять, основную часть внешних объектов на странице составляют изображения или мультимедийные файлы. И для них тоже есть свои методы оптимизации.

Основные задачи оптимизации

Если говорить кратко, то можно выделить 3 основных задачи клиентской оптимизации:

Оптимизация размера файлов.

Оптимизация задержек при загрузке.

Оптимизация взаимодействия с пользователем.

Краткий обзор технологий

При этом все основные методы можно разбить на 6 групп (каждая из которых позволяет решить одну из заявленных задач).

Уменьшение размера объектов. Здесь фигурируют сжатие и методы оптимизации изображений, подробнее об этом можно прочитать во второй главе.

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

Объединение объектов. Основными технологиями являются слияние текстовых файлов, применение CSS Sprites или data:URI для изображений. Этому посвящена четвертая глава книги.

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

Оптимизация CSS-производительности, что проявляется в скорости появления первоначальной картинки в браузере пользователя и скорости ее дальнейшего изменения. О CSS-производительности рассказывает шестая глава.

Оптимизация JavaScript. Есть достаточно много проблемных мест в JavaScript, о которых необходимо знать при проектировании сложных веб-приложений. Обо всем этом можно прочитать в седьмой главе.

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

Все советы в книге упорядочены по увеличению сложности внедрения и уменьшению возможного выигрыша при загрузке страницы. Для простых веб-проектов можно ограничиться только включением кэширования и архивирования (gzip или deflate). Более сложным понадобится изменить верстку, используя CSS Sprites или data:URI, и добавить несколько хостов для загрузки изображений. Для высоконагруженных проектов (некоторые из них проанализированы в конце восьмой главы) нужно учитывать все аспекты клиентской оптимизации с самого начала при проектировании и применять их последовательно для достижения наилучшего результата.

1.2. Психологические аспекты производительности

Согласно многочисленным исследованиям пользовательское раздражение сильно возрастает, если скорость загрузки страницы превышает 8–10 секунд безо всякого уведомления пользователя о процессе загрузки. Последние работы в этой области показали, что пользователи с широкополосным доступом еще менее терпимы к задержкам при загрузке веб-страниц по сравнению с пользователями с более узким каналом.

В проведенном в 2007 году опросе было установлено, что 33% пользователей скоростного соединения не хотят ждать при загрузке страницы более 4 секунд, при этом 43% пользователей не ждут более 6 секунд. В данном случае имеется в виду, что пользователь в большинстве случаев покинет сайт, если в течение 5–10 секунд будет видеть вместо него белый экран в браузере.

Терпимое время ожидания

При исследовании, проведенном в 2004 году, было установлено, что терпимое время ожидания для неработающих ссылок (без обратной связи) находилось между 5 и 8 секундами. С добавлением уведомления пользователя о процессе загрузки (обратной связи), например, индикатора загрузки, такое время ожидания увеличилось до 38 секунд. Распределение времени для повторных попыток зайти на неработающие ссылки имело максимум в районе 23 секунд (без наличия каких-либо индикаторов, показывающих, что страница загружается или в данный момент недоступна).

Таким образом, можно заключить, что для 95% пользователей время ожидания ответа от неработающего сайта составит не более 8 секунд. Если учесть стремление пользователя посетить сайт повторно, то исследования продемонстрировали крайне малое (почти равное нулю) число пользователей, ждущих более 10 секунд.

Эффекты медленной скорости загрузки

Даже малые изменения времени загрузки могут иметь значительные последствия. Так, для Google ( http://www.google.com/ ) увеличение времени загрузки для страницы с 10 поисковыми результатами на 0,4 секунды и на 0,9 секунд для страницы с 30 результатами сказалось на уменьшении трафика и рекламных доходов на 20% (в соответствии с исследованиями, проведенными в 2006 году). Когда главную страницу Google Maps ( http://maps.google.com/ ) уменьшили в объеме с 100 Кб до 70-80 Кб, трафик увеличился на 10% в течение первой недели и еще на 25% в следующие три недели (по данным 2006 года).

Тестирование в 2007 году для Amazon дало очень близкие результаты: каждые 100 мс увеличения времени загрузки для Amazon.com уменьшали продажи на 1%. Эксперименты Microsoft для Live Search ( http://www.live.com/ ) показали, что при замедлении загрузки страниц на 1 секунду количество сброшенных поисковых запросов возросло на 1% и число кликов по рекламе уменьшилось на 1,5%. При увеличении времени загрузки страницы с результатами еще на 2 секунды количество сброшенных поисковых запросов возросло на 2,5% и число кликов по рекламе уменьшилось на 4,4%.

Как время ответа сайта влияет на пользовательскую психологию

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

«Терпимое» время будет сильно зависеть от аудитории, но его можно достаточно надежно проверить: для этого нужно значительно (например, в 2–3 раза) увеличить (или уменьшить) время задержки при показе страницы и посмотреть на число отказов (число пользователей, закрывших страницу сразу после захода на сайт) и на число постоянных посетителей. Если при сильном увеличении (или уменьшении) задержки при загрузке сайта количество пользователей практически не изменилось, значит, страница уже загружается в допустимом диапазоне. Если же число пользователей претерпело видимые изменения, то, следовательно, со временем загрузки сайта нужно что-то делать.

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

1.3. Стадии загрузки страницы

Рис.1.2. Стадии загрузки страницы

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

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

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

Полная загрузка страницы. Страница полностью появилась в браузере, на ней представлена вся заявленная информация, и она практически готова к дальнейшим действиям пользователя.

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

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

Расставляем приоритеты

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

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

Узкие места

Первая и вторая стадии загрузки являются наиболее проблемными аспектами при анализе производительности. Это вполне понятно: загрузка первоначального HTML-файла, равно как и CSS-/JavaScript-файлов идет в один поток, — и на первое место выходит уменьшение числа запросов при загрузке.

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

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

Но все эти приемы могут как ускорить загрузку следующих для пользователя страниц, так и упорядочить саму пост-загрузку. Как достичь этого эффекта и как распределить файлы и клиентскую логику между стадиями загрузки страницы, рассказано в четвертой главе.

1.4. Клиентская и серверная оптимизация: сходство и различия

Клиентская оптимизация оперирует двумя основными принципами: меньше данных и меньше соединений. Но именно эти принципы помогают уменьшить нагрузку на сам сервер. Давайте посмотрим, как это происходит и как перенести часть серверной нагрузки на клиентский браузер.

Кэширование во главу угла

Сервер может управлять состоянием кэша клиентского браузера, во-первых, через заголовок Cache-Control (и его атрибуты max-age, pre-check, post-check), который может указывать на промежуток времени, в течение которого соответствующий файл следует хранить на диске и не запрашивать с сервера. Рекомендуется для всех статических файлов выставлять максимальное время жизни кэша и форсировать его обновление у пользователя через изменение URL ресурса (с помощью RewriteRule либо GET-параметра).

Во-вторых, состоянием клиентского кэша можно управлять через заголовки ETag и Last-Modified, которые ставят в соответствие каждому файлу уникальный идентификатор, изменяющийся при изменении файла, — своеобразная цифровая подпись или хэш. При этом серверу нужно не пересылать файл заново, а лишь ответить статус-кодом 304 на запрос браузера, если файл не изменился с момента последнего запроса. В итоге сам файл не пересылается, соединение (и сокет) освобождается быстрее, и ресурсы сервера также экономятся.

Подробнее о кэшировании рассказывается в третьей главе.

Меньше запросов — легче серверу

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

Наряду с объединением текстовых файлов не стоит пренебрегать и объединением картинок. Если учитывать, что современные браузеры могут устанавливать несколько десятков одновременных соединений с сервером для получения статических файлов (и 80% из них — это именно картинки), то экономия от использования CSS Sprites, Image Map или data:URI подхода рассчитывается очень просто. В некоторых случаях удается уменьшить число соединений браузера с сервером для загрузки одной HTML-страницы в 8-10 раз.

Объединение файлов рассматривается в четвертой главе.

Архивировать и кэшировать на сервере

Как показали проведенные исследования, gzip-сжатие текстового файла «на лету» в 95–98% случаев позволяет сократить время на передачу файла браузеру. Если хранить архивированные копии файлов на сервере (в памяти proxy-сервера или просто на диске), то соединение в общем случае удается освободить в 3-4 раза быстрее.

В случае высоконагруженных серверов с динамическими HTML-файлами gzip также может быть применим. Здесь стоит ориентироваться на минимальную степень сжатия, ибо процессорные издержки при этом растут линейно, а размер уменьшается лишь логарифмически.

О сжатии рассказывает следующая глава.

Кто у кого на службе?

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

Когда дело доходит до взаимодействия «клиент-сервер», нужно помнить обо всех аспектах оптимизации. И у клиентской составляющей есть своя, выделенная область ответственности. Она находится в окне браузера — это веб-страница, которая загружается у пользователя и с которой он взаимодействует.

1.5. Применение в разработке приложений

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

Ниже рассказывается, как можно организовать создание веб-приложения, ориентируясь на самые важные аспекты клиентской оптимизации.

Этап 1: Доставка информации и оформления

На этом этапе разработчики должны сделать все возможное, чтобы не замедлить скорость загрузки страницы. Фактически идет речь об ускорении первой стадии загрузки. Наиболее важными методами здесь является сжатие (gzip) текстовых файлов и объединение файлов стилей (CSS). Для CSS- и JavaScript-файлов возможно применять статическое архивирование (без необходимости архивировать каждый раз эти файлы «на лету»; этому посвящена вторая глава).

При загрузке страницы браузер запросит все CSS-файлы, объявленные в head страницы, последовательно. Поэтому каждый файл добавляет задержку в загрузке, равную времени запроса к серверу (даже если предположить, что устанавливаемое соединение keep-alive и нам не нужно совершать все TCP/IP-процедуры, — в противном случае мы экономим гораздо больше). Для файлов скриптов рекомендуется применить либо также объединение, либо вообще вынести их в пост-загрузку (подробнее об этом рассказано в седьмой главе).

Итог первого этапа — это доставленный и оформленный HTML. И издержки на доставку JavaScript сведены к минимуму (на этом этапе он только мешает, поскольку замедляет отображение основного содержимого страницы). Время от начала до завершения загрузки такой страницы при включенном и выключенном JavaScript (при вынесении его в пост-загрузку) фактически будет одинаковым. Это и будет выигрышем в скорости загрузки!

Этап 2: Кэширование файлов оформления и параллельные запросы

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

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

CSS Sprites достаточно трудоемки в автоматической «склейке», поэтому их внедряют обычно на первом этапе (при создании макета страниц). При использовании метода data:URI на первом этапе о них можно забыть, потому что автоматизированное решение просто в реализации и не требует от верстальщика отдельных технологических познаний. Об этом можно прочитать в четвертой главе.

Этап 3: Жизнь после загрузки страницы

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

Говорят, что иногда «грамм видимости важнее килограмма сути» — это как раз про JavaScript. Ведь именно на нем можно реализовать механизмы, упрощающие действия пользователя; можно сделать много различных визуальных эффектов, подчеркивающих оформление, удобство и полезность сайта (а фактически — усилить и сфокусировать всю работу, которую проделали разработчики на предыдущих этапах).

К этому моменту мы должны иметь оформленную HTML-страницу, на которой все ссылки и формы обязаны работать без JavaScript (как этого добиться, как отделить представление страницы от ее функционирования, рассказывается в седьмой главе в разделе про «ненавязчивый» JavaScript).

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

Чтобы не уменьшать скорость доставки контента и оформления, JavaScript-файлы (лучше всего, конечно, один JavaScript-файл; несколько файлов должны использоваться только при большой сложности клиентского интерфейса) должны быть подключены перед закрытием тега body (а в идеале — вынесены именно в пост-загрузку).

Задача по обеспечению взаимодействия пользователя с интерфейсом сайта сводится к выполнению следующих действий:

найти DOM-элементы, требующие «оживления» (далее — компоненты);

определить, что это за компонент;

обеспечить подключение необходимого кода JavaScipt;

следить за очередностью подключения файлов;

не позволять нескольких загрузок одного файла.

Все это напрямую следует из концепции «ненавязчивого» JavaScript, которая описана в седьмой главе.

Поиск необходимых DOM-элементов должен нам дать список названий JavaScript-компонентов. Названия компонентов должны однозначно соответствовать названиям файлов на сервере, в которых содержится код для них. Также нам может понадобиться загрузить некоторые дополнительные CSS-правила для найденных компонентов (в случае небольшого количества CSS-кода разумно будет включить его в основной файл) ради каких-то визуальных эффектов, которые можно пропустить на первом этапе загрузки. Например, все эффекты по смене изображения при наведении мыши обеспечиваются через CSS-правила и технику CSS Sprites.

Список названий компонент можно объединить в один запрос к серверу. В итоге на стадии пост-загрузки должны осуществляться запросы к файлам вида static.site.net/jas/componentName1.css;componentName2.css и static.site.net/jas/componentName1.js;componentName2.js.

У данного подхода есть два недостатка:

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

Иногда на странице может оказаться очень много компонент, причем так много, что длина имени запрашиваемого объединенного файла перевалит за возможности файловой системы (например, 255 символов у Ext3) — в этом случае потребуется разбить один запрос на несколько последовательных.

Этап 4: Предупреждаем действия пользователя

Если после посещения главной страницы большинство пользователей попадают внутрь сайта, то логично будет после полной загрузки главной страницы запрашивать стили и скрипты, применяемые на других страницах сайта. Для пользователя это выльется в небольшое увеличение трафика (при использовании сжатия текстовая информация составляет 10–20% от объема графики), однако во вполне заметное ускорение загрузки последующих страниц.

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

Естественно, что за балансировку третьей и четвертой стадий отвечает уже JavaScript-разработчик и фронтенд-архитектор — ведь именно в зоне ответственности последнего находится скорость загрузки страницы.