llm-wiki/raw/official-docs/mdn-storage-quotas-eviction-persistence.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title	source_type	url	archive_url	related_branches	related_projects	tags	created
MDN — Storage quotas and eviction criteria / StorageManager.persist()	official-doc	https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria		feature-frontend-binary-file-io-store-contract feature-frontend-large-object-transfer-contract feature-frontend-cache-tier-cross-tab-invalidation-contract	ca-skeleton-frontend	frontend storage indexeddb opfs cache-storage quota browser	2026-07-28

MDN — Storage quotas and eviction criteria / StorageManager.persist()

Layer: raw/ — 외부 자료의 원문 발췌·출처 기록.

활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
[[raw/branch-notes/feature-frontend-binary-file-io-store-contract]]	BlobStorePort 의 quota 실패 매핑, eviction 정책, evictionOrder 필드의 실제 적용 범위
[[raw/branch-notes/feature-frontend-large-object-transfer-contract]]	UPLOAD_PART_STATE 를 재개 가능 전송의 correctness 값으로 유지할 수 있는지의 조건
[[raw/branch-notes/feature-frontend-cache-tier-cross-tab-invalidation-contract]]	영속 캐시 tier 가 브라우저 eviction 에 노출되는 범위

출처

• 원본 URL: https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria
• 보조 URL: https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist
• 아카이브 URL:
• 저자 / 조직: MDN Web Docs (Mozilla)
• 발행일: (문서 지속 갱신)
• 마지막 확인일: 2026-07-28

왜 저장했는지

ca-skeleton-frontend 의 FE-REG-STORAGE 가 quotaFallback·evictionOrder 필드를 정의했는데, 그 필드가 브라우저 eviction 에도 적용되는지 확인이 필요했다. 결과적으로 브라우저 eviction 은 origin 단위 전량 삭제라 per-key 순서가 적용되지 않는다는 사실을 확인했고, 이는 FE-D027·FE-D030 의 전제를 바꾼다.

핵심 인용

[§Storage limits — Firefox] "In Firefox, the maximum storage space an origin can use in best-effort mode is whichever is the smaller of: 10% of the total disk size where the profile of the user is stored. Or 10 GiB, which is the group limit that Firefox applies to all origins that are part of the same site."

[§Storage limits — Chromium] "In browsers based on the Chromium open-source project, including Chrome and Edge, an origin can store up to 60% of the total disk size in both persistent and best-effort modes."

[§Storage limits — Web Storage] "Web Storage, which can be accessed by using the localStorage and sessionStorage properties of the window object, is limited to 10 MiB of data maximum on all browsers."

[§Storage limits — Web Storage] "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin."

[§Eviction] "Browsers use a Least Recently Used (LRU) policy to deal with this scenario. The data from the least recently used origin is deleted. If storage pressure continues, the browser moves on to the second least recently used origin, and so on, until the problem is resolved."

[§Eviction] "When an origin's data is evicted by the browser, all of its data, not parts of it, is deleted at the same time. If the origin had stored data by using IndexedDB and the Cache API for example, then both types of data are deleted."

[§Eviction] "This eviction mechanism only applies to origins that are not persistent and skips over origins that have been granted data persistence by using navigator.storage.persist()."

[§Eviction — Safari] "Safari proactively evicts data when cross-site tracking prevention is turned on. If an origin has no user interaction, such as click or tap, in the last seven days of browser use, its data created from script will be deleted."

[§Persistence] "Best-effort: this is the way that data is stored by default. Best-effort data persists as long as the origin is below its quota, the device has enough storage space, and the user doesn't choose to delete the data via their browser's settings."

[§Persistence] "Persistent: an origin can opt-in to store its data in a persistent way. Data stored this way is only evicted, or deleted, if the user chooses to, by using their browser's settings."

[§StorageManager.persist] "The persist() method of the StorageManager interface requests permission to use persistent storage, and returns a Promise that resolves to true if permission is granted and bucket mode is persistent, and false otherwise."

[§StorageManager.persist] "The browser may or may not honor the request, depending on browser-specific rules."

추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
C1	브라우저 eviction 은 origin 단위로 전량 삭제하며 일부만 지우지 않는다	[§Eviction] "all of its data, not parts of it, is deleted at the same time"	official-reference	best-effort 모드의 모든 origin-partitioned storage	애플리케이션이 스스로 수행하는 선택적 정리까지 금지한다는 뜻은 아님
C2	IndexedDB 와 Cache API 는 같은 eviction 단위에 속해 함께 삭제된다	[§Eviction] "If the origin had stored data by using IndexedDB and the Cache API for example, then both types of data are deleted"	official-reference	IndexedDB · Cache API · File System API(OPFS)	각 API 의 개별 quota 가 존재한다는 뜻은 아님
C3	eviction 은 LRU origin 순서로 일어난다	[§Eviction] "Browsers use a Least Recently Used (LRU) policy... The data from the least recently used origin is deleted"	official-reference	best-effort origin	origin 내부의 key 우선순위를 브라우저가 존중한다는 뜻은 아님
C4	navigator.storage.persist() 로 허가받은 origin 은 LRU eviction 대상에서 제외된다	[§Eviction] "skips over origins that have been granted data persistence by using navigator.storage.persist()"	official-reference	허가가 실제로 부여된 origin	요청하면 항상 허가된다는 뜻은 아님
C5	persist 요청의 허가 여부는 브라우저 재량이며 boolean 으로 반환된다	[§StorageManager.persist] "The browser may or may not honor the request, depending on browser-specific rules."	official-reference	모든 지원 브라우저	특정 브라우저의 허가 조건이 무엇인지
C6	Web Storage(localStorage/sessionStorage)는 origin 당 5 MiB 수준이며 IndexedDB 계열과 별도 한도를 가진다	[§Storage limits] "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin."	official-reference	모든 브라우저	Web Storage 가 eviction 에서 제외된다는 뜻은 아님
C7	Safari 는 cross-site tracking prevention 활성 시 7일간 사용자 상호작용이 없으면 script 로 만든 데이터를 삭제한다	[§Eviction — Safari] "If an origin has no user interaction... in the last seven days of browser use, its data created from script will be deleted."	official-reference	Safari + ITP 활성	다른 브라우저도 같은 정책을 쓴다는 뜻은 아님

적용 경계

• 이 자료가 직접 증명하는 것:
  • C1~C3: 브라우저 주도 eviction 의 단위와 순서
  • C4·C5: persist() 의 효과와 불확실성
• 이 자료가 증명하지 않는 것:
  • 애플리케이션이 quota 압박 시 스스로 어떤 순서로 정리해야 하는지 — 그건 제품 결정이다
  • 특정 브라우저가 persist 를 허가하는 구체 조건
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • UPLOAD_PART_STATE 가 재개 가능 전송에 실제로 충분히 오래 살아남는지 (Safari 7일 규칙 + persist 미허가 조합)

메모

• 인용 1 해석 후보 (미검증): FE-REG-STORAGE.evictionOrder 는 애플리케이션 주도 정리 순서로만 유효하다. 브라우저 eviction 에는 적용되지 않으므로 필드 설명에 그 경계를 명시해야 한다.
• 추가로 봐야 할 동일 출처 페이지: StorageManager.estimate(), navigator.storage.persisted()

관련

• 같은 주제 다른 official-doc: [[raw/official-docs/mdn-file-system-access-opfs]], [[raw/official-docs/mdn-object-url-cache-storage]]
• 이 자료를 인용한 wiki 요약: 생성 전