apakah realistis untuk menggunakan penyimpanan lokal HTML5 untuk menyimpan CSS, dan JavaScript


22

Idenya adalah memanfaatkan penyimpanan lokal HTML5 untuk menyimpan CSS dan JavaScript yang sering diakses.

Misalnya (pseudo-code):

var load_from_cdn = true;
jika (mendeteksi penyimpanan lokal)  
{
  if (cache of css, js found)
  {
     memuat cache penyimpanan lokal
     load_from_cdn = false;
  }
}
jika (load_from_cdn)
{
   document.write ('<script> ...');
}

Apakah ini mungkin atau realistis?

Saya menyadari cache browser, masih akan ada beberapa pemeriksaan akses header,
saya berasumsi tidak ada akses HTTP yang lebih baik (dalam pemikiran saya )

PS: Tampaknya penyimpanan lokal hanya mendukung pasangan nilai kunci , dapatkah seseorang membuktikannya?
(terbaik dengan beberapa contoh)



1
itu ide saya 2 tahun yang lalu ... :)
ajreal

Pertanyaan Anda adalah hal pertama yang saya temukan ketika saya mencari di Google tentang hal itu. Ada banyak diskusi di sini tentang apakah itu ide yang bagus atau tidak, jadi saya pikir saya akan memberikan beberapa bukti anekdotal yang mendukung!
Dave

1
Gambaran itu menyesatkan. Jika Anda menggulir lebih jauh ke bawah, Anda dapat melihat bahwa penurunan besar itu sebenarnya bukan karena penyimpanan lokal lebih baik daripada caching, melainkan bug dalam pengaturan caching mereka: " Ternyata menjadi kurang spektakuler :(. Grafik lalu lintas internal, penurunan karena ke localStorage menyembunyikan bug caching "- twitter.com/catrope/status/408110382599782400
Jamie Barker

Jawaban:


11

Benar-benar OK untuk menggunakan penyimpanan lokal untuk menyimpan JS dan CSS. Namun, penyimpanan lokal memiliki batasan 5M per domain. Anda mungkin harus mempertimbangkan kembali strategi ini.

Untuk web desktop, Anda dapat memanfaatkan cache browser default untuk melakukan triknya. Cukup setel respons HTTP JS & CSS menjadi cacheable. Sederhana dan mudah.

Untuk web seluler, latensi tinggi. Jadi, mengurangi permintaan HTTP sangat penting. Jadi, memiliki JS & CSS di URL eksternal adalah optimal. Akan jauh lebih baik untuk memiliki inline JS & CSS. Ini mengurangi permintaan HTTP, tetapi membengkak konten HTML. Lalu apa? Seperti yang Anda katakan, gunakan penyimpanan lokal!

Ketika satu browser mengunjungi situs untuk pertama kalinya, JS & CSS dimasukkan sebaris. JS juga memiliki dua pekerjaan lagi: 1) Simpan JS & CSS ke penyimpanan lokal; 2) Tetapkan cookie untuk menandai bahwa JS & CSS ada di penyimpanan lokal.

Ketika browser mengakses situs untuk kedua kalinya, server mendapatkan cookie dan tahu bahwa browser sudah memiliki JS & CSS terkait. Jadi HTML render memiliki inline JS untuk membaca JS & CSS dari penyimpanan lokal dan menyisipkan ke dalam pohon DOM.

Ini adalah ide dasar bagaimana versi mobile bing.com dibuat. Anda mungkin perlu mempertimbangkan kontrol versi JS & CSS saat mengimplementasikannya dalam produksi.

Terima kasih


Ya, cukup dekat dengan apa yang saya pikirkan.
ajreal

Google mengembangkan modul untuk Page Speed ​​Mod yang melakukan hal yang sama. Inilah halaman di mana mereka berbicara tentang barang, hal-hal buruk dan tidak diketahui pengembang.google.com/speed/pagespeed/module/…
tacone

terbalik, tetapi apa artinya "inline" dalam kasus ini. "inline" memiliki seperti 5 arti yang berbeda.
Alexander Mills

1
Ini sebenarnya meningkat menjadi 10MB untuk Desktop dan 5MB untuk seluler
Roko C. Buljan

1
Anda tidak memerlukan cookie apa pun. Anda cukup membaca jika penyimpanan lokal memiliki kunci / nilai yang Anda cari plus Anda harus memberikan versi (untuk tujuan pembatalan yang jelas). Trik ini hanya baik setelah kedua kalinya situs diakses dan juga jika aset tidak ada dalam cache (untuk beberapa alasan)
vsync


23

Apa gunanya?

Sudah ada teknik mapan yang disebut caching sisi klien. Apa yang dibawa penyimpanan lokal HTML5 dalam kasus ini caching apa yang tidak ada?

Anda mungkin memiliki semacam aplikasi aneh yang harus memuat potongan kode JavaScript secara dinamis sehingga Anda tidak dapat menggunakan cache secara efektif, tetapi ini merupakan kasus yang sangat jarang.

Juga, waspadai hal lain. Browser memiliki kebijakan khusus untuk cache, dan sebagian besar browser cukup baik dalam mengelola cache dengan baik (hanya menghapus konten yang lebih lama, dll.). Dengan menerapkan cache buatan Anda, Anda mencegah browser mengaturnya dengan benar. Tidak hanya itu dapat dikritik sendiri, tetapi juga akan merugikan Anda cepat atau lambat. Contoh: ketika pengguna aplikasi web melaporkan bug, sering Anda menjawab dengan meminta mereka menghapus cache. Saya tidak yakin apa yang akan Anda tanyakan dalam kasus Anda, karena membersihkan cache tidak akan pernah menyelesaikan masalah dengan aplikasi web Anda.


Menanggapi hasil edit pertama Anda (edit kedua Anda di luar topik):

Saya tahu cache browser, masih akan ada beberapa pemeriksaan akses header

Anda tampaknya kurang memahami tentang cache browser. Itu sebabnya penting untuk memahami cara kerjanya dulu, sebelum mulai menerapkan mekanisme caching buatan sendiri . Temukan kembali roda Anda sendiri hanya ketika Anda cukup memahami roda yang ada dan memiliki alasan yang baik untuk tidak menggunakannya. Lihat poin 1 dari jawaban saya untuk pertanyaan "Menemukan kembali roda dan TIDAK menyesalinya" .

Saat memberikan beberapa data melalui HTTP, Anda dapat menentukan beberapa header yang terkait dengan cache:

  • Last-Modified menentukan kapan konten diubah,
  • Expiresmenentukan kapan browser harus bertanya ke server jika konten berubah .

Dua header itu memungkinkan browser untuk:

  • Hindari mengunduh konten lagi dan lagi. Jika Last-Modifieddiatur ke bulan lalu, dan konten sudah diunduh hari ini beberapa jam sebelumnya, tidak perlu mengunduhnya lagi.
  • Hindari permintaan tanggal di mana file terakhir diubah. Jika Expiresdari entitas cache Mei 5 th 2014, Anda tidak perlu mengeluarkan permintaan GET tidak pada tahun 2011, atau pada tahun 2012 atau 2013, karena Anda tahu bahwa cache adalah up-to-date.

Yang kedua sangat penting untuk CDN. Saat Google menyajikan JQuery kepada pengunjung Stack Overflow atau cdn.sstatic.netmenyajikan gambar atau stylesheet yang digunakan oleh Stack Overflow, mereka tidak ingin browser meminta versi baru setiap waktu. Sebaliknya, mereka melayani file-file itu satu kali, mengatur tanggal kedaluwarsa menjadi sesuatu yang cukup lama, dan hanya itu.

Contohnya, screenshot dari apa yang terjadi ketika saya mengunjungi halaman muka Stack Overflow:

Tangkapan layar garis waktu Stack Overflow di Chrome menunjukkan 15 file, 3 sedang diminta, 12 dilayani langsung dari cache tanpa ada permintaan ke server jauh

Ada 15 file untuk dilayani. Tapi di mana semua 304 Not Modifiedtanggapan itu? Anda hanya memiliki tiga permintaan konten yang berubah. Untuk yang lainnya, browser menggunakan versi cache tanpa membuat permintaan ke server apa pun .


Untuk menyimpulkan, Anda benar-benar perlu berpikir dua kali sebelum menerapkan mekanisme cache Anda sendiri, dan terutama menemukan skenario yang baik di mana ini bisa berguna . Seperti yang saya katakan di awal jawaban saya, saya hanya dapat menemukan satu: di mana Anda melayani potongan JavaScript untuk menggunakannya, OMG eval(),. Tetapi dalam hal ini, saya cukup yakin bahwa ada pendekatan yang lebih baik yaitu:

  • Lebih efektif menggunakan teknik cache standar, atau
  • Lebih mudah dirawat.

+1 untuk yang ini. Sama sekali tidak ada gunanya. Hampir dalam semua kasus mutlak. Caching dengan beberapa kunci unik berbasis hash jauh lebih baik.
shabunc

1
Anda tidak sepenuhnya benar tentang cache browser. Penyegaran keras akan melewati semua pengecekan cache browser.
ajreal

1
Tautan ke reinventing the wheel and not regretting itmati: '(
Esailija

4
Caching Bowser tidak semaju yang Anda bayangkan, juga tidak konsisten di semua browser. Sebagai contoh, beberapa browser secara acak memutuskan untuk memuat font web (terlepas dari header - tidak dapat menemukan artikel tentang ini sekarang, tetapi saya pikir Dave Rupert yang menemukan ini). Juga, ETAG memaksa browser untuk memeriksa apakah suatu sumber daya telah diperbarui ... dan kadang-kadang Anda tidak dapat menghapus ETAG (mis. Amazon S3) - jadi jika file CSS Anda mengirim header ETAG, itu akan selalu diperiksa untuk pembaruan (304s masih payload). Untuk mencegah permintaan yang tidak perlu, caching khusus diperlukan.
Ryan Wheale

7

Caching lokal sisi klien harus lebih dioptimalkan daripada menggunakan penyimpanan lokal HTML5. Pastikan saja javascript dan CSS Anda ada di file eksternal yang bisa dibuka dan halaman Anda harus memuat lebih cepat melalui cache browser daripada mencoba mengekstraknya dari penyimpanan lokal dan mengeksekusinya sendiri.

Selain itu, browser dapat mulai memuat sumber daya eksternal saat halaman mulai memuat, sebelum Anda benar-benar dapat mulai menjalankan javascript di halaman itu untuk kemudian mendapatkan sumber daya Anda dari penyimpanan lokal HTML5.

Selain itu, Anda memerlukan kode di halaman untuk memuat dari penyimpanan lokal HTML5, jadi masukkan saja semua JS Anda ke dalam satu file JS eksternal yang dapat dilepas.



2

Anda akan mendapatkan kinerja yang jauh lebih baik dengan menggunakan jaringan pengiriman konten (CDN) seperti perpustakaan kode Google . Direncanakan dengan serius, sebagian besar JS dan CSS Anda harus ada dalam cache setiap pengunjung sebelum mereka mengunjungi situs Anda untuk pertama kalinya. Perkecil sisanya.

Anda selalu dapat membandingkan cache caching dengan solusi HTML5 linting tangan Anda. Tapi taruhan saya adalah bahwa caching asli akan mengalahkan celananya.


2

Menggunakan localStorage cepat (er)! Tes saya menunjukkan

  • Memuat jQuery dari CDN: Chrome 268ms , FireFox: 200ms
  • Memuat jQuery dari localStorage: Chrome 47ms , FireFox 14ms

Saya kira menyimpan permintaan HTTP sudah membawa keuntungan kecepatan besar. Semua orang di sini tampaknya diinsafkan akan hal yang sebaliknya, jadi tolong buktikan saya salah.

Jika Anda ingin menguji hasil saya, saya membuat perpustakaan kecil yang menyimpan skrip di localStorage. Lihat di Github https://github.com/webpgr/cached-webpgr.js atau cukup salin dari contoh di bawah ini.

Perpustakaan lengkap:

function _cacheScript(c,d,e){var a=new XMLHttpRequest;a.onreadystatechange=function(){4==a.readyState&&(200==a.status?localStorage.setItem(c,JSON.stringify({content:a.responseText,version:d})):console.warn("error loading "+e))};a.open("GET",e,!0);a.send()}function _loadScript(c,d,e,a){var b=document.createElement("script");b.readyState?b.onreadystatechange=function(){if("loaded"==b.readyState||"complete"==b.readyState)b.onreadystatechange=null,_cacheScript(d,e,c),a&&a()}:b.onload=function(){_cacheScript(d,e,c);a&&a()};b.setAttribute("src",c);document.getElementsByTagName("head")[0].appendChild(b)}function _injectScript(c,d,e,a){var b=document.createElement("script");b.type="text/javascript";c=JSON.parse(c);var f=document.createTextNode(c.content);b.appendChild(f);document.getElementsByTagName("head")[0].appendChild(b);c.version!=e&&localStorage.removeItem(d);a&&a()}function requireScript(c,d,e,a){var b=localStorage.getItem(c);null==b?_loadScript(e,c,d,a):_injectScript(b,c,d,a)};

Memanggil perpustakaan

requireScript('jquery', '1.11.2', 'http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js', function(){
    requireScript('examplejs', '0.0.3', 'example.js');
});

3
Ukuran Anda tidak relevan. (1) Jika pengguna baru ke situs web, ia tidak memiliki jQuery di penyimpanan lokal. (2) Jika, di sisi lain, pengguna sudah mengunjungi situs web Anda, ia memiliki jQuery dalam cache, yang berarti itu tidak akan dimuat dari CDN. Ini juga mengarah pada poin ketiga: (3) penyimpanan lokal sesuai untuk situs tertentu, sementara jQuery di Google CDN dibagikan oleh banyak situs, yang berarti bahwa pengguna yang mengunjungi, katakanlah, Stack Overflow tetapi baru di situs Anda menang perlu memuat ulang jQuery dari CDN jika Anda menggunakan versi jQuery yang sama.
Arseni Mourzenko

@MainMa Mungkin ukuran ini tidak baik, saya melihat itu sekarang, tetapi untuk cache browser berfungsi harus ada permintaan kirim ke server yang kemudian mengembalikan 304. Permintaan ini membutuhkan waktu lebih lama daripada langsung mendapatkan file dari penyimpanan lokal . Koreksi saya jika saya salah.
pilih

@MainMa tolong periksa juga komentar dari programmers.stackexchange.com/a/105526/195684 ada lebih banyak masalah dengan cache, seperti perbandingan ETAG yang membuat caching kustom ini lebih cepat
pilih
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.