Представьте себе крупную веб-страницу с большим количеством изображений и скриптов, которая загружается в браузере практически моментально, с такой же скоростью, как загрузка файлов с вашего жесткого диска. Теперь представьте, что вы изучаете веб-сайт, обладающий 60-70 страницами, и все они загружаются очень и очень быстро. Звучит интригующе? Но как реализовать это? Заполнить кэш браузера? Предварительно загрузить все компоненты веб-страниц? Это вообще возможно?

И да, и нет. Это становится возможным при использовании Gears. Gears – проект с открытым исходным кодом – позволяет сохранять все “статичные” компоненты (JS, CSS, изображения, и т.д.) одной веб-страницы или целого сайта и загружать их из локального хранилища всякий раз, когда в них нуждается браузер. Однако команда разработчиков Gears решила несколько сместить свои приоритеты в пользу оффлайн хранения HTML 5.0, что выступало превалирующей идеей для Gears. К сожалению, спецификация HTML 5.0 для оффлайн хранения поддерживает только некоторые из функций, которые и были реализованы в Gears, таким образом, указанный тип кэширования (регулируемый пользователем и управляемый сервером) невозможен.

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

Давайте бросим беглый взгляд на работу кэша:

• Мы (пользователи) просматриваем веб-страницу
• Сервер сообщает браузеру: “Эй, ты, эти несколько файлов (JS, CSS, изображения и т.д.) почти никогда не обновляются, засунь их к себе в кэш и не проси, чтобы я отправил их снова в течение десяти лет!”
• Браузер думает: “Хм-м, поместить их в кэш, как он сказал? Я подумаю об этом. Вы знаете, я Веб-Браузер. Я должен загружать страницы очень и очень быстро. Я не хочу держать при себе огромный кэш, в котором находятся миллионы файлов. Это замедлит мою работу. Давайте посмотрим, вернется ли пользователь когда-нибудь снова к этой странице.”

Если бы мы настойчиво заходили на одну и ту же страницу, то браузер в конечном счете бы передумал: “Возможно, слова Сервера были справедливы, и я должен поместить эти файлы в свой кэш. Это ускорило бы загрузку страницы. Но что произойдет, если эти файлы будут обновлены… Я лучше попрошу сервер проверить, были ли они обновлены, чтобы мой кэш всегда отвечал текущей ситуации”.

Несколько лет назад в WordPress появилась возможность Turbo, которая была реализована с помощью Gears. Она применялась не для того, чтобы сделать WordPress онлайн приложением; с ее помощью мы могли создать управляемый сервером кэш. Функция Turbo работала великолепно. Даже самые тяжелые страницы в панели администратора загружались значительно быстрее, вне зависимости от того, как часто пользователи посещали их.

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

• Пользователь решает, какие веб-сайты/веб-приложения будут кэшироваться, может добавлять/удалять их.
• Сервер (т.е. веб-приложение) обслуживает кэш, по необходимости обновляя, добавляя или удаляя файлы.

Результаты были захватывающими. Нам не нужно было подцеплять и сжимать скрипты и стилевые таблицы. Мы даже прекратили сжатие редактора TinyMCE, который в одиночку подгружал примерно 30-40 файлов во время своей инициализации. И время загрузки страницы колебалось от 0.5 до 1.5 секунд, вне зависимости от того, насколько тяжелой была страница. Для сравнения: до использования “супер кэша” время загрузки страниц было 5-9 секунд.

Почему процесс загрузки страниц значительно ускорился? Все просто: Gears ликвидировал все запросы к серверу для кэшированных файлов. Это относится даже к “HEAD” запросам. В реализации Turbo единственным файлом, который загружался с сервера, был актуальный HTML. Все остальные компоненты веб-страницы находились в оффлайн хранилище Gears.

В качестве дополнительной выгоды мы получали снижение траффика на сервере. На первый взгляд это не так много: 30-40 запросов для компонентов веб-страницы, 30-40 HEAD запросов на каждую страницу в течение некоторого времени (учитывая, что кэш браузера постоянно в работе). Однако давайте взглянем на это в глобальной перспективе: каждый час загружаются несколько миллионов веб-страниц.

Почему бы не сделать то же самое с помощью оффлайн хранения, реализованного в HTML 5.0? Ответ очевиден: оно не позволяет пойти аналогичным путем. Спецификация HTML 5.0 для оффлайн хранения хороша только для… оффлайн хранения. В ней отсутствуют многие возможности, которые предлагает Gears. Да, существует обходное решение. Мы можем сохранить оффлайн скелет веб-страницы и затем загрузить весь динамический контент с помощью XHR (AJAX), однако у этого метода существуют другие (довольно раздражающие) ограничения.

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

Что мы можем сделать с HTML 5.0? Не думаю, что здесь можно что-либо сделать, за исключением изменения, или скорее улучшения спецификации HTML 5.0 для оффлайн хранения. XHR “взлом”, который позволяет реализовать в HTML 5.0 рассмотренный нами вид кэширования, по-прежнему остается всего лишь “взломом”.

По материалам сайта azaozz.wordpress.com.