Цитирую, потому что прямая ссыла у меня почему-то не работает. Интересное — жирным
Техники снижения трафика
23 августа 2002 г.
Одной из ключевых проблем при создании интерактивного сайта является скорость взаимодействия с пользователем. Каждое действие, каждое нажатие кнопки требует перезагрузки всей страницы, что пагубно сказывается на трафике, а следовательно — на скорости работы.
Автор статьи: Сергей Чистович
Одной из ключевых проблем при создании интерактивного сайта является скорость взаимодействия с пользователем. Каждое действие, каждое нажатие кнопки требует перезагрузки всей страницы, что пагубно сказывается на трафике, а следовательно — на скорости работы. Существуют различные техники для снижения объема пересылаемых данных, и некоторые из них будут здесь описаны (с разной степенью подробности). Эти приемы не представляют большого секрета, но могут быть полезны. Используются они, к сожалению, нечасто.
SSI на стороне клиента
Один из несложных приемов, довольно широко известный, но неудобный в реализации.Суть его в том, чтобы позволить клиенту хранить неизменяющиеся блоки страницы (шапку, навигацию, footer) у себя в кэше, а не выкачивать их заново с каждым запросом. Идеологически этот прием напоминает фреймы, но без недостатков, им присущих.
Как это делается? Разумеется, современные принципы работы браузеров не позволяют написать в странице инструкции типа SSI, обрабатываемые клиентом. А что может исполняться на клиенте? Правильно, Javascript. Метод document.write() скоро начнут проходить в первом классе, так что создавать HTML-код из скрипта мы умеем. Дело за малым: написать скрипт, который печатает шапку, и сохранить его в файле shapka.js, который на радость всем клиентам прекрасно кэшируется.
Часто, конечно, хочется сделать шапку и прочие модули зависимыми от текущей страницы, но в простейших случаях эта проблема разрешима. Можно написать скрипт, который будет разбирать строку запроса, и в соответствии с полученной информацией вносить коррективы.
SRC и его применения
Описанный выше «client-SSI» — по сути, один из случаев использования возможностей атрибута src. Фактически у него существует масса применений, некоторые из которых даже не воспринимаются как нечто особенное. Например, все счетчики и рейтинги, а также хакеры, пользуются тем, что тег <IMG> — не просто картинка, а объект, имеющий «источник». Особенно широкие горизонты раскрывает возможность динамического изменения src.
Первое и самое простое — это rollover. Возможность изменения картинки при наведении на нее курсора поражает каждого начинающего дизайнера, и уже никогда он не сможет от нее отказаться. Представить сайт без rollover’ов практически невозможно.
Дальше — больше. Появляются фреймы, inline-фреймы, всякие такие удовольствия. Но это не так интересно само по себе, куда интереснее, что это дает возможности выполнения серверных скриптов без перезагрузки страницы.
Обмен информацией без перезагрузки страницы
Этот параграф основан на статье Exchanging information with a server without reloading your HTML page (автор — Tong Li) с сайта IBM DeveloperWorks. Разумеется, с некоторыми дополнениями и изменениями.
Часто возникает желание передать какую-то информацию на сервер, минимизируя объем возвращаемой информации. Существуют два случая: когда нам вообще не надо ничего получать с сервера, и когда какой-то отклик все же нужен. В первом случае прекрасно подходит картинка нулевого размера, src которой является URL-ом вызываемого скрипта. При нажатии кнопки (или какой-то иной инициализации действия) Javascript на клиенте формирует строку запроса и приравнивает ей src картинки-исполнителя. Серьезным минусом является то, что мы ограничены GET-методом, поэтому объем запроса ограничен двумя килобайтами. Да, можно написать функцию, которая разрежет большой запрос на кусочки и отправит их по отдельности, но удобства такая необходимость определенно не добавляет.
Во втором случае тоже применяется изменение src, и, соответственно, остается ограничение GET-запроса, но в качестве рабочего инструмента используется <IFRAME>. В самом деле, зачем перегружать целую страницу, если можно сделать все в маленьком окошке (в зависимости от ситуации можно сделать его и вовсе нулевым, а результат разбирать скриптом).
Методы, описанные в этом параграфе, любопытны и действенны. Но есть в них один недостаток: для простой вроде бы задачи (отослать информацию на сервер, не перезагружая страницу) применяются сложные методы, пишутся замысловатые скрипты, изменяются атрибуты элементов… такое впечатление, что мы пытаемся сделать что-то противозаконное. Между тем, есть очень простой, но малоизвестный метод, позволяющий сделать то же самое куда меньшими усилиями. Малоизвестный, несмотря на то, что вся информация лежит под носом, надо только протянуть руку. Подходит он, правда, исключительно для случая, когда содержательного ответа не требуется, только «да» или «нет».
Сокровищница HTTP
Как общается браузер с сервером? Говоря попросту, клиент шлет запрос, сервер возвращает ответ. Что нам сейчас интересно, так это статус возврата в HTTP-заголовке. Такие статусы, как 404 и 403 знакомы, думаю, всем. А вот код 204 не так широко известен. Он имеет описание No Content, и при получении такого кода браузер не должен ничего делать, то есть перезагрузки страницы не произойдет. На первый взгляд может показаться, что таким образом мы не можем получить никакого ответа от сервера, и потому невозможно узнать, выполнился скрипт или нет, не произошла ли какая-то ошибка. Но это неверно: в случае неудачи просто не надо посылать этот код возврата, а вернуть вместо него сообщение об ошибке или что-то еще. Обратите внимание, что сейчас мы не ограничиваем себя методом GET, и потому отправить на сервер большую и сложную форму можно без малейшего труда.
Рассмотрим более детально, как следует использовать этот прием, и что можно с него получить. Представим себе, что у нас есть некоторая форма, которую нужно обработать скриптом. Исполняющий скрипт должен возвращать в случае успешной обработки код 204, и страница с формой не будет перезагружаться. Поскольку пользователю все же необходимо какое-то подтверждение успеха, на кнопку submit следует повесить нечто вроде OnClick="alert(’Все путем!’)". Особенно это будет удобно, если форма является малозначительной частью страницы, например, голосовалка или подписка на рассылку.
Если обработка данных прошла неудачно, пользователя надо вернуть к заполнению формы — например, с помощью указания заголовка Location. Осторожно, тут есть тонкость. Если указан не полный, а локальный URL в таком заголовке, то сервер может не потребовать нового запроса от браузера, а сразу выдаст требуемый документ, отчего в адресной строке и журнале браузера останется адрес нашего скрипта. Плохо это потому, что обработчик информации останется в истории, и манипуляции с кнопкой «Назад» могут привести посетителя к нему опять, что чревато повторной отсылкой информации. Поэтому URL стоит указывать полностью. Такой особенностью (по некоторым данным, отчасти подтверждаемым проверкой) обладает Apache. Возможно, это зависит от конфигурации или версии. Не забудьте проверить.
Некоторое недоумение посетителя (в случае неудачной обработки данных) может вызвать то, что сначала появится alert с подтверждением успеха, а потом загрузится страница с сообщением об ошибке. Но вероятность такой ситуации можно минимизировать, если перед отправкой информации тщательно проверять ее Javascript’ом. Тогда ошибки будут возникать только в статистически несущественных случаях некорректной работы сервера.
При желании можно придумать еще много различных применений этому методу. А можно почитать документацию и найти еще что-нибудь интересное.
Эпилог
Существует множество различных способов сэкономить пару килобайт, но самый простой — писать чистый, компактный код, не злоупотреблять графикой и сценариями. Никакие технические приемы не помогут топорно сверстанной странице, загроможденной ненужными элементами и неграмотной разметкой. Самое простое решение — всегда самое лучшее.
Примечание. В этой статье нет никаких соображений о межбраузерной совместимости, отчасти из-за лени, отчасти в силу уважения к стандартам и надежды, что рано или поздно все браузеры будут совместимы. При непосредственных реализациях той или иной техники настоятельно рекомендуется ее хорошенько потестировать. Желаю успеха!
