- Crawl Budget Management For Large Sites | Google Search Central | Documentation | Google for Developers
- Learn what crawl budget is and how you can optimize Google's crawling of large and frequently updated websites.
Teks yang diterjemahkan oleh AI.
Ringkasan posting oleh durumis AI
- Untuk menggunakan anggaran crawling Google Search secara efisien, kami telah meningkatkan kecepatan pengiriman halaman web dan menerapkan layanan Redirect berbasis Cloud Run.
- File statis seperti robots.txt, favicon.ico, dan logika pengalihan telah dipindahkan ke Cloud Run untuk meningkatkan kecepatan respons dari 200ms menjadi 20ms dibandingkan dengan GKE Autopilot sebelumnya.
- Dengan menyebarkan Cloud Run ke berbagai wilayah di seluruh dunia, kami dapat memberikan layanan dari server yang lebih dekat dengan lokasi pengguna, sehingga meningkatkan kecepatan dan mengurangi biaya.
Semua layanan yang berfokus pada konten ingin mendapatkan eksposur yang tinggi di hasil pencarian Google.
Namun, untuk muncul di hasil pencarian Google, crawler harus sering mengunjungi situs web, melakukan crawling data terbaru, dan merefleksikannya dengan baik.
Pada saat ini, agar crawler lebih sering mengunjungi situs web, kita dapat memanfaatkan " Anggaran Crawling" dengan alokasi anggaran yang lebih tinggi untuk kunjungan yang lebih sering. Untuk itu, situs web perlu memiliki lalu lintas yang cukup.
Lalu, bagaimana cara memanfaatkan "anggaran crawling" yang terbatas ini secara efisien agar crawler dapat mengunjungi situs web lebih sering dengan alokasi anggaran yang sama?
Jawabannya adalah dengan mempercepat kecepatan pengiriman halaman web situs web. Misalnya, situs web dengan waktu unduh halaman 20ms akan lebih sering di-crawl daripada situs web dengan waktu unduh halaman 200ms.
Secara fundamental, durumis (두루미스) bertujuan untuk menjadi "layanan global", sehingga kami menyediakan layanan lalu lintas dasar di 8 wilayah global.
Wilayah Server GCP
Saat ini, layanan kami secara dasar memanfaatkan 40 wilayah Google , khususnya wilayah Seoul dan Singapura di Asia, Mumbai, Belgia di Eropa, Los Angeles, dan South Carolina di Amerika Serikat. Dengan demikian, akses dari mana pun di dunia cenderung tetap cepat.
Namun, karena alasan yang telah dijelaskan sebelumnya, kami memutuskan untuk melakukan sedikit penyetelan lebih lanjut untuk mencapai kecepatan yang lebih ekstrem.
Saat ini, layanan kami sedang dalam proses transisi dari skema URL awal ke skema subdomain baru, sehingga terdapat beberapa pengalihan (Redirect) yang menyebabkan banyak kunjungan dari crawler Google. Kami perlu membuat Google mengenali URL baru dengan cepat.
Oleh karena itu, untuk memaksimalkan penggunaan anggaran crawling yang diberikan, lalu lintas pengalihan perlu dipertahankan kecepatannya secepat mungkin.
Sebelumnya, GKE ditempatkan di 8 wilayah yang disebutkan di atas, dan masing-masing GKE menggunakan GKE Autopilot Google untuk melakukan pengalihan menggunakan data yang tidak terhubung dengan basis data.
Oleh karena itu, kami memutuskan untuk memindahkan beberapa logika yang ada di GKE dan Cloud Run ke Cloud Run yang baru. Berikut adalah daftar yang akan dipindahkan:
- robots.txt: Meskipun merupakan file statis, file ini melayani konten yang dihasilkan dari beberapa logika di berbagai subdomain.
- favicon.ico: File statis murni.
- durumis.com/[lang]/@userId/postID: Pengalihan ke URL baru -> userId.durumis.com/[lang]/postID
Sebelumnya, ketika disajikan melalui kerangka kerja yang agak berat di GKE Autopilot, waktu responsnya sekitar 200ms.
Metode baru memanfaatkan Cloud Run, dan karena logikanya sangat sederhana, kami tidak menggunakan kerangka kerja dan menggunakan node:http tanpa pustaka, hanya dengan kode dasar.
const http = require("http"); const fs = require("fs"); const path = require("path"); let cachedFavicon = null; function loadFavicon() { const faviconPath = path.join(__dirname, "favicon.ico"); try { cachedFavicon = fs.readFileSync(faviconPath); console.log("Favicon loaded into memory"); } catch (err) { console.error("Error loading favicon:", err); } } --- 생략 --- const server = http.createServer((req, res) => { if (req.url === "/favicon.ico") { res.writeHead(200, { "Content-Type": "image/x-icon", "Cache-Control": "public,max-age=2419200" } res.end(cachedFavicon); }); server.listen(port, () => { console.log(Server running at http://localhost:${port}/); });
( Kode di atas tidak akan berfungsi jika dijalankan begitu saja. Anda hanya perlu memahami konsep dasarnya.)
Untuk favicon.ico, karena merupakan file gambar, kami memilih untuk memuatnya dari file, menyimpannya di memori, dan mengirimkannya menggunakan metode tersebut.
Kami menggunakan shell script dan gcloud untuk melakukan penyebaran secara bersamaan ke beberapa wilayah.
Taraa...
Hasil penyebaran ditunjukkan di bawah ini.
Layar Cloud Run
Kami melakukan penyebaran ke "semua wilayah" di Amerika Serikat dan beberapa wilayah di setiap benua: 2 di Eropa, 2 di Asia, 1 di Afrika, dan 2 di Amerika Selatan. Ini sebenarnya merupakan keuntungan dari Serverless, karena biaya tidak akan meningkat meskipun kita melakukan penyebaran seperti ini. ( Bahkan, biaya bisa berkurang jika kita melayani lalu lintas dari lokasi yang tidak terlalu jauh.)
Nah, seberapa cepat kecepatannya setelah dilakukan perubahan ini?
Berikut adalah waktu respons server sebelumnya.
GKE Autopilot
Berikut adalah kecepatan setelah perbaikan.
Cloud Run yang Digunakan untuk File Statis
Tentu saja, Anda mungkin berpikir bahwa Cloud Run sebagai layanan Serverless pasti memiliki waktu mulai dingin (cold start), tetapi dalam situasi di mana crawling terjadi secara berkala, ini tidak menjadi masalah yang signifikan. Ini adalah salah satu karakteristik Serverless di GCP, di mana layanan beralih antara mode Standby dan Idle sambil menunggu permintaan. ( Dan biaya tidak akan meningkat.)
Pada postingan berikutnya, saya akan menjelaskan tentang penanganan file selain file statis kecil atau pengalihan 301, seperti file gambar atau file lainnya.