GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самые читаемые материалы
Краткий обзор бесплатных "движков" (CMS) для сайта(26581)
Бизнес-планирование для Интернет-проекта(20390)
Обзор решений для тестирования сайтов(18394)
Составление сметы на сайт(17450)
Конструкторы сайтов: дешево и сердито(10814)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » Управление проектами » Со скоростью курьерского

Со скоростью курьерского


Артемий Ломов
artemy@lomov.ru
http://www.lomov.ru/

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

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

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

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

Разделение труда
Скорость загрузки страниц зависит от многих факторов, ибо сам процесс неоднороден и включает в себя массу составляющих. Целесообразно выделить некоторые из них, наиболее существенным образом влияющие на время загрузки страниц:

  • поиск IP-адреса сервера по его доменному имени;
  • преодоление очереди запросов;
  • обработка запроса сервером;
  • передача запрошенных данных по каналу связи пользователю;
  • отображение объектов страницы браузером

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

Мой адрес — не дом и не улица…
Если адрес хоста задается в виде доменного имени, это неизбежно приводит к ощутимым временным задержкам. Ведь фактически обращение к web-серверу все равно производится по IP-адресу, а клиент, не зная такового, вынужден сперва обращаться к серверу службы DNS.

В принципе, открытие ссылок и загрузку объектов страниц можно ускорить, используя в атрибутах href, src и им подобных IP-адреса вместо доменных имен соответствующих серверов. Но тому есть существенные ограничения.

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

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

В-третьих, при смене хостинга старый IP-адрес ресурса теряет свою актуальность, тогда как домен второго уровня легко «переносится» от провайдера к провайдеру. В силу перечисленных предостережений редкие web-мастера решаются на столь неоднозначный и ответственный шаг.

Хорошему проекту — хороший хостинг
Длина очереди запросов зависит от степени загруженности сервера и от качества канала, при помощи которого он связан с внешним миром.

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

Всю жизнь на проводе
Сеанс взаимодействия клиента и сервера (HTTP-транзакция) состоит из следующих этапов:

  • установка соединения;
  • передача запроса от клиента серверу;
  • передача данных от сервера клиенту;
  • разрыв соединения

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

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

За поддержку означенной возможности отвечает ряд директив базовой конфигурации сервера. Приведем здесь их список для Apache 1.2 и выше:

  • KeepAlive on|off — разрешает или запрещает серверу осуществлять постоянные соединения. Значение по умолчанию — on.
  • KeepAliveTimeOut число — определяет количество секунд ожидания очередного запроса перед закрытием постоянного соединения. Значение по умолчанию — 15.
  • MaxKeepAliveRequests число — определяет возможное количество запросов, разрешенных для каждого постоянного соединения. Значение по умолчанию — 100. Значение 0 соответствует отсутствию ограничений.

Самостоятельно контролировать эти параметры можно только в том случае, если вы располагаете выделенным сервером. Услуга эта у хостеров достаточно дорогая, в среднем порядка 50 долларов в месяц. Если же ваш web-ресурс использует виртуальный сервер, следует осведомиться у службы техподдержки своего хостинг-провайдера о значениях упомянутых директив. Лично я не вижу причин для запрета постоянных соединений.

Мелочь, а неприятно
Если ссылка указывает на каталог, а не на конкретный файл, на конце адреса в обязательном порядке должен присутствовать символ слэша. Пример правильного URL: http://www.apache.org/dist/.

В противном случае произойдет переадресация — сервер отправит клиенту сообщение «301 Moved Permanently» с указанием верной ссылки на каталог, что порождает лишний трафик и провоцирует отсрочку передачи индексного файла каталога клиенту.

За сокращение рабочего дня
Львиную долю нагрузки на сервер порождают динамические страницы. Выполнение сервером замысловатых CGI-скриптов и даже обработка простых SSI-директив немилосердно расходуют память машины и ее процессорное время. Статические HTML-страницы, напротив, возвращаются сервером буквально молниеносно.

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

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

Что же делать? Ответ один: сокращать до минимума количество информации, передаваемой от сервера клиенту.

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

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

Каждое значимое графическое изображение необходимо снабжать содержательным описанием в виде alt-текста. Игнорировать атрибут alt из «благих» соображений уменьшения объема страницы — большая ошибка. Не сослужите пользователям медвежьей услуги. То же самое касается кавычек, обрамляющих значения атрибутов тэгов, закрывающих тэгов при их необходимости и т. д. — все элементы, которые приветствуются стандартами, не должны игнорироваться. Некоторые web-мастера рекомендуют использовать тэг <i> вместо <em>, <b> вместо <strong> из соображений «краткости». Не слушайте подобных горе-рекомендаций, не подменяйте логику документа визуальным форматированием!

Сокращать объем HTML-кода можно за счет комментариев, символов перевода строки и лишних пробелов. Оставьте себе на локальной машине удобочитаемые версии страниц со стройной «лесенкой» отступов и обилием комментариев, а на сервер загружайте другие версии страниц, без излишеств. Формировать их можно при помощи несложного Perl-скрипта, состоящего из нескольких регулярных выражений.

Если объем кода HTML-страницы превышает 20…30 Кбайт, ищите ошибку в структуре сайта. Объемные тексты лучше распределять по нескольким страницам.

Больше интерактивности
Содержимое HTML-таблиц не отображается до тех пор, пока браузер не загрузит код всей таблицы целиком и не определит размеры изображений, должных размещаться в таблице. Поэтому не следует при табличной верстке макета «загонять» все содержимое страницы в одну большую таблицу. Выгоднее, напротив, разбить страницу на несколько идущих подряд таблиц, и тогда все содержимое будет отображаться порциями по мере загрузки. Размеры всех изображений в пикселях должны непосредственно указываться в HTML-коде (атрибуты width и height тэга <img>).

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

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

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

Изображения с резкими переходами цвета, состоящие из точных линий, лучше всего сохранять в формате GIF (сжатие без потери качества). Палитра GIF-файла ограничена 256 цветами, но на практике бывает достаточно гораздо меньшего количества цветов. Даже если в автоматическом режиме ImageReady предлагает палитру, состоящую из 256 цветов, почти всегда без видимых потерь можно «урезать» ее в 2…4 раза. И хотя ImageReady позволяет вручную корректировать палитру GIF-файла так, что количество цветов в ней может быть совершенно произвольным, лучше всего выбирать значения, соответствующие целому числу бит, т. е. 2, 4, 8, 16, 32, 64, 128 и 256. Дело в том, что цвет каждого пикселя в изображении, состоящем, скажем, из 64 цветов, кодируется шестью битами, а в 65-цветной картинке — уже семью, вследствие чего объем файла в первом случае может быть существенно меньшим.

Бывают неоднозначные случаи — порой не всегда очевидно, в каком формате сохранить то или иное изображение. Здесь лучше действовать опытным путем: предпочтение отдается тому формату, в котором файл картинки занимает меньше места при достаточном визуальном качестве изображения.

Использование формата PNG далеко не однозначно. Прежде всего, не все браузеры его поддерживают, но, как мне представляется, в 2003 году это уже неактуально. Главная проблема в том, что PNG отнюдь не всегда дает меньший размер файла при сопоставимом качестве изображения. С каждым конкретным изображением нужно экспериментировать, игра стоит свеч! Суммарный объем графики на странице информационного web-ресурса не должен превышать 30…40 Кбайт, но чем меньше — тем лучше.

Если на сайте предполагается разместить фотоальбом, цифровую галерею живописи или иллюстрированный каталог продукции, нужно позаботиться о том, чтобы создать миниатюры изображений, при щелчке мышью на каждой из которых открывалось бы соответствующая полноразмерная иллюстрация. Предварительный просмотр миниатюр способен сэкономить значительное количество времени пользователя. Ориентировочный объем файла каждой миниатюры должен составлять 4…5 Кбайт, тогда как полноразмерное изображение может иметь объем 50…100 Кбайт. Ни в коем случае нельзя прибегать к созданию «миниатюр» посредством уменьшения линейных размеров изображений при помощи HTML — ведь объем файлов от этого не уменьшается.

Напротив, применять атрибуты width и height для растягивания изображений не зазорно. Бывают случаи, когда, например, необходимо разместить на странице оттенение в виде вертикально ориентированного градиента высотой в десяток пикселей в виде горизонтальной полосы во всю ширину страницы. Не создавайте для этого графическое изображение соответствующей ширины! Достаточно просто растянуть средствами HTML градиент, имеющий в ширину всего один пиксель.

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

Даже такая, на первый взгляд, простая работа, как рендеринг страницы с фоновым изображением размером 2000x2000 пикселей, может существенно затормозить работу подобного компьютера, если вообще не «повесить» его насмерть. JPEG-файл, в котором можно сохранить такой фон, может занимать не слишком много — всего каких-то 30 килобайт, но декодирование и отображение его способно отнять почти 12 мегабайт памяти компьютера (умножьте количество пикселей в изображении на 24 бита цвета в режиме True Color).

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

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

Успех того или иного проекта полностью подчинен разработчику. Причем одну из главных ролей здесь играет здравый смысл.

Статья опубликована в журнале CHIP, № 6, 2003

 
27.09.2004
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.