Как превратить милю в километр

Мои самые первые колонки для «ИнфоБума» были написаны в праздничные дни — второго и девятого мая. Вот и сегодня воскресенье вновь приходится на праздник. И хотя седьмое ноября, по всей видимости, перестанет, наконец, быть «красным днем календаря», можно констатировать хорошую традицию — даже праздники нашей «Веб-анатомии…» нипочем. (Интересно, а Новый год случайно не выпадет на воскресенье? Сейчас гляну в календарик… Так и есть: второго января, по идее, должна бы выйти очередная колонка. Ну уж нет уж, тут — увольте. Что-то мне слабо верится, что во второй день года я смогу добраться до компьютера, а тем более, набрать на клавиатуре нечто осмысленное. Да и читать все это наверняка особенно-то некому будет. Скорее всего, вообще уеду из Москвы на недельку куда-нибудь в Карелию или в Лапландию, к заснеженным елям… Хотя, как знать.)

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

Разумеется, самый зловредный из всех факторов задержек здесь — это низкая (в большинстве случаев) пропускная способность «последней мили», канала связи, соединяющего компьютер пользователя с сетью провайдера. Пока что даже в Москве «диалапщиков» среди домашних пользователей больше половины. Излишне говорить, что за пределами МКАД это соотношение намного более контрастно.

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

Стоит ли говорить, что 100 Кбайт — это не предельный и вряд ли уже даже средний объем страниц в Рунете, а 1 Мбит/с — мягко говоря, не самая плохая пропускная способность для выделенки?..

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

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

Любую веб-страницу, отправляемую сервером клиенту, вне зависимости от способов ее представления на стороне сервера, можно разложить на составляющие, каждая из которых вполне подвластна оптимизации:

• управляющие конструкции разметки;
• лист стилей (внедренный в HTML-код или связанный с ним);
• текстовое содержание;
• графические изображения и прочие связанные объекты.

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

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

Клиент, имеющий несчастье быть подключенным к Интернету по коммутируемой телефонной линии, за 10 секунд способен принять порядка 20…30 Кбайт данных. Но следует учитывать, что 2…3 секунды (и то в лучшем случае) драгоценного времени отнимают другие факторы задержек, в том числе из рассмотренных нами ранее. Таким образом, «критическая масса» уменьшается до ничтожного уровня где-то порядка 15 Кбайт. Если же учесть, что пользователь может пытаться загружать несколько страниц одновременно, то «сумма чистыми на руки» будет и вовсе смехотворной.

Подчеркиваю, что речь идет об объеме всей веб-страницы в целом, включая связанные с ней объекты, а не только о размере HTML-кода!

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

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

Хорошо бы, если каждый функциональный блок описывался единственным элементом <div> — это положительно сказывается как на логике построения документа, так и на объеме его кода.

Сокращения объема результирующего кода можно добиться, выжав из него всю лишнюю «воду» — комментарии, бесполезные метатеги (с атрибутами вроде name="generator", name="author" и т. д.), горизонтальные отступы («лесенку», которую программисты и кодеры используют для повышения удобочитаемости листингов), лишние переходы на новую строку, а тем более пустые строки… Строго говоря, весь HTML-код можно вообще записать в одну строку, и при динамическом формировании оного грех так не поступать.

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

Какую выгоду (в цифрах) это может принести? Представьте себе страницу с более-менее сложной версткой, подразумевающей порядка 10 уровней вложенности элементов. Если на каждый новый уровень отводится 2 дополнительных пробела «лесенки», в начале каждой строки будет в среднем по 10 пробелов (это, кстати, очень оптимистичный прогноз, особенно в случае верстки таблицами). В пересчете на 100 строк кода получаем 1000 символов из ничего. Если длина строк с той же самой целью удобочитаемости кода ограничивается, предположим, 80-ю символами, то при средней протяженности абзацев текста в 400 знаков на 10 абзацев получаем порядка 50 лишних переходов на новую строку. И это только для абзацев текстового содержания! А каждый переход на новую строку — в лучшем случае один символ (код 10), в худшем — два (код 10 + код 13, если документ загружен на сервер в том виде, в каком он был сохранен в каком бы то ни было редакторе под Windows). При самых скромных подсчетах, если удалить только пробелы в начале строк и лишние переносы, никак не затрагивая комментарии и прочие бесполезные HTML-конструкции, получим свыше килобайта экономии. И это на 100 строк кода, которые при ограничении длины 80-ю знаками при всем желании не могли занимать больше 8 килобайт. Мне кажется, что даже ради этих вот 10—20% стоит попотеть. Ведь любые мероприятия эффективны в комплексе — как говорится, с миру по нитке…

Тем не менее, все хорошо в меру. Если вам дороги рекомендации W3C, ни в коем случае нельзя причислять к «лишним» элементам объявления типа документа (<!DOCTYPE …>), кавычки, обрамляющие значения атрибутов или закрывающие теги там, где они предполагаются стандартом, атрибуты alt и т. д. Недопустимо заменять теги, аналогичные <stong> и <em>, их «краткими аналогами» <b> и <i> — эти вещи далеко не эквивалентны! В данном случае идет речь о подмене логики документа визуальным форматированием.

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

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

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

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

#main {margin: 0px; padding: 10px; top: 100px; left: 0px; width: 500px; font-family: Tahoma, Verdana, Arial, sans-serif; font-size: 80%; color: #666; background-color: #f0f0f0; border-style: solid; border-width: 1px; border-color: #999}
#news {margin: 0px; padding: 10px; top: 100px; left: 530px; width: 200px; font-family: Tahoma, Verdana, Arial, sans-serif; font-size: 80%; color: #666; background-color: #f0f0f0; border-style: solid; border-width: 1px; border-color: #999}

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

#main, #news {margin: 0px; padding: 10px; top: 100px; font-family: Tahoma, Verdana, Arial, sans-serif; font-size: 80%; color: #666; background: #f0f0f0; border: solid 1px #999}
#main {left: 0px; width: 500px}
#news {left: 530px; width: 200px}

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

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

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

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

Что до связанных со страницами объектов — порассуждаем о них в другой раз.