Crawling Edisi Desember: Penyimpanan cache HTTP

Senin, 9 Desember 2024

Mohon izinkan kami menyimpan cache.

Seiring dengan berkembangnya internet dari tahun ke tahun, jumlah halaman yang di-crawl Google juga meningkat. Meskipun infrastruktur crawling Google sudah lama mendukung mekanisme penyimpanan cache heuristik, jumlah permintaan yang dapat ditampilkan dari cache lokal makin menurun: 10 tahun lalu, hanya sekitar 0,026% dari total pengambilan dapat disimpan dalam cache, yang sebenarnya sudah tidak terlalu mengesankan; saat ini, angka tersebut turun menjadi 0,017%.

Mengapa penyimpanan cache itu penting?

Mekanisme penyimpanan cache adalah komponen krusial dalam infrastruktur internet yang kompleks. Penyimpanan cache memungkinkan halaman dimuat dengan sangat cepat saat dibuka kembali, menghemat resource komputasi, sehingga menghemat sumber daya alam dan bandwidth yang sangat mahal untuk klien dan server.

Terutama jika Anda memiliki situs besar dengan konten yang jarang berubah di setiap URL, mengizinkan penyimpanan cache secara lokal dapat membantu situs Anda di-crawl secara lebih efisien. Infrastruktur crawling Google mendukung penyimpanan cache HTTP heuristik seperti yang ditentukan oleh standar penyimpanan cache HTTP, khususnya melalui header respons ETag dan permintaan If-None-Match, serta header respons Last-Modified dan permintaan If-Modified-Since.

Sebaiknya gunakan ETag karena lebih jarang mengalami error dan kesalahan (nilainya tidak terstruktur, tidak seperti nilai Last-Modified). Selain itu, jika memungkinkan, Anda dapat menetapkan keduanya: mungkin hal itu dapat berdampak positif di internet. Bisa jadi demikian.

Anda yang menentukan perubahan apa yang mengharuskan klien memuat ulang cache. Sebaiknya Anda meminta pembaruan cache jika ada perubahan yang signifikan pada konten Anda; jika Anda hanya memperbarui tanggal hak cipta di bagian bawah halaman, hal itu mungkin tidak terlalu signifikan.

ETag dan If-None-Match

Crawler Google mendukung permintaan bersyarat berbasis ETag persis seperti yang ditentukan dalam standar penyimpanan cache HTTP. Artinya, untuk memberikan sinyal preferensi penyimpanan cache ke crawler Google, tetapkan nilai Etag ke string ASCII arbitrer (biasanya hash konten atau nomor versi, tetapi juga dapat berupa bagian dari π, sesuai pilihan Anda) unik untuk representasi konten yang dihosting oleh URL yang diakses. Misalnya, jika Anda menghosting versi berbeda dari konten yang sama dengan URL yang sama (misalnya, versi seluler dan desktop), setiap versi dapat memiliki nilai ETag uniknya sendiri.

Crawler Google yang mendukung penyimpanan cache akan mengirimkan nilai ETag yang ditampilkan untuk crawl sebelumnya dari URL tersebut di If-None-Match header. Jika nilai ETag yang dikirim oleh crawler cocok dengan nilai saat ini yang dihasilkan server, server Anda akan menampilkan kode status HTTP 304 (Tidak diubah) tanpa isi HTTP. Bagian terakhir ini, yaitu tidak adanya isi HTTP, sangat penting karena beberapa alasan:

  • server Anda tidak perlu menghabiskan resource komputasi untuk membuat konten sebenarnya; artinya, Anda menghemat uang
  • server Anda tidak perlu mentransfer isi HTTP; sekali lagi, Anda menghemat uang

Di sisi klien, seperti browser pengguna atau Googlebot, konten di URL tersebut diambil dari cache internal klien. Karena tidak melibatkan transfer data, proses ini terjadi dengan sangat cepat, sehingga membuat pengguna senang sekaligus berpotensi menghemat sejumlah resource untuk klien.

Last-Modified dan If-Modified-Since

Mirip dengan ETag, crawler Google juga mendukung permintaan bersyarat Last-Modified based, persis seperti yang ditetapkan dalam standar Penyimpanan Cache HTTP. Secara semantik, ETag memiliki cara kerja yang sama, yaitu menggunakan ID untuk menentukan apakah resource dapat disimpan dalam cache. Mekanisme ini juga memberikan manfaat yang sama seperti ETag di sisi klien.

Kami memiliki beberapa rekomendasi jika Anda menggunakan Last-Modified sebagai perintah penyimpanan cache:

  1. Tanggal di header Last-Modified harus diformat sesuai dengan standar HTTP. Untuk menghindari masalah penguraian, sebaiknya gunakan format tanggal berikut: "Hari, DD Mon YYYY HH:MM:SS Zona Waktu". Misalnya, "Fri, 4 Sep 1998 19:15:56 GMT".
  2. Meskipun tidak wajib, sebaiknya tetapkan kolom max-age dari header Cache-Control untuk membantu crawler menentukan kapan harus meng-crawl ulang URL tertentu. Tetapkan nilai kolom max-age dengan perkiraan waktu dalam detik ketika kontennya tetap sama. Misalnya, Cache-Control: max-age=94043.

Contoh

Sama seperti saya, Anda mungkin kesulitan memahami cara kerja penyimpanan cache heuristik. Namun, melihat contoh rantai permintaan dan respons bisa membantu kita memahaminya dengan lebih baik. Berikut dua rantai—satu untuk ETag/If-None-Match dan satu lagi untuk Last-Modified/If-Modified-Since—untuk mendapatkan gambaran tentang cara kerjanya:

ETag/If-None-Match Last-Modified/If-Modified-Since
Respons server terhadap crawling: Ini adalah respons yang dapat digunakan crawler untuk menyimpan kolom header prasyarat ETag dan Last-Modified. 
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 4 Sep 1998 19:15:50 GMT
ETag: "34aa387-d-1568eb00"
...
 
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 4 Sep 1998 19:15:50 GMT
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT
Cache-Control: max-age=94043
...
Permintaan bersyarat crawler berikutnya: Permintaan bersyarat didasarkan pada nilai header prasyarat yang disimpan dari permintaan sebelumnya. Nilai dikirim kembali ke server untuk divalidasi di header permintaan If-None-Match dan If-Modified-Since. 
GET /hello.world HTTP/1.1
Host: www.example.com
Accept-Language: en, hu
User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)
If-None-Match: "34aa387-d-1568eb00"
...
 
GET /hello.world HTTP/1.1
Host: www.example.com
Accept-Language: en, hu
User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT
...
Respons server terhadap permintaan bersyarat: Karena nilai header prasyarat yang dikirim oleh crawler divalidasi di sisi server, server akan menampilkan kode status HTTP 304 (tanpa isi HTTP) ke crawler. Hal ini akan terjadi pada setiap permintaan berikutnya hingga prasyarat gagal divalidasi (perubahan tanggal ETag atau Last-Modified di sisi server). 
HTTP/1.1 304 Not Modified
Date: Fri, 4 Sep 1998 19:15:50 GMT
Expires: Fri, 4 Sep 1998 19:15:52 GMT
Vary: Accept-Encoding
If-None-Match: "34aa387-d-1568eb00"
...
 
HTTP/1.1 304 Not Modified
Date: Fri, 4 Sep 1998 19:15:50 GMT
Expires: Fri, 4 Sep 1998 19:15:51 GMT
Vary: Accept-Encoding
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT
...

Jika Anda ingin membuat pengguna senang dan mungkin juga ingin menghemat biaya hosting, hubungi penyedia hosting atau CMS, atau developer Anda tentang cara mengaktifkan cache HTTP untuk situs Anda. Setidaknya, pengguna akan lebih berterima kasih kepada Anda.

Jika ada hal lain yang perlu didiskusikan terkait penyimpanan cache, buka komunitas bantuan Pusat Penelusuran, dan jika ingin menyampaikan sesuatu terkait cara kami menyimpan cache, berikan masukan di dokumentasi tentang penyimpanan cache yang kami publikasikan bersamaan dengan postingan blog ini.

Diposting oleh Gary Illyes

Ingin mempelajari crawling lebih lanjut? Lihat seluruh seri Crawling Edisi Desember:

Artikel Pengingat tentang Robots: memperkenalkan seri baru

Senin, 24 Februari 2025 Terkadang kami mendapatkan pertanyaan tentang robots.txt, tag meta robots, serta fungsi kontrol yang ditawarkannya. Setelah meluncurkan seri artikel bulan Desember tentang crawling, kami rasa ini adalah waktu yang tepat untuk

Search Central Live akan hadir di New York City

Kamis, 13 Februari 2025 Dengan senang hati kami umumkan bahwa Search Central Live akan hadir di New York City untuk pertama kalinya pada 20 Maret 2025. Tim Google Penelusuran telah beberapa kali menyelenggarakan sejumlah acara di kota ini, tetapi

Menyederhanakan elemen URL yang terlihat di hasil penelusuran seluler

Kamis, 23 Januari 2025 Penelusur seluler akan segera melihat tampilan URL yang lebih ringkas dan sederhana di hasil penelusuran. Awalnya diperkenalkan sebagai bagian dari fitur "hierarki situs", kami mendapati bahwa elemen breadcrumb tidak terlalu