Квоты хранилища и критерии удаления

Веб-разработчики могут использовать ряд технологий для хранения данных в браузере пользователя (то есть на локальном диске устройства, которое пользователь использует для просмотра веб-сайта).

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

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

Браузеры хранят данные с веб-сайтов в разных местах, также называемых «вёдрами», чтобы снизить риск отслеживания пользователей по сети. В большинстве случаев браузеры управляют хранимыми данными по происхождению.

Поэтому важно понимать термин происхождение в этой статье. Происхождение определяется схемой (например, HTTPS), именем хоста и портом. Например, https://example.com и https://example.com/app/index.html принадлежат к одному происхождению, потому что у них одинаковая схема (https), имя хоста (example.com) и стандартный порт.

Квоты и критерии удаления, описанные в этой статье, применяются к всему происхождению, даже если это происхождение используется для запуска нескольких веб-сайтов, таких как https://example.com/site1/ и https://example.com/site2/.

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

Веб-разработчики могут использовать следующие веб-технологии для хранения данных в браузере:

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

Данные для происхождения могут храниться в браузере двумя способами: постоянно и с наименьшими затратами:

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

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

Если по какой-либо причине разработчикам требуется постоянное хранилище (например, при создании веб-приложения, которое полагается на критически важные данные, не сохраненные нигде еще), они могут сделать это, используя метод navigator.storage.persist() API хранения.

В Firefox, когда сайт выбирает использование постоянного хранилища, пользователю отображается всплывающее окно UI, запрашивающее разрешение.

Safari и большинство браузеров на основе Chromium, таких как Chrome или Edge, автоматически одобряют или отклоняют запрос на основе истории взаимодействия пользователя с сайтом и не показывают никаких запросов пользователю.

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

Обратите внимание, что в режиме приватного просмотра (также называемом «Инкогнито» в Chrome и «Инкогнито» в Edge) браузеры могут применять разные квоты, а хранимые данные обычно удаляются при завершении режима приватного просмотра.

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

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

Веб-хранилище, к которому можно получить доступ, используя свойства localStorage и sessionStorage объекта window, ограничено максимум 10 МБ данных во всех браузерах.

Браузеры могут хранить до 5 МБ локального хранилища и 5 МБ сеансового хранилища на происхождение.

Когда этот предел достигнут, браузеры выбрасывают исключение QuotaExceededError, которое необходимо обрабатывать с помощью блока try...catch.

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

Эта система регулирует все данные, которые происхождение хранит с помощью этих API.

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

Firefox

В Firefox максимальный объем хранилища, который может использовать происхождение в режиме наименьших затрат, — это меньшее из:

• 10% от общего размера диска, где хранится профиль пользователя.
• Или 10 ГБ, что является групповым лимитом, который Firefox применяет ко всем происхождениям, которые являются частью одного домена eTLD+1.

Происхождения, которым разрешено постоянное хранилище, могут хранить до 50% от общего размера диска, с максимальным значением 8 ТБ, и не ограничены групповым лимитом eTLD+1.

Например, если устройство имеет жесткий диск объемом 500 ГБ, Firefox позволит происхождению хранить до:

• В режиме наименьших затрат: 10 ГБ данных, что является групповым лимитом eTLD+1.
• В режиме постоянного хранения: 250 ГБ, что составляет 50% от общего размера диска.

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

Chrome и браузеры на основе Chromium

В браузерах на основе открытого проекта Chromium, включая Chrome и Edge, происхождение может хранить до 60% от общего размера диска как в режиме наименьших затрат, так и в режиме постоянного хранения.

Например, если устройство имеет жесткий диск объемом 1 ТБ, браузер позволит происхождению использовать до 600 ГБ.

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

Safari

Начиная с macOS 14 и iOS 17, Safari выделяет до примерно 20% от общего дискового пространства для каждого происхождения. Если пользователь сохранил его как веб-приложение на главном экране или в доке, этот лимит увеличивается до 60% размера диска. По соображениям безопасности, фреймы разных происхождений имеют отдельную квоту, составляющую примерно 1/10 от квоты родительского происхождения.

Например, устройство macOS с диском объёмом 1 ТБ будет ограничивать каждое происхождение примерно 200 ГБ. Если пользователь сохранит веб-приложение в доке, это будет иметь больший лимит — около 600 ГБ.

Как и в других браузерах, точные лимиты, применяемые к квоте, могут меняться, чтобы избежать отпечатков пальцев. Кроме того, Safari также применяет общую квоту, при которой объём данных, сохранённых по всем происхождениям, не может превысить 80% размера диска для каждого браузера и веб-приложения, и 15% размера диска для каждого приложения, которое не является браузером и отображает веб-контент. Более подробную информацию о политике хранения данных Safari можно найти на блоге WebKit.

В более ранних версиях Safari происхождению даётся начальная квота в 1 ГБ. После достижения этим происхождением этого предела Safari запрашивает у пользователя разрешение на хранение большего объёма данных. Это происходит независимо от того, хранит ли происхождение данные в режиме наименьших затрат или постоянном режиме.

Веб-разработчики могут проверить, сколько места доступно для своего источника и сколько места используется источником, с помощью метода navigator.storage.estimate() API хранилища.

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

Попытка сохранить больше, чем квота источника, используя IndexedDB, кэш или OPFS, например, завершается с исключением QuotaExceededError.

Веб-разработчики должны обернуть JavaScript-код, записывающий данные в хранилище браузера, в блоки try...catch. Также рекомендуется освободить место, удалив данные перед сохранением новых.

Удаление данных — это процесс, посредством которого браузер удаляет сохранённые данные источника.

Удаление данных может произойти в нескольких случаях:

• Когда на устройстве мало места, также известном как нагрузка на хранилище.
• Когда все данные, хранящиеся в браузере (всех источниках), превышают общее количество места, которое браузер готов использовать на устройстве.
• Проактивно, для источников, которые не используются регулярно, что происходит только в Safari.

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

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

Этот механизм удаления применим только к источникам, которые не являются постоянными, и пропускает источники, которым была предоставлена постоянность данных с помощью navigator.storage.persist().

Некоторые браузеры определяют максимальный объём хранилища, который они могут использовать на жёстком диске устройства. Например, Chrome в настоящее время использует не более 80% общего размера диска.

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

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

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

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

Удаление только части данных источника может привести к проблемам с согласованностью.

• Хранилище для веб-приложений на web.dev
• Постоянное хранилище на web.dev
• Концепции хранилища Chrome Web и квот