Hareket halindeyken internet bağlantıları kesintili olabilir veya hiç olmayabilir; bu nedenle, ilerici web uygulamalarında çevrimdışı destek ve güvenilir performans ortak özelliklerdir. Mükemmel kablosuz ortamlarda bile, önbelleğe alma ve diğer depolama tekniklerinin makul kullanımı, kullanıcı deneyimini önemli ölçüde iyileştirebilir. Statik uygulama kaynaklarınızı (HTML, JavaScript, CSS, resimler vb.) ve verilerinizi (kullanıcı verileri, haber makaleleri vb.) önbelleğe almanın birkaç yolu vardır. Ama en iyi çözüm hangisi? Ne kadar saklayabilirsiniz? Çıkarılmasını nasıl engelliyorsunuz?
Ne kullanmalıyım? #
İşte kaynakları depolamak için genel bir öneri:
IndexedDB ve Cache Storage API, her modern tarayıcıda desteklenir. Her ikisi de eşzamansızdır ve ana ileti dizisini engellemez. Şuradan erişilebilirler: window nesne, web çalışanları ve hizmet çalışanları, bunları kodunuzun herhangi bir yerinde kullanmayı kolaylaştırır.
Peki ya diğer depolama mekanizmaları? #
Tarayıcıda kullanılabilen birkaç başka depolama mekanizması vardır, ancak bunların kullanımı sınırlıdır ve önemli performans sorunlarına neden olabilir.
Oturum Depolama sekmeye özgüdür ve sekmenin kullanım ömrüne göre kapsamlandırılmıştır. Bir IndexedDB anahtarı gibi küçük miktarlarda oturuma özgü bilgileri depolamak için yararlı olabilir. Dikkatli kullanılmalıdır çünkü senkrondur ve ana iş parçacığını bloke eder. Yaklaşık 5 MB ile sınırlıdır ve yalnızca dizeleri içerebilir. Sekmeye özel olduğundan, web çalışanlarından veya hizmet çalışanlarından erişilemez.
Yerel depolama Senkronize olduğu ve ana iş parçacığını engelleyeceği için kaçınılmalıdır. Yaklaşık 5 MB ile sınırlıdır ve yalnızca dizeleri içerebilir. LocalStorage’a web çalışanlarından veya hizmet çalışanlarından erişilemez.
Kurabiye kullanımları vardır, ancak depolama için kullanılmamalıdır. Çerezler her HTTP isteğinde gönderilir, bu nedenle az miktarda veriden fazlasını depolamak, her web isteğinin boyutunu önemli ölçüde artıracaktır. Eşzamanlıdırlar ve web çalışanlarından erişilemezler. LocalStorage ve SessionStorage gibi çerezler de yalnızca dizelerle sınırlıdır.
bu Dosya Sistemi API’sı ve FileWriter API, dosyaları korumalı bir dosya sistemine okumak ve yazmak için yöntemler sağlar. Eşzamansız olsa da, önerilmez çünkü yalnızca Chromium tabanlı tarayıcılarda kullanılabilir.
File System Access API, kullanıcıların yerel dosya sistemlerindeki dosyaları okumasını ve düzenlemesini kolaylaştırmak için tasarlanmıştır. Bir sayfanın herhangi bir yerel dosyayı okuyabilmesi veya yazabilmesi için kullanıcının izin vermesi gerekir ve izinler oturumlar arasında kalıcı değildir.
WebSQL gerekir Olumsuz kullanılmalı ve mevcut kullanım IndexedDB’ye taşınmalıdır. Destek var kaldırıldı neredeyse tüm büyük tarayıcılardan. W3C Web SQL spesifikasyonunu korumayı durdurdu 2010’da, daha fazla güncelleme planlanmadan.
Uygulama Önbelleği Olumsuz kullanılmalı ve mevcut kullanım hizmet çalışanlarına ve Cache API’ye taşınmalıdır. Olmuştur kullanımdan kaldırıldı ve destek gelecekte tarayıcılardan kaldırılacaktır.
Ne kadar saklayabilirim? #
Kısacası, çok fazla, en az birkaç yüz megabayt ve potansiyel olarak yüzlerce gigabayt veya daha fazlası. Tarayıcı uygulamaları değişiklik gösterir, ancak kullanılabilir depolama miktarı genellikle cihazda bulunan depolama miktarına bağlıdır.
- Chrome, tarayıcının toplam disk alanının %80’ine kadarını kullanmasına izin verir. Bir kaynak, toplam disk alanının %60’ına kadarını kullanabilir. kullanabilirsiniz StorageManager API’si kullanılabilir maksimum kotayı belirlemek için. Diğer Chromium tabanlı tarayıcılar farklı olabilir.
- Gizli modda Chrome, bir kaynağın kullanabileceği depolama miktarını toplam disk alanının yaklaşık %5’ine düşürür.
- Kullanıcı Chrome’da “Tüm pencereleri kapattığınızda çerezleri ve site verilerini temizle” seçeneğini etkinleştirmişse, depolama kotası maksimum yaklaşık 300 MB’a önemli ölçüde düşürülür.
- Chrome’un uygulanmasıyla ilgili ayrıntılar için PR #3896’ya bakın.
- Internet Explorer 10 ve sonrası, 250 MB’a kadar depolayabilir ve 10 MB’tan fazlası kullanıldığında kullanıcıyı uyarır.
- Firefox, tarayıcının boş disk alanının %50’ye kadarını kullanmasına izin verir. Bir eTLD+1 grup (örn.
example.com,www.example.comVefoo.bar.example.com) 2GB’a kadar kullanabilir. kullanabilirsiniz StorageManager API’si ne kadar boş alan kaldığını belirlemek için. - Safari (hem masaüstü hem de mobil) yaklaşık 1 GB’a izin veriyor gibi görünüyor. Sınıra ulaşıldığında, Safari kullanıcıdan istemde bulunarak sınırı 200 MB’lık artışlarla artırır. Bununla ilgili herhangi bir resmi belge bulamadım.
- Mobil Safari’de ana ekrana bir PWA eklenirse, yeni bir saklama kapsayıcısı oluşturuyor gibi görünür ve PWA ile mobil Safari arasında hiçbir şey paylaşılmaz. Yüklü bir PWA için kota dolduğunda, ek depolama talep etmenin herhangi bir yolu yok gibi görünüyor.
Geçmişte, bir site depolanan belirli bir veri eşiğini aşarsa, tarayıcı kullanıcıdan daha fazla veri kullanma izni vermesini isterdi. Örneğin, kaynak 50 MB’tan fazla kullandıysa, tarayıcı kullanıcıdan 100 MB’a kadar depolamaya izin vermesini ister ve ardından 50 MB’lık artışlarla tekrar sorar.
Bugün, çoğu modern tarayıcı kullanıcıyı uyarmaz ve bir sitenin kendisine ayrılan kotayı kullanmasına izin verir. İstisna, depolama kotası aşıldığında uyarıda bulunan ve ayrılan kotayı artırmak için izin isteyen Safari gibi görünüyor. Bir kaynak tahsis edilen kotasından fazlasını kullanmaya çalışırsa, daha fazla veri yazma denemesi başarısız olur.
Ne kadar kullanılabilir depolama alanı olduğunu nasıl kontrol edebilirim? #
İçinde birçok tarayıcıkullanabilirsiniz StorageManager API’si kaynağın kullanabileceği depolama miktarını ve ne kadar depolama kullandığını belirlemek için. IndexedDB ve Cache API tarafından kullanılan toplam bayt sayısını bildirir ve kullanılabilir yaklaşık kalan depolama alanını hesaplamayı mümkün kılar.
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 değil uygulandı henüz tüm tarayıcılarda, bu yüzden kullanmadan önce algılama özelliği gerekir. Kullanılabilir olduğunda bile kota aşımı hatalarını yakalamanız gerekir (aşağıya bakın). Bazı durumlarda, kullanılabilir kotanın mevcut gerçek depolama miktarını aşması mümkündür.
İncelemek #
Geliştirme sırasında, farklı depolama türlerini incelemek ve saklanan tüm verileri kolayca temizlemek için tarayıcınızın DevTools’unu kullanabilirsiniz.
Chrome 88’de, Depolama Bölmesinde sitenin depolama kotasını geçersiz kılmanıza olanak tanıyan yeni bir özellik eklendi. Bu özellik, size farklı cihazları simüle etme ve uygulamalarınızın davranışını düşük disk kullanılabilirliği senaryolarında test etme yeteneği sağlar. git Başvuru Daha sonra Depolamaketkinleştir Özel depolama kotasını simüle edin onay kutusunu seçin ve depolama kotasını simüle etmek için herhangi bir geçerli sayı girin.
Bu makale üzerinde çalışırken, bir basit araç olabildiğince çok depolama alanını hızlı bir şekilde kullanmaya çalışmak. Farklı depolama mekanizmalarını denemenin ve tüm kotanızı kullandığınızda ne olduğunu görmenin hızlı ve kolay bir yoludur.
Kota aşımı nasıl yapılır? #
Kotayı aştığınızda ne yapmalısınız? En önemlisi, yazma hatalarını her zaman yakalamalı ve ele almalısınız. QuotaExceededError veya başka bir şey. Ardından, uygulama tasarımınıza bağlı olarak bununla nasıl başa çıkacağınıza karar verin. Örneğin, uzun süredir erişilmeyen içeriği silin, verileri boyuta göre kaldırın veya kullanıcılara silmek istediklerini seçmeleri için bir yol sağlayın.
Hem IndexedDB hem de Cache API, bir DOMError adlı QuotaExceededError kullanılabilir kotayı aştığınızda.
IndexedDB #
Kaynak, kotasını aştıysa, IndexedDB’ye yazma girişimleri başarısız olur. işlemin onabort() işleyici çağrılacak ve bir olay geçirilecek. Etkinlik şunları içerecektir: DOMException hata özelliğinde. Hatayı kontrol etme name dönecek 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
}
};
Önbellek API’sı #
Kaynak, kotasını aştıysa, Önbellek API’sine yazma girişimleri şu şekilde reddedilir: 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
}
}
Tahliye nasıl çalışır? #
Web depolama, “En İyi Çaba” ve “Kalıcı” olmak üzere iki grupta kategorize edilir. En iyi çaba, depolamanın kullanıcıyı rahatsız etmeden tarayıcı tarafından temizlenebileceği, ancak uzun vadeli veya kritik veriler için daha az dayanıklı olduğu anlamına gelir. Kalıcı depolama, depolama alanı azaldığında otomatik olarak temizlenmez. Kullanıcının bu depolamayı manuel olarak temizlemesi gerekir (tarayıcı ayarları aracılığıyla).
Varsayılan olarak, bir sitenin verileri (IndexedDB, Cache API, vb. dahil) en iyi çaba kategorisine girer; bu, bir site kalıcı depolama talep etmedikçe, örneğin cihaz depolama alanı düşük olduğunda, tarayıcının site verilerini kendi takdirine bağlı olarak çıkarabileceği anlamına gelir.
En iyi çaba için tahliye politikası:
- Chromium tabanlı tarayıcılar, tarayıcının alanı dolduğunda verileri çıkarmaya başlayacak ve tarayıcı artık sınırı aşmayana kadar tüm site verilerini önce en son kullanılan kaynaktan, ardından sonraki kaynaktan temizleyecektir.
- Internet Explorer 10+ verileri çıkarmayacak, ancak kaynağın artık yazmasını engelleyecektir.
- Firefox, kullanılabilir disk alanı dolduğunda verileri çıkarmaya başlayacak ve tarayıcı artık sınırı aşmayana kadar tüm site verilerini önce en son kullanılan kaynaktan, ardından sonraki kaynaktan temizleyecektir.
- Safari daha önce verileri çıkarmadı, ancak yakın zamanda tüm yazılabilir depolamaya yedi günlük yeni bir sınır getirdi (aşağıya bakın).
macOS’ta iOS ve iPadOS 13.4 ve Safari 13.1’den başlayarak, IndexedDB, hizmet çalışanı kaydı ve Önbellek API’si dahil olmak üzere tüm komut dosyasıyla yazılabilir depolamada yedi günlük bir sınır vardır. Bu, kullanıcı siteyle etkileşime girmezse, Safari’nin yedi günlük Safari kullanımından sonra tüm içeriği önbellekten çıkaracağı anlamına gelir. Bu tahliye politikası yüklü PWA’lar için geçerli değildir Ana ekrana eklenenler. Görmek Tam Üçüncü Taraf Çerez Engelleme ve Daha Fazlası tüm ayrıntılar için WebKit blogunda.
Bonus: IndexedDB için neden sarmalayıcı kullanmalısınız? #
IndexedDB, kullanımdan önce önemli düzeyde kurulum gerektiren ve özellikle basit verileri depolamak için sancılı olabilen düşük seviyeli bir API’dir. Çoğu modern vaat tabanlı API’nin aksine olay tabanlıdır. gibi söz sarmalayıcıları idb IndexedDB için bazı güçlü özellikleri gizler ama daha da önemlisi, IndexedDB kitaplığıyla birlikte gelen karmaşık makineleri (örneğin işlemler, şema sürüm oluşturma) gizler.
Çözüm #
Sınırlı depolamanın olduğu ve kullanıcıyı giderek daha fazla veri depolamaya sevk eden günler geride kaldı. Siteler, çalıştırmak için ihtiyaç duydukları tüm kaynakları ve verileri etkin bir şekilde depolayabilir. Kullanmak StorageManager API’si ne kadarının sizin için uygun olduğunu ve ne kadarını kullandığınızı belirleyebilirsiniz. Ve kalıcı depolama ile, kullanıcı onu kaldırmadığı sürece onu tahliyeye karşı koruyabilirsiniz.
Ek kaynaklar #
Teşekkürler #
Jarryd Goodman, Phil Walton, Eiji Kitamura, Daniel Murphy, Darwin Huang, Josh Bell, Marijn Kruisselbrink ve Victor Costan’a bu makaleyi inceledikleri için özel teşekkürler. Bunun dayandığı orijinal makaleleri yazan Eiji Kitamura, Addy Osmani ve Marc Cohen’e teşekkürler. Eiji adlı yararlı bir araç yazdı. Tarayıcı Depolama Alanını Kötüye Kullanan bu, mevcut davranışı doğrulamak için yararlıydı. Mümkün olduğu kadar çok veri depolamanıza ve depolama sınırlarını tarayıcınızda görmenize olanak tanır. Depolama sınırlarını bulmak için Safari’yi araştıran François Beaufort’a teşekkürler.
Kahraman görseli Guillaume Bolduc’a aittir. Unsplash.