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

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

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

Этап 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; c omponentName2.js .

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

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

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

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

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

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

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