Seoptimasi: Optimasi Cache Browser

	Dengan SEGALA HORMAT ,Kami mohon dukungan dan Partisipasinya dalam membebaskan Indonesia dari reputasi BURUK oleh Search Engine Google,Yahoo & Bing sebagai Negara Penghasil SPAM dan SPAMMER terbanyak ke-3 (tiga) didunia, Kami minta waktu anda sejenak untuk bergabung pada komunitas SEO Indonesia tanpa SPAM dan SPAMMER,terima kasih atas partisipasinya.

Aturan ini berlaku saat PageSpeed Insights mendeteksi bahwa respons dari server Anda tidak menyertakan header penyimpanan ke cache yang eksplisit atau jika sumber daya ditentukan untuk disimpan dalam cache untuk jangka waktu pendek.

Browser Chaching Proses

Ikhtisar

Penyimpanan ke cache browser untuk sumber daya statis dapat menghemat waktu pengguna jika mereka mengunjungi situs Anda lebih dari sekali. Sebaiknya header penyimpanan ke cache berlaku untuk semua sumber daya statis yang dapat disimpan di cache, tidak hanya sebagian kecil saja (misalnya gambar). Sumber daya yang dapat disimpan di cache meliputi file JS dan CSS, file gambar, dan file objek biner lainnya (file media, PDF, dsb.). Secara umum, HTML tidaklah statis dan tidak dapat disimpan di cache secara default. Sebaiknya Anda mempertimbangkan kebijakan penyimpanan dalam cache apa yang dapat bekerja dengan baik untuk HTML situs Anda.

Saran

Aktifkan penyimpanan ke cache browser untuk server Anda. Sumber daya statis setidaknya memiliki masa penyimpanan dalam cache selama seminggu. Untuk sumber daya pihak ketiga seperti iklan atau widget, sumber daya tersebut memiliki masa penyimpanan dalam cache setidaknya satu hari. Untuk semua sumber daya yang dapat disimpan di cache, sebaiknya ikuti setelan berikut:

Setel Expires minimal satu minggu, dan sebaiknya sampai satu tahun ke depan. (Kami lebih memilih Expires daripada Cache-Control: max-age karena lebih banyak didukung.) Jangan menyetelnya melebihi satu tahun ke depan karena melanggar pedoman RFC.
Jika Anda tahu persis waktu saat sumber daya akan berubah, setel masa berakhir yang lebih pendek. Namun jika sumber daya tersebut "akan segera berubah" tetapi Anda tidak tahu waktunya, sebaiknya setel masa berakhir yang panjang dan gunakan penyidikjarian URL (yang dideskripsikan di bawah).

Menggunakan Expires dan Cache-Control: max-age

Header ini menentukan jangka waktu yang dimiliki browser untuk dapat menggunakan sumber daya yang disimpan di cache tanpa perlu memeriksanya untuk mengetahui apakah versi baru tersedia dari server web. Header tersebut merupakan "header penyimpanan ke cache yang kuat" yang berlaku tanpa syarat. Setelah header disetel dan sumber daya diunduh, browser tidak akan mengeluarkan permintaan GET apa pun untuk sumber daya sampai tanggal masa berakhir atau usia maksimum tercapai, atau sampai cache dihapus oleh pengguna.

Header Last-Modifed dan ETag

Header ini menetapkan bagaimana seharusnya browser menentukan apakah file sama untuk tujuan penyimpanan ke cache. Pada header Last-Modified, yang menjadi acuan adalah tanggal. Pada header ETag, yang ditetapkan menjadi acuan dapat berupa nilai apa pun yang mengidentifikasi sumber daya secara unik (umumnya versi file atau hash konten). Last-Modified merupakan header penyimpanan ke cache yang "lemah", dalam artian browser menerapkan heuristik untuk menentukan apakah mengambil item dari cache atau tidak.

Header ini memungkinkan browser memperbarui sumber daya yang disimpan di cache secara efisien dengan mengeluarkan permintaan GET bersyarat saat pengguna memuat ulang laman secara eksplisit. GET bersyarat tidak mengembalikan respons penuh kecuali sumber daya telah berubah di server. Dengan demikian, GET bersyarat memiliki latensi yang lebih rendah daripada GET penuh.
Header penyimpanan ke cache mana yang seharusnya saya gunakan?
Penting untuk menetapkan salah satu dari Expires atau Cache-Control max-age, dan salah satu dari Last-Modified atau ETag, untuk semua sumber daya yang dapat disimpan di cache. Menentukan Expires dan Cache-Control: max-age, atau menentukan Last-Modified dan ETag merupakan hal yang berlebihan.

Menggunakan penyidikjarian URL

Untuk sumber daya yang terkadang berubah, kita dapat meminta browser agar menyimpan sumber daya di cache sampai sumber daya tersebut berubah di server. Dan pada saat sumber daya berubah di server, server memberi tahu browser bahwa versi baru tersedia. Kita dapat mencapai hal ini dengan memberikan URL unik ke setiap versi sumber daya. Misalnya, anggap saja kita memiliki sumber daya yang diberi nama “my_stylesheet.css.” Kita dapat mengubah nama file menjadi “my_stylesheet_fingerprint.css”. Saat sumber daya berubah, begitu juga sidik jarinya, dan kemudian URL-nya pun berubah. Segera setelah URL berubah, browser dipaksa untuk mengambil ulang sumber daya. Penyidikjarian memungkinkan kita menyetel tanggal masa berakhir yang lama ke masa mendatang, bahkan untuk sumber daya yang lebih sering berubah.

Cara umum penyidikjarian adalah dengan bilangan heksadesimal 128-bit yang mengodekan hash konten file tersebut.

Strategi lain adalah dengan membuat direktori rilisan baru untuk setiap versi baru aplikasi dan menempatkan semua aset untuk setiap versi pada direktori berversi. Strategi ini memiliki kelemahan bahwa apabila aset tidak berubah di antara versi, URL-nya masih akan berubah dan memaksa pengunduhan ulang. Menggunakan hash konten tidak terkena dampak masalah ini, tapi sedikit lebih kompleks.

Demikian apa yang dapat saya sampaikan dan saya berharap anda dapat mengambil manfaatnya untuk informasi dan bahan pengetahuan.jika anda merasa artikel yang saya tulis bermanfaat silahkan tinggalkan komentar anda,dan terima kasih atas kunjungannya.

Baca juga : Bebaskan Indonesia dari SPAM dan SPAMMER

Sources Google Insight