AlexSol высказал интересную идею, относительно улучшения аяксовой навигации. Идея замечательная. Но ее можно доработать. Как? Обратите внимание на пример, который он приводит.

При нажатии на одну ссылку, догружается один контент. При нажатии на вторую — другой. Но если снова нажать на первую, снова будет подгружаться первый контент с сервера! Разумнее было бы кэшировать эти данные в браузере и не посылать лишний раз гонца запрос серверу. Хорошо бы прибегнуть к кэшированию.

Как сделать кэширование в JavaScript? Об этом данная статья.

Кэширование, с помощью объекта

Метод, о котором хочу рассказать — это кэширование с помощью объекта JavaScript. Суть в том, что мы создаем хэш-массив объект, имена полей которого совпадают с именами локаций. Значения этих полей — это кэшируемые тексты.

//создаем глобальный объект
var CACHE = new Object();

Как записать в кэш что-то? Проще простого!

alert(CACHE.key);

Кроме того, нужно помнить, что объекты в JS - это по сути, ассоциативные массивы. То есть

CACHE.key == CACHE;

Вооружившись этим знанием, приступаем к построению нашего тестового приложения.

Структура html

Для начала, определимся с html. У меня получилось что-то такое:

Как видно, я решил оставил задел, чтобы сделать красивую навигацию по методу AlexSol-а. Делать я ее не буду, но прикрутить ее потом будет делом двух минут. Пока что, давайте узнаем, что делает функция getData?

var CACHE = new Object(); //создаем объект кэша

function getData(id_loc, url2load) {
if (CACHE) { //если в кэше еще нет нужных данных
//загружаем требуемый файл и вызываем функцию cache_n_go,
//которой передаем содержимое файла и id нажатой ссылки
$.get(url2load, function(data) {cache_n_go(data, id_loc)});
}
//если в кэше уже есть нужные нам данные
else {
//получаем данные из кэша
showRes(CACHE + "(из кэша)");
}
}

Как видно, здесь мы как раз используем преимущества кэширования. Если у нас уже есть данные, то мы берем их из кэша. Если еще нет, то с сервера.

Теперь посмотрим что творится в функции cahce_n_go.

function cache_n_go(text, id_loc) {
CACHE = text;
showRes(text);
}

Ничего сверхъестественного в ней нет. Она кэширует полученый текст и отправляет его функции showRes, чтобы та его показала. Кстати, вот и она:

function showRes(text) {
var res = $("#res");
res.empty();
res.html(text);
}

Как видно, она принимает текст, опустошает блок для вывода контента, и выводит в него то, что ей передали. Вот и все.

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

Запрет кэширования страницы на HTML

Сделать это можно с помощью мета тегов. Сейчас мы разберем разные варианты запрета на кэширование.

Запрет на кэширование браузером и прокси-сервером

Запрет кэширования страницы, только браузером

Установка кэширования на определенное время, для браузера

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

Установка кэширования на определенное время, для прокси-сервера

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

Запретить кэширование страницы с помощью PHP

Практически, все тоже самое, что в случае с HTML, только информацию будем выводить через header заголовки. Вот, как реализовать абсолютный запрет на кэш:

", date("H:i:s"), ""; ?>

Также, можно разрешать кэшировать на определенное время. Например, разрешим кэширование только на 1 час.

", date("H:i:s"), ""; ?>

Запретить кэширование страницы с помощью.htaccess

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

LoadModule expires_module modules/mod_expires.so LoadModule headers_module modules/mod_headers.so ... AddModule mod_expires.c AddModule mod_headers.c

Теперь в файле.htaccess, собственно запрещаем кэшировать выводимые данные. Как нам известно, .htaccess файл будет распространяться на директорию, в которой лежит, и на все субдиректории.

# Заголовок Cache-Control Header append Cache-Control "no-store, no-cache, must-revalidate" # Заголовок Expires ExpiresActive On ExpiresDefault "now"

Важно заметить, что полный запрет кэширования, повышает нагрузку на сервер. Поэтому, играйтесь с этим осторожно! А лучше, установите определенное время, на которое можно кэшировать документы. Например, установим кэширование на 1 час:

# Заголовок Cache-Control Header append Cache-Control "public" # Заголовок Expires ExpiresActive On ExpiresDefault "access plus 1 hours"

Заключение

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

В рамках этой статьи мы попытаемся разобраться с клиентским кэшированием. В частности, разберемся с тем, какие http-заголовки используются браузерами и веб-серверами и что они значат.

Но для начала давайте выясним, зачем вообще нужно кэширование на стороне клиента? .

Веб-страницы состоят из множества различных элементов: картинок, css и js файлов и т.п. Часть этих элементов используются на нескольких (многих) страницах сайта. Под клиентским кэшированием понимают способность браузеров сохранять копии файлов (ответов сервера), чтобы не загружать их повторно. Это позволяет значительно ускорить повторную загрузку страниц, сэкономить на трафике, а также снизить нагрузку на сервер.

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

Http заголовки для управления клиентским кэшированием

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

Без кэша (при отсутствии кэширующих http-заголовков)

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

Заголовок ответа Last-modified и заголовок запроса if-Modified-Since .

Идея заключается в том, что сервер добавляет заголовок Last-modified к файлу (ответу), который он отдает браузеру.

Теперь браузер знает, что файл был создан (или изменен) 1 декабря 2014. В следующий раз, когда браузеру понадобится тот же файл, он отправит запрос с заголовком if-Modified-Since .

Если файл не изменялся, сервер отправляет браузеру пустой ответ со статусом 304 (Not Modified) . В этом случае, браузер знает, что файл не обновлялся и может отобразить копию, которую он сохранил в прошлый раз.

Таким образом, используя Last-modified мы экономим на загрузке большого файла, отделываясь пустым быстрым ответом от сервера.

Заголовок ответа Etag и заголовок запроса If-None-Match .

Принцип работы Etag очень схож с Last-modified , но, в отличии от него, не привязан ко времени. Время – вещь относительная.

Идея заключается в том, что при создании и каждом изменении сервер помечает файл особой меткой, называемой ETag , а также добавляет заголовок к файлу (ответу), который он отдает браузеру:

ETag: "686897696a7c876b7e"

Теперь браузер знает, что файл актуальной версии имеет ETag равный “686897696a7c876b7e”. В следующий раз, когда брузеру понадобится тот же файл, он отправит запрос с заголовком If-None-Match: "686897696a7c876b7e" .

If-None-Match: "686897696a7c876b7e"

Сервер может сравнить метки и, в случае, если файл не изменялся, отправить браузеру пустой ответ со статусом 304 (Not Modified) . Как и в случае с Last-modified браузер выяснит, что файл не обновлялся и сможет отобразить копию из кэша.

Заголовок Expired

Принцип работы этого заголовка отличается от вышеописанных Etag и Last-modified . При помощи Expired определяется “срок годности” (“срок акуальности”) файла. Т.е. при первой загрузке сервер дает браузеру знать, что он не планирует изменять файл до наступления даты, указанной в Expired:

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

Такой вид кэша особенно актуален для иллюстраций к статьям, иконкам, фавиконкам, некоторых css и js файлов и тп.

Заголовок Cache-control с директивой max-age .

Принцип работы Cache-control: max-age очень схож с Expired . Здесь тоже определяется “срок годности” файла, но он задается в секундах и не привязан к конкретному времени, что намного удобнее в большинстве случаев.

Для справки:

• 1 день = 86400 секунд
• 1 неделя = 604800 секунд
• 1 месяц = 2629000 секунд
• 1 год = 31536000 секунд

К примеру:

Cache-Control: max-age=2629000;

У заголовка Cache-control , кроме max-age , есть и другие директивы. Давайте коротко рассмотрим наиболее популярные:

public
Дело в том, что кэшировать запросы может не только конечный клиент пользователя (браузер), но и различные промежуточные прокси, CDN-сети и тп. Так вот, директива public позволяет абсолютно любым прокси-серверам осуществлять кэширование наравне с браузером.

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

Позволяет указать, что клиент должен делать запрос на сервер каждый раз. Иногда используется с заголовком Etag , описанным выше.

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

must-revalidate
Эта директива предписывает браузеру делать обязательный запрос на сервер для ре-валидации контента (например, если вы используете eTag). Дело в том, что http в определенной конфигурации позволяет кэшу хранить контент, который уже устарел. must-revalidate обязывает браузер при любых условиях делать проверку свежести контента путем запроса к серверу.

proxy-revalidate
Это то же, что и must-revalidate , но касается только кэширующих прокси серверов.

s-maxage
Практически не отличается от мах-age , за исключением того, что эта директива учитывается только кэшем резличных прокси, но не самим браузером пользователя. Буква “s -” исходит из слова “s hared” (например, CDN). Эта директива предназначена специально для CDN-ов и других посреднических кэшей. Ее указание отменяет значения директивы max-age и заголовка Expired . Впрочем, если вы не строите CDN-сети, то s-maxage вам вряд ли когда-либо понадобится.

Как посмотреть, какие заголовки используются на сайте?

Вы можете посмотреть заголовки http-запросов (request headers) и ответов (response headers) в отладчике Вашего любимого браузера. Вот например, как это выглядит в хроме:

То-же самое можно увидеть в любом уважающем себя браузере или http-сниффере.

Настройка кэшировения в Аpache и Nginx

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

Пример конфигурации Apache для контроля Expires

Выставляем различный “срок годности” для различных типов файлов. Один год для изображений, один месяц для скриптов, стилей, pdf и иконок. Для всего остального – 2 дня.

ExpiresActive On ExpiresByType image/jpg "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType image/png "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType application/pdf "access plus 1 month" ExpiresByType text/x-javascript "access plus 1 month" ExpiresByType image/x-icon "access plus 1 year" ExpiresDefault "access plus 2 days"

Пример конфигурации Nginx для контроля Expires

Выставляем различный “срок годности” для различных типов файлов. Одна неделя – для изображений, один день – для стилей и скриптов.

Server { #... location ~* \.(gif|ico|jpe?g|png)(\?+)?$ { expires 1w; } location ~* \.(css|js)$ { expires 1d; } #... }

Пример конфигурации Apache для Cache-control (max-age и public/private/no-cache)

Header set Cache-Control "max-age=2592000, public" Header set Cache-Control "max-age=88000, private, must-revalidate" Header set Cache-Control "private, no-store, no-cache, must-revalidate, no-transform, max-age=0" Header set Pragma "no-cache"

Пример конфигурации Nginx для Cache-control статических файлов

server { #... location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { add_header Cache-Control "max-age=88000, public"; } #... }

В заключение

“Кэшировать все то, что можно кэшировать” – хороший девиз для веб-разработчика. Иногда можно потратить всего несколько часов на конфигурацию и при этом значительно улучшить восприятие вашего сайта пользователем, значительно сократить нагрузку на сервер и сэкономить на трафике. Главное – не переусердствовать и настроить все правильно с учетом особенностей Вашего ресурса.

Возникают ситуации, когда нам требуется довольно часто дергать какой-либо DOM элемент (например, с помощью querySelector). Но к сожалению, этот метод довольно прожорливый и из-за него очень сильно падает производительность. Или, например, нужно часто делать тяжелые запросы на сервер в рамках одной сессии. Либо же пользоваться функциями, которые долго что-то считают.

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

Function cache(key, value) { if (typeof value == "undefined") { return cache; } cache = value; }

Теперь на примерах рассмотрим как будет вести себя написанная выше функция cache.

Пример 1. Кэширование querySelector

// _io_q - обертка под querySelector, сохраняющая данные в кэш _io_q = function(selector) { if (!cache(selector)) { cache(selector, document.querySelector(selector)); } return cache(selector); }

Теперь посмотрим на скорость работы _io_q и querySelector:

Console.time("regular querySelector"); for (var i = 0; i < 1000000; i++) { document.querySelector("h1"); } console.timeEnd("regular querySelector"); // regular querySelector: 100.6123046875ms console.time("cached _io_q"); for (var i = 0; i < 1000000; i++) { _io_q("h1"); } console.timeEnd("cached _io_q"); // cached _io_q: 5.77392578125ms

Пример 2. Кэширование запросов с сервера

Напишем функцию, которая отправляет очень тяжелый запрос на сервер:

Function longRequestToServer(params) { var key = params.endpoint + "_" + params.value; if (!cache(key)) { var result = 0; for (var i = 0; i < 999999999; i++) { result++; } cache(key, result); } return cache(key); }

Посмотрим как будет вести себя функция:

Console.time("first run"); longRequestToServer({ endpoint: "/loadExample", value: 10}); console.timeEnd("first run"); // first run: 1012.068115234375ms console.time("second run"); longRequestToServer({ endpoint: "/loadExample", value: 10}); console.timeEnd("second run"); // second run: 1.31884765625ms console.time("other request"); longRequestToServer({ endpoint: "/loadSomeOtherData", value: 15 }); console.timeEnd("other request"); // other request: 1033.783203125ms

TL;DR

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

В HTML5 стало возможным создавать веб-приложения, которые будут работать даже без подключения к интернету.

Усовершенствованное кэширование страниц

Обратите внимание: IE10+, Chrome, Firefox, Opera и Safari имеют поддержку данной технологии.

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

Использование HTML5 кэширования дает следующие преимущества:

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

Пример использования HTML5 кэширования

...Содержимое документа...

Декларирование HTML5 кэширования

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

Если данный атрибут не был задан на веб-странице и ссылка на нее отсутствует в файле кэширования, страница не будет кэширована.

Файл кэширования может иметь любое расширение (например.appcache или.mf), но обязан иметь специальный MIME тип: "text/cache-manifest".

В некоторых случаях веб-серверу может потребоваться дополнительная настройка, чтобы обслуживать данный MIME тип. Например, чтобы настроить веб-сервер Apache необходимо добавить следующий код в.htaccess файл:

AddType text/cache-manifest .appcache

Содержимое файла кэширования

Файл кэширования является обычным текстовым файлом, который указывает браузеру какие файлы необходимо кэшировать.

Файл может содержать три секции:

• CACHE MANIFEST - в данной секции указываются ссылки на файлы, которые необходимо кэшировать. Браузер будет автоматически кэшировать все перечисленные файлы сразу после первой загрузки.
• NETWORK - в данной секции указываются файлы, которые требуют постоянного подключения к интернету. Браузер не будет кэшировать файлы перечисленные в данной секции.
• FALLBACK - если файлы указанные в этой секции будут по какой-либо причине будут недоступны пользователи автоматически будут перенаправляться на другой указанный файл.

Секция CACHE MANIFEST обязательно должна присутствовать во всех файлах кэширования. Секции NETWORK и FALLBACK могут отсутствовать.

Пример файла кэширования:

CACHE MANIFEST #В данной секции перечислены файлы, которые будут кэшированы index.html flower.png NETWORK #Здесь перечислены файлы, которые требуют подключение к интернету login-page.php FALLBACK #Если mob.html недоступен пользователь будет перенаправлен на offline.html /mob.html /offline.html #Если какой-либо из HTML файлов недоступен пользователь будет перенаправлен на offline.html *.html /offline.html

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

Обратите внимание: некоторые браузеры могут иметь ограничение на размер кэшируемого содержимого на одном сайте.

Обновление кэшированных файлов

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

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

• Очистить кэш в браузере пользователя
• Обновить содержимое файла кэширования
• Обновить кэш браузера программно (с помощью JavaScript)

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