인터넷 연결은 결함이 있거나 존재하지 않을 수 있으므로 오프라인 지원 및 안정적인 성능이 점진적인 웹 앱의 일반적인 기능입니다.
완벽한 무선 환경에서도 캐싱 및 기타 스토리지 기술을 신중하게 사용하면 사용자 경험을 크게 향상 시킬 수 있습니다.
정적 응용 프로그램 리소스 (HTML, JavaScript, CSS, 이미지 등)와 데이터 (사용자 데이터, 뉴스 기사 등)를 캐시하는 방법에는 여러 가지가 있습니다.
그러나 가장 좋은 솔루션은 무엇입니까? 얼마를 저장할 수 있습니까? 퇴거 당하지 않으려면 어떻게 해야 합니까?
https://web.dev/storage-for-the-web/
무엇을 사용해야 합니까?
리소스 저장에 대한 일반적인 권장 사항은 다음과 같습니다.
IndexedDB 및 Cache Storage API는 모든 최신 브라우저에서 지원됩니다. 둘 다 비동기이며 메인 스레드를 차단하지 않습니다. 창 개체, 웹 워커 및 서비스 워커에서 액세스 할 수 있으므로 코드의 어느 곳에서나 쉽게 사용할 수 있습니다.
다른 스토리지 메커니즘은 어떻습니까?
브라우저에는 여러 가지 다른 저장 메커니즘이 있지만 사용이 제한되어 심각한 성능 문제가 발생할 수 있습니다.
SessionStorage는 탭마다 다르며 탭 수명에 따라 범위가 정해집니다. 소량의 세션 특정 정보 (예 : IndexedDB 키)를 저장하는 데 유용 할 수 있습니다. 동기식이며 메인 스레드를 차단하므로 주의해서 사용해야 합니다. 약 5MB로 제한되며 문자열만 포함 할 수 있습니다. 탭마다 다르므로 웹 워커 나 서비스 워커가 액세스 할 수 없습니다.
LocalStorage는 동기식이며 메인 스레드를 차단하므로 피해야 합니다. 약 5MB로 제한되며 문자열 만 포함 할 수 있습니다. 웹 작업자 또는 서비스 작업자는 LocalStorage에 액세스 할 수 없습니다.
쿠키는 용도가 있지만 저장에 사용해서는 안됩니다. 쿠키는 모든 HTTP 요청과 함께 전송되므로 소량의 데이터 이상을 저장하면 모든 웹 요청의 크기가 크게 증가합니다. 그것들은 동 기적이며 웹 워커로부터 접근 할 수 없습니다. LocalStorage 및 SessionStorage와 마찬가지로 쿠키는 문자열로만 제한됩니다.
File System API 및 FileWriter API는 파일을 샌드 박스 파일 시스템으로 읽고 쓰는 방법을 제공합니다. 비동기식이지만 Chromium 기반 브라우저에서만 사용할 수 있으므로 권장되지 않습니다.
Native File System API는 사용자가 로컬 파일 시스템에서 파일을 쉽게 읽고 편집 할 수 있도록 설계되었습니다. 사용자가 페이지가 로컬 파일을 읽거나 쓰기 전에 권한을 부여해야 하며 세션간에 권한이 유지되지 않습니다.
WebSQL을 사용하지 않아야 하며 기존 사용법을 IndexedDB로 마이그레이션해야합니다. 거의 모든 주요 브라우저에서 지원이 제거되었습니다. W3C는 2010 년에 Web SQL 사양 유지를 중단했으며 추가 업데이트 계획은 없습니다.
응용 프로그램 캐시를 사용하지 않아야 하며 기존 사용을 서비스 작업자 및 캐시 API로 마이그레이션해야합니다. 더 이상 사용되지 않으며 향후 브라우저에서 지원이 제거됩니다.
얼마나 저장할 수 있습니까?
요컨대, 적어도 수백 메가 바이트, 그리고 잠재적으로 수백 기가 바이트 이상이 됩니다. 브라우저 구현은 다양하지만 사용 가능한 스토리지 양은 일반적으로 장치에서 사용 가능한 스토리지 양을 기준으로 합니다.
과거에는 사이트가 저장된 특정 데이터 임계 값을 초과하면 브라우저는 사용자에게 더 많은 데이터를 사용할 수 있는 권한을 부여하라는 메시지를 표시했습니다. 예를 들어, 원본이 50MB 이상을 사용하는 경우 브라우저는 사용자에게 최대 100MB를 저장할 수 있도록 요청한 다음 50MB 단위로 다시 요청합니다.
오늘날 대부분의 최신 브라우저는 사용자에게 메시지를 표시하지 않으며 사이트가 할당 된 최대 할당량을 사용할 수 있도록 합니다. 예외는 Safari로 표시되며, 최대 1.1GB의 저장 권한을 요청하는 750MB의 프롬프트가 표시됩니다. 오리진이 할당량 보다 많은 할당량을 사용하려고 하면 데이터 쓰기 시도가 더 이상 실패합니다.
사용 가능한 저장 공간을 어떻게 확인할 수 있습니까?
많은 브라우저에서 StorageManager API를 사용하여 오리진에 사용 가능한 스토리지 양과 사용 중인 스토리지 양을 판별 할 수 있습니다. IndexedDB 및 캐시 API에서 사용한 총 바이트 수를 보고 하고 사용 가능한 대략적인 남은 스토리지 공간을 계산할 수 있습니다.
if (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.used;
console.log(`You can write up to ${remaining} more bytes.`);
}StorageManager가 아직 모든 브라우저에서 구현되지는 않았으므로 사용하기 전에 기능을 감지해야 합니다. 사용 가능한 경우에도 여전히 초과 인용 부호 오류를 잡아야 합니다 (아래 참조). 경우에 따라 사용 가능한 할당량이 실제 사용 가능한 스토리지 양을 초과 할 수 있습니다.
다른 Chromium 기반 브라우저는 사용 가능한 할당량을 보고 할 때 사용 가능한 공간의 양을 고려할 수 있습니다. Chrome은 실제 디스크 크기의 60 %를 항상 보고하지 않습니다. 이렇게 하면 저장된 교차 원본 리소스의 크기를 결정하는 기능이 줄어 듭니다.
Inspect
개발 중에는 브라우저의 DevTools를 사용하여 다양한 스토리지 유형을 검사하고 저장된 모든 데이터를 쉽게 지울 수 있습니다.
이 기사에서 작업하면서 가능한 한 많은 스토리지를 빠르게 사용하려고 시도하는 간단한 도구를 작성했습니다.
다양한 스토리지 메커니즘을 실험하고 모든 할당량을 사용할 때 어떤 일이 발생하는지 확인할 수 있는 빠르고 쉬운 방법입니다.
할당량 초과 처리 방법
할당량을 초과하면 어떻게 해야 합니까? 가장 중요한 것은 쓰기 오류가 QuotaExceededError이든 다른 오류이든 항상 잡아서 처리해야 합니다. 그런 다음 앱 디자인에 따라 처리 방법을 결정하십시오.
예를 들어 오랫동안 액세스하지 않은 콘텐츠를 삭제하거나 크기에 따라 데이터를 제거하거나 사용자가 삭제할 항목을 선택할 수 있는 방법을 제공합니다.
사용 가능한 할당량을 초과하면 IndexedDB와 Cache API 모두 QuotaExceededError라는 DOMError를 발생시킵니다.
IndexedDB
오리진이 할당량을 초과 한 경우 IndexedDB에 대한 쓰기 시도가 실패합니다. 트랜잭션의 onabort() 핸들러가 호출되어 이벤트를 전달합니다. 이벤트는 error 속성에 DOMException을 포함합니다. 오류 이름을 확인하면 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
}
};Cache API
오리진이 할당량을 초과 한 경우 캐시 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
}
}퇴거는 어떻게 이루어 집니까?
웹 스토리지는 "Best Effort"와 "Persistent"의 두 가지 버킷으로 분류됩니다. 최선의 노력은 브라우저를 통해 사용자를 방해하지 않고 스토리지를 지울 수 있지만 장기 또는 중요 데이터에 대해서는 내구성이 떨어집니다.
스토리지가 부족하면 영구 스토리지가 자동으로 지워지지 않습니다. 사용자는 브라우저 설정을 통해 이 저장소를 수동으로 지워야 합니다.
기본적으로 사이트 데이터 (IndexedDB, 캐시 API 등 포함)는 최선의 노력 범주에 속합니다.
즉, 사이트가 영구 스토리지를 요청하지 않으면 브라우저는 예를 들어 디바이스 스토리지가 부족할 때 재량에 따라 사이트 데이터를 제거 할 수 있습니다.
최선의 노력을 위한 퇴거 정책은 다음과 같습니다.
macOS의 iOS 및 iPadOS 13.4 및 Safari 13.1부터 IndexedDB, 서비스 워커 등록 및 캐시 API를 포함하여 모든 스크립트 쓰기 가능 스토리지에 7 일 제한이 있습니다. 즉, 사용자가 사이트와 상호 작용하지 않으면 Safari는 7 일 간의 Safari 사용 후 캐시에서 모든 컨텐츠를 제거합니다. 이 제거 정책은 홈 화면에 추가 된 설치된 PWA에는 적용되지 않습니다. 자세한 내용은 WebKit 블로그에서 전체 타사 쿠키 차단 및 기타를 참조하십시오.
보너스 : IndexedDB에 래퍼를 사용하는 이유
IndexedDB는 사용하기 전에 상당한 설정이 필요한 저수준 API로, 간단한 데이터를 저장하는 데 특히 어려움이 있습니다. 대부분의 최신 약속 기반 API와 달리 이벤트 기반입니다. IndexedDB 용 idb와 같은 약속 래퍼는 강력한 기능 중 일부를 숨기지 만 IndexedDB 라이브러리와 함께 제공되는 복잡한 기계 (예 : 트랜잭션, 스키마 버전 관리)를 숨 깁니다.
결론
스토리지가 제한되어 사용자에게 점점 더 많은 데이터를 저장하라는 메시지가 사라졌습니다.
사이트는 실행하는 데 필요한 모든 리소스와 데이터를 효과적으로 저장할 수 있습니다. StorageManager API를 사용하여 사용 가능한 양과 사용 된 양을 판별 할 수 있습니다.
영구 저장소를 사용하면 사용자가 제거하지 않는 한 퇴거로부터 보호 할 수 있습니다.
추가 자료
등록된 댓글이 없습니다.
