WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 |
ПРОБЛЕМЫ СКОРОСТИ ЗАГРУЗКИ ВЕБ-РЕСУРСОВ НА СТОРОНЕ КЛИЕНТА: КЛАССИФИКАЦИЯ И МЕТОДЫ РЕШЕНИЯ Н.С. Мациевский Московский физико-технический институт (государственный университет) 141700, Московская область, г. Долгопрудный, Институтский пер., д. 9 Аннотация. В данной статье рассматриваются вопросы, связанные с текущим состоянием и производительностью веб-ресурсов в современном Интернете. Делается аспект на вопросах производительности, связанных с особенностями работы пользовательских агентов (браузеров), а также на существующих методах решения определенного ряда проблем, возникающих вследствие использования браузерами тех или иных ограничений при загрузке веб-ресурсов. В статье предлагается простой алгоритм, позволяющий принять решение относительно любого аспекта клиентской производительности загрузки веб-ресурсов.

Annotation. This article is concerned about client side issues of web resources load process related to user agents (browsers) behavior. A lot of modern problems with current load algorithms are investigated and all known solutions with their area or efficiency are compared. Also a simple way to make decision about every aspect of client side productivity of web resources is offered with detailed explanations.

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

Каждое наше действие в Интернете затрагивает многочисленные технические аспекты сетевых соединений и передачи данных. При текущих скоростях доступа в Интернет можно подумать, что любой веб-ресурс работает быстро или что скорость его работы зависит только от скорости подключения (самого ресурса или конечного пользователя). Однако, по данным последних исследований [1] рост размера страницы среднего веб-ресурса лишь немногим уступает росту пропускной способности каналов доступа. А если учесть, что с каждым годом расслоение пользователей по скорости подключения к Интернету только усиливается, то ситуация принимает уже критический характер: ведь для обеспечения высокой скорости загрузки для 90% пользователей нужно использовать более прогрессивные и технологичные методы.

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

Согласно прошлогоднему исследованию [2], проведенному инженерами Yahoo! в области пользовательских интерфейсов, 95% времени при загрузке веб-ресурса связано с задержками на стороне конечного пользователя. И только 5% приходится на «серверную» составляющую (которая включает, кроме ожидания ответа, собственно, от сервера, еще и время на DNS-запрос, время на установление TCP/IP-соединения и ряд других издержек). Именно поэтому оптимизация времени загрузки страницы является одной из первостепенных задач При этом каждый проблемный вопрос, будь то использование стандартов при верстке страницы, комбинирование фоновых изображений для уменьшения числа запросов к серверу, применение JavaScript-логики на странице, должен решаться, в первую очередь, исходя не только из фактического технического задания, но и максимальной производительности на стороне браузера.

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

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

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

Психологические аспекты загрузки веб-страницы Соответствующее исследование продемонстрировало, что пользовательское раздражение сильно возрастает, если скорость загрузки страницы превышает 8-секунд безо всякого уведомления пользователя о процессе загрузки [3]. Последние работы в этой области показали, что пользователи с широкополосным доступом еще менее терпимы к задержкам при загрузке веб-страниц по сравнению с пользователями с более узким каналом. В опросе, проведенном JupiterResearch [4], было установлено, что 33% пользователя скоростного соединения не хотят ждать более 4 секунд при загрузке страницы, при этом 43% пользователей не ждут более 6 секунд.



В исследовании, проведенном в 2004, Fiona Nah установила, что терпимое время ожидания (ТВО) для неработающих ссылок (без обратной связи) находилось между 5 и 8 секундами [5]. С добавлением уведомления пользователя о процессе загрузки (обратной связи), например, индикатора загрузки, ТВО увеличилось до 38 секунд.

Распределение ТВО для повторных попыток зайти на неработающие ссылки имело максимум в районе 2-3 секунд (без обратной связи). Nah заключила, что ТВО для вебпользователей имеет максимум около 2 секунд. Если учесть стремление пользователя посетить веб-ресурс повторно, то Dennis Galletta и др. показали, что кривая сглаживается при 4 и более секундах и уходит в нуль в районе 8 и более секунд [6].

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

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

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

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

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

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

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

Эффективность основных методов Если описать все оптимизационные методы, то они разбиваются на 4 основные группы:

1. Уменьшение объема представляемых данных (сюда относится использование алгоритмов сжатия и соответствующих форматов представления изображений).

2. Кэширование (использование парных клиент-серверных заголовков для уменьшения времени передачи информации при ее сохранении ее актуальности).

3. Уменьшение числа ресурсов (различные методы объединения загружаемых файлов) 4. «Визуальная» оптимизация (к которой относятся алгоритмы разделения процесса загрузки на 4 стадии для максимального ускорения загрузки основных стадий, а также ряд методов, связанных с параллельными потоками загрузки).

При уменьшении объема данных наиболее действенных будет архивирование (gzip/deflate) на сервере. Практически все современные гиганты Интернет-индустрии сейчас отдают текстовые файлы в gzip-формате (это и GoogLe, и Yahoo!, и Yandex).

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

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

Далее по эффективности обычно используют объединение как текстовых (.html,.css,.js) файлов, так и графических, используемых в оформительских целях. Текстовые файлы объединять очень просто, при этом мы можем сэкономить значительное время, уходящее на дополнительные запросы к серверу. При объединении и графических файлов обычно используют технологии CSS Sprites (Image Map), которую не так легко автоматизировать, но при больших количествах иконок на странице она способна значительно ускорить загрузку.

К методам «визуальной» оптимизации можно отнести как экстремальную оптимизацию: когда все сопутствующие файлы включены в итоговый – так и распределение нагрузки по загрузке файлов по нескольким серверам. На реальном времени отображения страницы эти действия сказываются не сильно, в некоторых случаях их внедрение сопряжено со значительными трудностями. Однако, в случае высоконагруженных проектов, даже несколько миллисекунд могут сказаться на значительных (в абсолютном смысле) приростах прибылей [7].

Основным критерием, который должен определять, какие методы и в каком объеме стоит применять, естественно, будет аудитория ресурса. Для каждого вебресурса можно выделить несколько характерных групп страниц, которые посещаются тем или иным типом аудитории. В первую группу войдут веб-страницы, на которые заходят всякий раз новые пользователи. Это и специальные рекламные страницы, задачей которых является прямая продажа продукта. Это и страницы объявлений, которые пользователи должны увидеть один, максимум, два раза. И т.д. Аудитория таких страниц на 99,9% состоит из новых пользователей. Следовательно, для них нужно применять методы, снижающие, в первую очередь, число обращений к серверу для показа страницы: объединение файлов и экстремальную оптимизацию.





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

Для таких страниц можно выделить характерное ядро постоянных посетителей, однако, оно составляет не более 30-40% от общего числа. Большинство веб-ресурсов, которые «живут» на поисковом трафике, являются замечательным примеро, полностью подходящих под эту группу. Для таких страниц, в первую очередь, стоит рассмотреть методы уменьшения числа запросов (CSS Sprites), также возможную минимизацию всех текстовых файлов (HTML, CSS, JavaScript). Однако, применение кэширование в данном случае оправдано в меньшей степени, так как уменьшит время загрузки страницы не так сильно (если брать средневзвешенное значение), чем, например, параллельные запросы.

Наконец, к третьей группе относятся все остальные страницы, а именно те, аудитория которых в большей степени постоянна (конкретные числа стоит рассматривать из параметров бизнес-эффективности различных групп аудитории, однако, характерные значения здесь – это 30% постоянных пользователей ресурса). В этой группе наиболее действенным будет, конечно же, кэширование и оптимизация скорости работы JavaScript и Flash-анимации – ведь именно она будет «съедать» больше всего времени.

Методы сжатия Основными инструментами для уменьшения объема данных являются разнообразные минимизаторы и обфускаторы (для JavaScript-файлов), архивирование и также ряд утилит для уменьшения размера изображений. Давайте рассмотрим их по порядку. Как показало проведенное тестирование средств сжатия CSS, лучше всего с этой задачей справляется проект CSS Tidy [8] (примерно на одном уровне с ним идет YUI Compressor [9]), который вместе с дополнительным архивированием файлов позволяет получить выигрыш до 85% [10].

Рисунок 2. Зависимость выигрыша для сжатия CSS-файлов при использовании различных инструментов и архивирования Для JavaScript-файлов ситуация несколько интереснее [11]. Если применять архивирование, то лучше всего использовать YUI Compressor [9], так как он, в среднем, сжимает в этом случае лучше. Если архивирование для JavaScript-файлов применять нельзя, то лидером в сжатии является Dean Edwards Packer [12], однако, он вносит дополнительные издержки на свою «распаковку». Как показали исследования, для пользователей, которые будут, в основном, загружать JavaScript из кэша, лучше использовать сжатие без обфускации.

Рисунок 3. Зависимость выигрыша для сжатия JavaScript-файлов при использовании различных инструментов и архивирования Использование архивирования через mod_gzip или mod_deflate для веб-сервера Apache (и соответствующих модулей для других веб-серверов) способно существенно уменьшить размер загружаемых файлов. Однако, в случае очень быстрого канала у пользователей (например, локальный ресурс) и ограниченных ресурсов сервера (высокая удельная нагрузка на создание страницы) будет разумнее сжатие не использовать [13].

Также стоит для архивированных файлов добавить соответствующие заголовки (Cache-Control:private), чтобы избежать ряда проблем с локальными кэширующими прокси-серверами. Для архивирования CSS- и JavaScript-файлов также нужно исключить Safari (для Windows-платформ) и Konqueror из числа тех браузеров, которым можно отправлять gzip-файлы: эти браузеры до последнего времени не умели их корректно распознавать.

Рисунок 4. Пример конфигурации веб-сервера Apache для включения сжатия CSS-и JavaScript-файлов Для большинства графических элементов рекомендуется использовать формат PNG, так как он более экономичен, чем GIF [14] в представлении графиков и рисунков с ограниченной цветовой палитрой. Однако, для небольших изображений GIF-формат может оказаться лучше. На данный момент PNG-изображения поддерживаются, практически, всеми браузерами.

Сейчас существует проблема с поддержкой альфа-канала в Internet Explorer (которую обещают исправить в 8 версии), однако, в 6 и 7 версии она решается через фильтр ImageAlphaLoader, что позволяет использовать полупрозрачность, практически, в полном объеме.

В случае проблем с совпадением цветом (снова в Internet Explorer) рекомендуется удалить из изображения gAMA-чанков, отвечающих за прозрачность (в таком случае получить прозрачное изображение с совпадающими цветами в Internet Explorer не получится). В этом также может помочь ряд утилит, уменьшающих размер PNG-изображений: например, pngcrush. Для уменьшения размера JPEG-изображений можно применить утилиту jpegtran, которая не затрагивает цветовые данные изображения, а удаляет комментарии и другие мета-данные.

Для анимированных изображений стоит использовать либо GIF-изображения с несколькими кадрами, либо DHTML-анимацию (применяя JavaScript0логику для смены PNG- или JPEG-картинок). Анимированные PNG-изображения пока не поддерживаются браузерами [14].

Pages:     || 2 | 3 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.