이 페이지는 Cloud Translation API를 통해 번역되었습니다.

웹용 스토리지

브라우저에 데이터를 저장하는 다양한 옵션이 있습니다. 가장 적합한 옵션은 무엇인가요?

Pete LePage

인터넷 연결은 이동 중에 불안정하거나 아예 없을 수 있습니다. 오프라인 지원과 안정적인 성능은 프로그레시브 웹 앱입니다. 완벽한 무선 환경 캐싱 및 기타 저장 기술을 신중하게 사용하면 사용자 환경이 크게 개선됩니다. 캐시하는 방법에는 여러 가지가 있습니다. 정적 애플리케이션 리소스 (HTML, 자바스크립트, CSS, 이미지 등)와 데이터 (사용자 데이터, 뉴스 기사 등)가 포함됩니다. 하지만 가장 좋은 해결책은 무엇일까요? 방법 얼마나 저장할 수 있을까요? 제거되지 않도록 하려면 어떻게 해야 하나요?

무엇을 사용해야 하나요?

리소스 저장을 위한 일반적인 권장사항은 다음과 같습니다.

앱과 파일 기반 콘텐츠를 로드하는 데 필요한 네트워크 리소스의 경우 Cache Storage API( 서비스 워커).
다른 데이터의 경우 IndexedDB( 프라미스 래퍼)

IndexedDB 및 Cache Storage API는 모든 최신 브라우저에서 지원됩니다. 둘 다 비동기적이며 기본 스레드를 차단하지 않습니다. 그들은 window 객체, 웹 작업자, 서비스 워커에서 액세스할 수 있어 코드 어디에서나 쉽게 사용할 수 있습니다.

다른 저장 메커니즘은 어떨까요?

브라우저에서 사용할 수 있는 여러 다른 저장 메커니즘이 있지만 사용이 제한되며 심각한 성능 문제가 발생할 수 있습니다.

SessionStorage는 탭마다 다르며 탭 수명입니다. 작은 양의 세션을 저장하고 특정 정보(예: IndexedDB 키) 동기식이며 기본 스레드를 차단하므로 주의하세요. 그것은 약 5MB로 제한되고 문자열만 포함할 수 있습니다. 탭마다 다르기 때문에 웹 작업자 또는 서비스 워커에서 액세스할 수 없습니다.

LocalStorage는 동기식이므로 사용하지 않아야 합니다. 기본 스레드를 차단합니다. 약 5MB로 제한되며 문자열만 있습니다. 웹 작업자 또는 서비스에서 로컬 스토리지에 액세스할 수 없음 있습니다

쿠키에는 용도가 있지만 저장소로 사용해서는 안 됩니다. 쿠키는 모든 HTTP 요청과 함께 전송되므로 데이터의 양이 적으면 모든 웹 요청의 크기가 크게 증가합니다. 이는 동기식이며 웹 작업자에서 액세스할 수 없습니다. 좋아요 LocalStorage 및 SessionStorage의 경우 쿠키는 문자열로만 제한됩니다.

File System API 및 FileWriter API는 샌드박스 파일 시스템에서 파일 읽기 및 쓰기 비동기식이지만 그것은 권장되지 않습니다 Chromium 기반 브라우저에서만 사용 가능

File System Access API는 사용자가 로컬 파일 시스템에서 파일을 쉽게 읽고 편집할 수 있습니다. 사용자 페이지가 로컬 파일을 읽거나 쓰기 전에 권한을 부여해야 합니다. 권한은 세션 간에 유지되지 않습니다.

WebSQL을 사용해서는 안 되며 기존 사용량은 IndexedDB. 거의 모든 주요 항목에서 지원이 삭제되었습니다. 있습니다. W3C는 2010년에 웹 SQL 사양 유지를 중단했습니다. 향후 업데이트 계획이 없습니다.

애플리케이션 캐시는 사용해서는 안 되며 기존 사용량도 Cache API로 마이그레이션할 수 있습니다 그랬습니다. 지원 중단되었으며 다음 국가의 브라우저에서 지원이 삭제될 예정입니다. 생각해 보세요

얼마나 저장할 수 있나요?

간단히 말해서 크게, 수백 MB 이상이며 잠재적으로는 수백 기가바이트 이상이 될 수 있습니다. 브라우저 구현은 다양하지만 사용 가능한 스토리지는 일반적으로 Compute Engine에서 사용하는 있습니다.

Chrome은 브라우저가 총 디스크 공간의 최대 80% 를 사용하도록 허용합니다. 출처는 총 디스크 공간의 최대 60% 를 사용합니다. StorageManager. API를 사용하여 사용 가능한 최대 할당량을 결정합니다. 기타 Chromium 기반 브라우저가 다를 수 있습니다
- 시크릿 모드를 사용하면 Chrome이 출처에서 사용할 수 있는 저장용량을 줄입니다. 전체 디스크 공간의 약 5% 가 될 것입니다
- 사용자가 '모두 닫을 때 쿠키 및 사이트 데이터 삭제'를 사용 설정한 경우 창문" Chrome에서는 저장용량이 최대 약 300MB입니다.
- 다음 경우에는 PR #3896을 참조하세요. 를 참조하세요.
Internet Explorer 10 이상에서는 최대 250MB까지 저장할 수 있으며 10MB 이상 사용 시 사용자에게 반환됩니다.
Firefox는 브라우저에서 사용 가능한 디스크 공간의 최대 50% 를 사용합니다. eTLD+1 그룹 (예: example.com, www.example.com, foo.bar.example.com) 최대 2GB까지 사용할 수 있습니다. 이 StorageManager API를 사용하여 아직 공간이 얼마나 남아 있는지 확인 있습니다.
Safari (데스크톱 및 모바일 모두)는 약 1GB를 허용하는 것으로 보입니다. 한도가 도달 시 Safari에서 사용자에게 메시지를 표시하여 200MB의 한도를 늘립니다. 증가하게 됩니다. 이와 관련된 공식 문서를 찾을 수 없습니다.
- PWA가 모바일 Safari의 홈 화면에 추가되면 새 저장소 컨테이너를 만들 때 PWA 간에 공유되는 것은 없습니다. 모바일 Safari에서 사용할 수 있습니다. 설치된 PWA의 할당량에 도달하면 추가 저장용량을 요청할 수 없는 것으로 보입니다.

이전에는 사이트가 일정 데이터 저장 한도를 초과하는 경우 브라우저는 사용자에게 추가 데이터를 사용할 권한을 부여하라는 메시지를 표시합니다. 대상 예를 들어 원본에서 50MB 이상을 사용하면 브라우저에서 사용자에게 최대 100MB까지 저장할 수 있도록 한 다음 50MB 단위로 다시 요청합니다.

오늘날 대부분의 최신 브라우저는 사용자에게 메시지를 표시하지 않으며, 할당된 할당량까지 사용할 수 있습니다 단, Safari는 예외인 것 같습니다. 저장용량 한도를 초과하면 요청 메시지를 표시하고 할당량으로 확장할 수 있습니다 출처가 할당된 할당량을 초과하여 사용하려고 하면 추가 데이터 쓰기를 시도합니다. 실패합니다

사용 가능한 저장용량을 확인하려면 어떻게 해야 하나요?

많은 브라우저에서 StorageManager API: 저장용량 확인 사용 중인 스토리지의 양을 결정합니다 이 측정항목은 IndexedDB 및 Cache API에서 사용하는 바이트 수를 계산하며 대략적인 남은 저장공간을 계산합니다.

if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate();
  // quota.usage -> Number of bytes used.
  // quota.quota -> Maximum number of bytes available.
  const percentageUsed = (quota.usage / quota.quota) * 100;
  console.log(`You've used ${percentageUsed}% of the available storage.`);
  const remaining = quota.quota - quota.usage;
  console.log(`You can write up to ${remaining} more bytes.`);
}

StorageManager는 아직 모든 브라우저에서 implemented되지 않았으므로 이를 사용하기 전에 감지해야 합니다. 사용할 수 있는 경우에도 할당량 초과 오류를 여전히 포착합니다 (아래 참조). 경우에 따라 한도를 초과하는 경우 사용 가능한 실제 스토리지 용량을 초과할 수 있습니다

검사

개발 중에 브라우저의 DevTools를 사용하여 저장된 데이터를 모두 쉽게 지울 수 있습니다.

Chrome 88에는 사이트의 저장용량을 재정의할 수 있는 새로운 기능이 추가되었습니다. 저장용량을 확보할 수 있습니다 이 기능을 사용하면 디스크 가용성이 낮은 상태에서 앱 동작을 테스트하세요 있습니다 애플리케이션 > 저장소로 이동한 다음 맞춤 스토리지 할당량 시뮬레이션 체크박스를 선택하고 스토리지 할당량을 시뮬레이션합니다

DevTools Storage 창

이 도움말을 작성하는 동안 다음과 같은 간단한 도구를 작성했습니다. 최대한 많은 스토리지를 빠르게 사용하는 것이 좋습니다 쉽고 빠르게 다양한 저장 메커니즘을 실험해 보고 할당량을 모두 사용합니다

할당량 초과는 어떻게 처리하나요?

할당량을 초과하면 어떻게 해야 하나요? 가장 중요한 것은 QuotaExceededError이든 누구든 쓰기 오류를 항상 포착하고 처리합니다. 다른 것입니다. 그런 다음 앱 디자인에 따라 처리 방법을 결정합니다. 예를 들어 장시간 액세스하지 않은 콘텐츠를 삭제하거나 삭제할 데이터를 선택할 수 있는 방법을 제공합니다.

IndexedDB와 Cache API 모두 이름이 지정된 DOMError을 발생시킵니다. 사용 가능한 할당량을 초과하면 QuotaExceededError가 반환됩니다.

IndexedDB

원본이 할당량을 초과한 경우 IndexedDB에 쓰기를 시도하면 있습니다 트랜잭션의 onabort() 핸들러가 호출되어 이벤트를 전달합니다. 이벤트의 오류 속성에 DOMException가 포함됩니다. 오류 name는 QuotaExceededError을 반환합니다.

const transaction = idb.transaction(['entries'], 'readwrite');
transaction.onabort = function(event) {
  const error = event.target.error; // DOMException
  if (error.name == 'QuotaExceededError') {
    // Fallback code goes here
  }
};

캐시 API

원본이 할당량을 초과한 경우 Cache API에 쓰기를 시도합니다. QuotaExceededError DOMException와 함께 거부됩니다.

try {
  const cache = await caches.open('my-cache');
  await cache.add(new Request('/sample1.jpg'));
} catch (err) {
  if (error.name === 'QuotaExceededError') {
    // Fallback code goes here
  }
}

제거는 어떻게 작동하나요?

웹 스토리지는 '최선의 노력'이라는 두 가지 버킷으로 분류됩니다. 'Persistent' 옵션을 제공합니다 최선의 조치를 취하지 않아도 브라우저에서 저장용량을 비울 수 있습니다. 사용자를 방해하지만 장기적이거나 중요한 데이터에 대한 내구성이 떨어집니다. 영구 스토리지는 스토리지가 부족해도 자동으로 비워지지 않습니다. 사용자 (브라우저 설정을 통해) 저장용량을 수동으로 삭제해야 합니다.

기본적으로 사이트의 데이터 (IndexedDB, Cache API 등)는 '최적의 노력' 카테고리로 분류해야 합니다. 영구 스토리지를 요청한 경우 브라우저가 사용자 재량에 따라 사이트 데이터를 관리합니다(예: 기기 저장공간이 부족할 때).

최선의 제거 정책은 다음과 같습니다.

Chromium 기반 브라우저는 브라우저가 소진되면 데이터를 제거하기 시작합니다. 가장 오래전에 사용한 출처의 모든 사이트 데이터를 먼저 지운 다음, 브라우저가 더 이상 한도를 초과하지 않을 때까지 다음 번 클릭하게 됩니다.
Internet Explorer 10 이상에서는 데이터가 제거되지 않지만 만들 수 있습니다.
사용 가능한 디스크 공간이 가득 차면 Firefox는 데이터를 제거하기 시작합니다. 가장 오래전에 사용한 출처에서 모든 사이트 데이터를 삭제한 다음 그 다음 브라우저가 더 이상 한도를 초과하지 않을 때까지 기다립니다.
Safari는 이전에는 데이터를 제거하지 않았지만 최근에 새로운 최대 7일로 제한하도록 설정할 수 있습니다 (아래 참고).

iOS, iPadOS 13.4, macOS의 Safari 13.1부터 IndexedDB, Service를 비롯한 모든 스크립트 쓰기 가능 스토리지의 7일 한도 작업자 등록 및 Cache API입니다. 즉, Safari에서 Safari를 사용하고 7일이 경과한 후에 캐시의 콘텐츠를 상호작용하지 않을 수 있습니다. 이 제거 정책은 설치된 앱에는 적용되지 않습니다. 홈 화면에 추가된 PWA 자세한 내용은 WebKit의 전체 서드 파티 쿠키 차단 등 블로그에서 자세한 내용을 확인하세요.

보너스: IndexedDB에 래퍼를 사용하는 이유

IndexedDB는 사용하기 전에 상당한 설정이 필요한 낮은 수준의 API입니다. 특히 간단한 데이터를 저장하는 데 어려울 수 있습니다 기존의 대부분의 프라미스 기반 API로, 이벤트 기반입니다 다음과 같은 래퍼를 IndexedDB의 idb는 몇 가지 강력한 기능을 숨기는 대신 중요한 것은 복잡한 기계 (예: 트랜잭션, 스키마 버전 관리)를 숨기는 것입니다. IndexedDB 라이브러리와 함께 제공됩니다.

결론

저장용량이 제한되는 시대는 지났습니다. 사용자가 더 많이 저장할 수 있도록 더 많은 데이터를 얻을 수 있습니다. 사이트에서 모든 리소스와 데이터를 효과적으로 실행할 수 있습니다 StorageManager API를 사용하여 다음 작업을 수행할 수 있습니다. 사용할 수 있는 용량과 사용량을 결정합니다. 또한 영구 저장소의 경우 사용자가 삭제하지 않는 한 제거되지 않도록 보호할 수 있습니다

추가 리소스

감사합니다.

Jarryd Goodman, Phil Walton, Eiji Kitamura, Daniel Murphy, Darwin Huang, Josh Bell, Marijn Kruisselbrink 및 Victor Costan 이 도움말을 참고하세요. Eiji Kitamura, Addy Osmani, 작문을 쓴 Marc Cohen에게 기사의 근간을 이루는 원본 기사입니다. 에이지가 만든 유용한 도구 브라우저 저장소 악용자라는 이용자를 검색하여 확인할 수 있습니다. 가능한 한 많은 데이터를 저장하고 스토리지 한도를 설정하는 것이 좋습니다. 철저한 구조물을 조사해 주신 프랑수아 보퍼트에게도 Safari로 이동하여 저장용량 한도를 확인합니다.

히어로 이미지는 Guillaume Bolduc가 스플래시 해제.