--- title: Использование кэширования приложений slug: Web/HTML/Использование_кэширования_приложений translation_of: Web/HTML/Using_the_application_cache ---

Введение

HTML5 предоставляет механизм кэширования приложения, позволяющий веб-приложениям работать в автономном режиме. Разработчики теперь могут использовать интерфейс Кэша приложения (AppCache), сообщая браузеру, какие из ресурсов браузеру следует закэшировать и сделать доступными в режиме оффлайн. Закэшированные приложения загружаются и работают корректно, даже если пользователь обновляет страницу в тот момент, когда он отключён от сети.

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

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

Как работает кэш приложения

Включение механизма кэширования

Для включения механизма кэширования приложения вам необходимо включить атрибут {{htmlattrxref("manifest", "html")}} в элемент {{HTMLElement("html")}} на странице вашего приложения, как показано примере ниже:

<html manifest="example.appcache">
  ...
</html>

Атрибут manifest ссылается на файл манифеста кэша, который является текстовым файлом и содержит список ресурсов (файлов), которые браузеру следует закэшировать для вашего приложения.

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

Некоторые браузеры (например, Firefox) показывают панель уведомлений , когда пользователь загружает использующее кэш приложение в первый раз. Панель уведомлений может показывать примерно такое сообщение::

Этот веб-сайт (www.example.com) запрашивает у вас разрешение на хранение данных для автономной работы на вашем компьютере. [Разрешить] [Никогда для этого сайта] [Не сейчас]

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

Загрузка документов

Использование кэша приложений изменяет обычный процесс загрузки документа:

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

Ниже приведено более подробное описание процесса загрузки документов и обновления кэша приложения:

Когда браузер посещает страницу со включенным атрибутом manifest и кэша приложения не существует, браузер загружает документ, а затем получает все пункты файла манифеста, создавая тем самым первую версию кэша приложения.
Последующие посещения данной страницы приводят к загрузке документа и других ресурсов, указанных в файле манифеста, уже из кэша приложения (не с сервера). К тому же браузер также посылает событие checking объекту window.applicationCache и получает файл манифеста в соответствии с правилами кэширования HTTP.
Если текущая закэшированная копия манифеста совпадает со скачанной, браузер посылает событие noupdate объекту applicationCache, завершая процесс обновления. Обратите внимание, если вы изменили закэшированные ресурсы на стороне сервера, вам также необходимо изменить и файл манифеста, тем самым давая браузеру знать, какие из ресурсов нужно получить повторно.
Если файл манифеста изменился, то все перечисленные в нём файлы, так же, как и добавленные в кэш с помощью вызова applicationCache.add(), попадают во временный кэш с учётом правил кэширования HTTP. Во время обновления каждого файла в этом временном кэше браузер посылает событие progress объекту applicationCache. Если происходит ошибка, браузер посылает событие error, а обновление прекращается.
Как только успешно получены все файлы, они автоматически отправляются в настоящий оффлайн-кэш, а объекту applicationCache посылается событие cached. Поскольку документ уже был загружен в браузер из кэша, обновлёный документ не перерисуется, пока страница не будет перезагружена (неважно как, вручную или программно).

Место хранения и очистка оффлайн-кэша

В Chrome оффлайн-кэш можно очистить, выбрав «Очистить историю...» в настройках или перейдя на адрес chrome://appcache-internals/. У Safari также есть похожий пункт «Очистить кэш» в настройках, но для этого также может понадобиться перезапуск браузера.

Firefox хранит данные оффлайн-кэша отдельно от профиля — по соседству с обычным дисковым кэшем:

В Windows Vista/7: C:\Users\<пользователь>\AppData\Local\Mozilla\Firefox\Profiles\<соль>.<имя профиля>\OfflineCache
В Mac/Linux: /Users/<пользователь>/Library/Caches/Firefox/Profiles/<соль>.<имя профиля>/OfflineCache

Текущее состояние оффлайн-кэша в Firefox можно посмотреть на странице about:cache (в разеделе «Offline cache device»). Оффлайн-кэш можно очистить по отдельности для каждого сайта, используя кнопку «Удалить...» в разделе Инструменты -> Настройки -> Дополнительные -> Сеть -> Автономное содержимое.

До Firefox 11 кэш нельзя было очистить ни кнопкой Инструменты -> Удалить недавнюю историю, ни Инструменты -> Настройки -> Дополнительные -> Сеть -> Автономное содержимое -> Очистить сейчас. Сейчас эта проблема устранена.

В Linux настройки оффлайн-кэша можно найти в разделе Инструменты -> Настройки -> Дополнительные -> Сеть -> Автономное содержимое и данные пользователя

См. также очистка данных хранилища DOM.

Также кэши приложения могут устареть. Если с сервера удалить файл манифеста, браузер удалит все кэши, которые были в нём указаны, и пошлёт событие obsoleted объекту applicationCache, что установит состояние кэша в OBSOLETE.

Файл манифеста кэша

Ссылки на файл манифеста кэша

Атрибут manifest может модержать как относительный путь, так и абсолютный URL (который должен соответствовать принципу единого источника) к файлу манифеста. Файл манифеста кэша может иметь любое расширение, но его MIME- тип должен быть text/cache-manifest.

Примечание: На серверах Apache MIME-тип файлов манифеста (.appcache) можно настроить, добавив строчку AddType text/cache-manifest .appcache в файл .htaccess в корневой директории или же директории приложения.

Пункты манифеста кэша

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

Пример 1: простой файл манифеста кэша

Ниже приведено содержимое простого файла манифеста кэша для воображаемого веб-сайта www.example.com.

CACHE MANIFEST
# v1 - 2011-08-13
# Это комментарий.
http://www.example.com/index.html
http://www.example.com/header.png
http://www.example.com/blah/blah

Манифест кэша может включать три секции (CACHE, NETWORK и FALLBACK, которые будут рассмотрены далее). В приведённом примере нет заголовков секций, поэтому предполагается, что все строчки находятся в явной секции CACHE, подразумевая, что все указанные в них ресурсы браузеру следует сохранить в кэше приложения. Ресурсы могут быть указаны с использованием как абсолютных, так и относительных URL (например, index.html).

Для наличия в кэше комментария «v1» есть веские основания. Браузер обновляет кэш приложения, только если изменён файл манифеста, хотя бы один байт в нём. Если вы изменяете закэшированный ресурс на стороне сервера, (например, при обновлении содержимого картинки header.png), вы также должны изменить содержимое файла манифеста, тем самым сообщая браузеру, что нужно обновить кэш. Вы можете изменять файл манифеста так, как вам угодно, но лучшие практики рекомендуют использовать изменение номера пересмотра.

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

Sections in a cache manifest file: `CACHE`, `NETWORK`, and `FALLBACK`

A manifest can have three distinct sections: CACHE, NETWORK, and FALLBACK.

CACHE:: This is the default section for entries in a cache manifest file. Files listed under the CACHE: section header (or immediately after the CACHE MANIFEST line) are explicitly cached after they're downloaded for the first time.
NETWORK:: Files listed under the NETWORK: section header in the cache manifest file are white-listed resources that require a connection to the server. All requests to such resources bypass the cache, even if the user is offline. Wildcards may be used.
FALLBACK:: The FALLBACK: section specifies fallback pages the browser should use if a resource is inaccessible. Each entry in this section lists two URIs—the first is the resource, the second is the fallback. Both URIs must be relative and from the same origin as the manifest file. Wildcards may be used.

The CACHE, NETWORK, and FALLBACK sections can be listed in any order in a cache manifest file, and each section can appear more than once in a single manifest.

Example 2: a more complete cache manifest file

The following is a more complete cache manifest file for the imaginary web site at www.example.com:

CACHE MANIFEST
# v1 2011-08-14
# This is another comment
index.html
cache.html
style.css
image1.png

# Use from network if available
NETWORK:
network.html

# Fallback content
FALLBACK:
/ fallback.html

This example uses NETWORK and FALLBACK sections to specify that the network.html page must always be retrieved from the network, and that the fallback.html page should be served as a fallback resource (e.g., in case a connection to the server cannot be established).

Structure of a cache manifest file

Cache manifest files must be served with the text/cache-manifest MIME type. All resources served using this MIME type must follow the syntax for an application cache manifest, as defined in this section.

Cache manifests are UTF-8 format text files, and may optionally include a BOM character. Newlines may be represented by line feed (U+000A), carriage return (U+000D), or carriage return and line feed both.

The first line of the cache manifest must consist of the string CACHE MANIFEST (with a single U+0020 space between the two words), followed by zero or more space or tab characters. Any other text on the line is ignored.

The remainder of the cache manifest must be comprised of zero or more of the following lines:

Blank line: You may use blank lines comprised of zero or more space and tab characters.
Comment: Comments consist of zero or more tabs or spaces followed by a single # character, followed by zero or more characters of comment text. Comments may only be used on their own lines (after the initial CACHE MANIFEST line), and cannot be appended to other lines. This means that you cannot specify fragment identifiers.
Section header: Section headers specify which section of the cache manifest is being manipulated. There are three possible section headers:

Section header Description

CACHE: Switches to the explicit section of the cache manifest (this is the default section).

NETWORK: Switches to the online whitelist section of the cache manifest.

FALLBACK: Switches to the fallback section of the cache manifest.

Section header	Description
`CACHE:`	Switches to the explicit section of the cache manifest (this is the default section).
`NETWORK:`	Switches to the online whitelist section of the cache manifest.
`FALLBACK:`	Switches to the fallback section of the cache manifest.

The section header line may include whitespaces, but must include the colon (:) in the section name.
Section data: The format for lines of data varies from section to section. In the explicit (CACHE:) section, each line is a valid URI or IRI reference to a resource to cache (no wildcard characters are allowed in this sections). Whitespace is allowed before and after the URI or IRI on each line. In the Fallback section each line is a valid URI or IRI reference to a resource, followed by a fallback resource that is to be served up when a connection with the server cannot be made. In the network section, each line is a valid URI or IRI reference to a resource to fetch from the network (the wildcard character * is allowed in this section).

Note: Relative URIs are relative to the cache manifest's URI, not to the URI of the document referencing the manifest.

Cache manifest files can switch from section to section at will (each section header can be used more than once), and sections are allowed to be empty.

Resources in an application cache

An application cache always includes at least one resource, identified by URI. All resources fit into one of the following categories:

Master entries: These are resources added to the cache because a browsing context visited by the user included a document that indicated that it was in this cache using its manifest attribute.
Explicit entries: These are resources explicitly listed in the application's cache manifest file.
Network entries: These are resources listed in the application's cache manifest files as network entries.
Fallback entries: These are resources listed in the application's cache manifest files as fallback entries.

Note: Resources can be tagged with multiple categories, and can therefore be categorized as multiple entries. For example, an entry can be both an explicit entry and a fallback entry.

Resource categories are described in greater detail below.

Master entries

Master entries are any HTML files that include a {{htmlattrxref("manifest","html")}} attribute in their {{HTMLElement("html")}} element. For example, let's say we have the HTML file http://www.example.com/entry.html, which looks like this:

<html manifest="example.appcache">
  <h1>Application Cache Example</h1>
</html>

If entry.html is not listed in the example.appcache cache manifest file, visiting the entry.html page causes entry.html to be added to the application cache as a master entry.

Explicit entries

Explicit entries are resources that are explicitly listed in the CACHE section of a cache manifest file.

Network entries

The NETWORK section of a cache manifest file specifies resources for which a web application requires online access. Network entries in an application cache are essentially an "online whitelist"—URIs specified in the NETWORK section are loaded from the server instead of the cache. This lets the browser's security model protect the user from potential security breaches by limiting access to approved resources.

As an example, you can use network entries to load and execute scripts and other code from the server instead of the cache:

CACHE MANIFEST
NETWORK:
/api

The cache manifest section listed above ensures that requests to load resources contained in the http://www.example.com/api/ subtree always go to the network without attempting to access the cache.

Note: Simply omitting master entries (files that have the manifest attribute set in the html element) from the manifest file would not have the same result, because master entries will be added—and subsequently served from—the application cache.

Fallback entries

Fallback entries are used when an attempt to load a resource fails. For example, let's say the cache manifest file http://www.example.com/example.appcache includes the following content:

CACHE MANIFEST
FALLBACK:
example/bar/ example.html

Any request to http://www.example.com/example/bar/ or any of its subdirectories and their content cause the browser to issue a network request to attempt to load the requested resource. If the attempt fails, due to either a network failure or a server error of some kind, the browser loads the file example.html instead.

Cache states

Each application cache has a state, which indicates the current condition of the cache. Caches that share the same manifest URI share the same cache state, which can be one of the following:

UNCACHED: A special value that indicates that an application cache object is not fully initialized.
IDLE: The application cache is not currently in the process of being updated.
CHECKING: The manifest is being fetched and checked for updates.
DOWNLOADING: Resources are being downloaded to be added to the cache, due to a changed resource manifest.
UPDATEREADY: There is a new version of the application cache available. There is a corresponding updateready event, which is fired instead of the cached event when a new update has been downloaded but not yet activated using the swapCache() method.
OBSOLETE: The application cache group is now obsolete.

Testing for updates to the cache manifest

You can programmatically test to see if an application has an updated cache manifest file, using JavaScript. Since a cache manifest file may have been updated before a script attaches event listeners to test for updates, scripts should always test window.applicationCache.status.

function onUpdateReady() {
  alert('found new version!');
}
window.applicationCache.addEventListener('updateready', onUpdateReady);
if(window.applicationCache.status === window.applicationCache.UPDATEREADY) {
  onUpdateReady();
}

To manually start testing for a new manifest file, you can use window.applicationCache.update().

Gotchas

Never access cached files by using traditional GET parameters (like other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network. To link to cached resources that have parameters parsed in JavaScript use parameters in the hash part of the link, such as other-cached-page.html#whatever?parameterName=value.
When applications are cached, simply updating the resources (files) that are used in a web page is not enough to update the files that have been cached. You must update the cache manifest file itself before the browser retrieves and uses the updated files. You can do this programmatically using window.applicationCache.swapCache(), though resources that have already been loaded will not be affected. To make sure that resources are loaded from a new version of the application cache, refreshing the page is ideal.
It's a good idea to set expires headers on your web server for *.appcache files to expire immediately. This avoids the risk of caching manifest files. For example, in Apache you can specify such a configuration as follows:
ExpiresByType text/cache-manifest "access plus 0 seconds"

Browser compatibility

Feature	Chrome	Firefox (Gecko)	Internet Explorer	Opera	Safari
Basic support	4.0	3.5	10.0	10.6	4.0

Feature	Android	Firefox Mobile (Gecko)	IE Mobile	Opera Mobile	Safari Mobile
Basic support	2.1	{{CompatVersionUnknown}}	{{CompatNo}}	11.0	3.2

Note: Versions of Firefox prior to 3.5 ignore the NETWORK and FALLBACK sections of the cache manifest file.