- 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.
โพสต์นี้แปลโดย AI
บทสรุปของโพสต์โดย durumis AI
- เพื่อใช้ประโยชน์จากงบประมาณการคืบคลานของ Google Search อย่างมีประสิทธิภาพ เราได้ดำเนินการปรับปรุงความเร็วในการโหลดเว็บเพจและนำบริการเปลี่ยนเส้นทางที่ใช้ Cloud Run มาใช้
- ได้ย้ายไฟล์คงที่ เช่น robots.txt, favicon.ico และตรรกะการเปลี่ยนเส้นทางไปยัง Cloud Run ทำให้เวลาตอบสนองเร็วขึ้นจาก 200ms เป็น 20ms เมื่อเทียบกับ GKE Autopilot เดิม
- การปรับใช้ Cloud Run ในหลายภูมิภาคทั่วโลกช่วยให้สามารถให้บริการจากเซิร์ฟเวอร์ที่ใกล้กับตำแหน่งของผู้ใช้มากขึ้น ส่งผลให้ความเร็วในการเข้าถึงเพิ่มขึ้นและลดต้นทุนได้
บริการต่างๆ ที่มีเนื้อหาเป็นหลักนั้น ต่างก็ต้องการให้ Google แสดงผลการค้นหาอยู่เสมอ
แต่การจะให้ Google แสดงผลการค้นหาได้นั้น ระบบคืบคลาน (Crawler) ต้องเข้ามาเยี่ยมชมบ่อยๆ เพื่อดึงข้อมูลล่าสุด และนำไปแสดงผลให้ถูกต้อง
ในกรณีนี้ เพื่อให้ระบบคืบคลานเข้ามาเยี่ยมชมเว็บไซต์บ่อยขึ้น เราจะใช้ " งบประมาณการคืบคลาน (Crawl Budget)" ซึ่งหมายความว่ายิ่งมีงบประมาณสูง ระบบก็จะเข้ามาเยี่ยมชมบ่อยขึ้น และเพื่อให้ได้งบประมาณที่สูงขึ้นนั้น เว็บไซต์ก็ต้องมีปริมาณการเข้าชมในระดับหนึ่ง
แล้วเราจะใช้ "งบประมาณการคืบคลาน" ที่มีอยู่อย่างจำกัดนี้อย่างมีประสิทธิภาพอย่างไร เพื่อให้ระบบเข้ามาเยี่ยมชมบ่อยขึ้นในงบประมาณเท่าเดิมล่ะ?
นั่นก็คือ เว็บไซต์ต้องมีเวลาในการโหลดหน้าเว็บที่รวดเร็ว ยกตัวอย่างเช่น เว็บไซต์ที่มีเวลาในการดาวน์โหลดหน้าเว็บ 200 มิลลิวินาที จะถูกระบบคืบคลานเข้ามาเยี่ยมชมหน้าเว็บบ่อยกว่าเว็บไซต์ที่มีเวลาในการดาวน์โหลดหน้าเว็บ 20 มิลลิวินาที
โดยพื้นฐานแล้ว บริการของทาง ดุรุมิส (durumis) มีเป้าหมายที่จะเป็น "บริการระดับโลก" ดังนั้น เราจึงให้บริการการเข้าถึงผ่าน 8 ภูมิภาคทั่วโลก
ภูมิภาคเซิร์ฟเวอร์ GCP
ปัจจุบัน บริการของเราใช้ ภูมิภาคต่างๆ ของ Google ทั้ง 40 ภูมิภาค (40 regions of Google)โดยเลือกใช้ภูมิภาคในเอเชีย ได้แก่ กรุงโซล สิงคโปร์ มุมไบ ภูมิภาคในยุโรป ได้แก่ เบลเยียม และภูมิภาคในอเมริกา ได้แก่ ลอสแอนเจลิส และเซาท์แคโรไลนา ซึ่งหมายความว่าไม่ว่าผู้ใช้จะเข้าถึงจากที่ใดในโลก ก็สามารถเชื่อมต่อได้อย่างรวดเร็วโดยส่วนใหญ่
อย่างไรก็ตาม ด้วยเหตุผลที่กล่าวมาข้างต้น เราจึงตัดสินใจปรับแต่งให้เร็วขึ้นอีกขั้น
ปัจจุบัน บริการของเรากำลังอยู่ในขั้นตอนการเปลี่ยนแปลงโครงสร้าง URL จากรูปแบบเดิมไปเป็นรูปแบบใหม่ที่ใช้ Subdomain ซึ่งส่งผลให้มีการ Redirect อยู่บ้าง และมีการเข้าชมจากระบบคืบคลานของ Google เป็นจำนวนมาก เราจำเป็นต้องให้ Google รับรู้ถึง URL ใหม่ได้อย่างรวดเร็ว
ดังนั้น เพื่อใช้ประโยชน์จากงบประมาณการคืบคลานที่มีอยู่ให้สูงสุด เราจำเป็นต้องรักษาความเร็วในการ Redirect ให้เร็วที่สุดเท่าที่จะเป็นไปได้
เดิมที GKE ถูกติดตั้งอยู่ใน 8 ภูมิภาคที่กล่าวมาข้างต้น และแต่ละ GKE นั้นใช้ GKE Autopilot ของ Google (GKE Autopilot of Google)ในการดำเนินการ Redirect โดยไม่ต้องเชื่อมต่อกับฐานข้อมูล
ดังนั้น เราจึงตัดสินใจย้ายโค้ดบางส่วนจาก GKE และ Cloud Run เดิม ไปยัง Cloud Run ใหม่ รายการที่ต้องการย้ายมีดังนี้
- robots.txt: แม้จะเป็นไฟล์แบบคงที่ แต่ก็มีการส่งข้อมูลที่สร้างขึ้นจากโค้ดบางส่วนในหลายๆ Subdomain
- favicon.ico: ไฟล์คงที่ล้วนๆ
- durumis.com/[lang]/@userId/postID: การ Redirect ไปยัง URL ใหม่ -> userId.durumis.com/[lang]/postID
เดิมที เมื่อใช้ Framework ที่ค่อนข้างหนักใน GKE Autopilot เวลาในการตอบสนองอยู่ที่ประมาณ 200 มิลลิวินาที
วิธีการใหม่คือการใช้ Cloud Run และเนื่องจากโค้ดนั้นง่ายมาก จึงไม่จำเป็นต้องใช้ Framework และใช้ node:http โดยตรงโดยไม่ต้องใช้ไลบรารีใดๆ
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}/); });
( ห้ามคัดลอกโค้ดนี้ไปใช้งานโดยตรง โปรดทำความเข้าใจแนวคิดเท่านั้น )
ในกรณีของ favicon.ico เนื่องจากเป็นไฟล์รูปภาพ เราจึงเลือกใช้วิธีการโหลดจากไฟล์และเก็บไว้ในหน่วยความจำ แล้วส่งผ่านข้อมูลจากหน่วยความจำ
ใช้ Shell Script และ gcloud ในการติดตั้งพร้อมกันในหลายๆ ภูมิภาค
เสร็จแล้ว...
ผลลัพธ์หลังจากการติดตั้งมีดังนี้
หน้าจอ Cloud Run
เราได้ติดตั้งใน "ทุกภูมิภาค" ของอเมริกา และติดตั้งในแต่ละทวีป ยุโรป 2 ภูมิภาค เอเชีย 2 ภูมิภาค แอฟริกา 1 ภูมิภาค และอเมริกาใต้ 2 ภูมิภาค จริงๆ แล้วนี่คือข้อดีของ Serverless ที่แม้จะติดตั้งแบบนี้ แต่ก็ไม่มีค่าใช้จ่ายเพิ่มขึ้นเลย (ยิ่งถ้ามีการเข้าชมจากบริเวณใกล้เคียง ก็อาจทำให้ค่าใช้จ่ายลดลงด้วยซ้ำ)
มาดูกันว่าความเร็วเพิ่มขึ้นแค่ไหน
ความเร็วในการตอบสนองของเซิร์ฟเวอร์เดิมมีดังนี้
GKE Autopilot
ความเร็วหลังจากปรับปรุงมีดังนี้
การใช้ Cloud Run กับไฟล์ Static
คุณอาจสงสัยว่า Cloud Run เป็น Serverless ดังนั้นจึงต้องมีเวลาในการเริ่มต้น (Cold Start) ใช่ไหม...แต่ในกรณีที่มีการคืบคลานเข้ามาอย่างต่อเนื่องเป็นระยะเวลาหนึ่งนั้น จริงๆ แล้วไม่ใช่ปัญหาใหญ่ เนื่องจากเป็นหนึ่งในคุณสมบัติของ Serverless ของ GCP ที่จะสลับไปมาระหว่างสถานะ Standby และ Idle เพื่อรอการเข้าชม (และไม่ทำให้ค่าใช้จ่ายเพิ่มขึ้นด้วย)
ในโพสต์ถัดไป เราจะมาอธิบายเกี่ยวกับไฟล์แบบคงที่หรือ 301 Redirect ที่ไม่ใช่ไฟล์เล็กๆ น้อยๆ เช่นเดียวกับกรณีข้างต้น เช่น ไฟล์รูปภาพหรือไฟล์ประเภทอื่นๆ