- 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.
Dies ist eine KI-übersetzte Version.
Zusammenfassung des Beitrags durch durumis AI
- Um das Google-Such-Crawl-Budget effizienter zu nutzen, haben wir die Übertragungsgeschwindigkeit von Webseiten verbessert und einen Redirect-Service basierend auf Cloud Run eingeführt.
- Durch die Verlagerung statischer Dateien wie robots.txt, favicon.ico und der Redirect-Logik auf Cloud Run konnten wir die Antwortzeit im Vergleich zu GKE Autopilot von 200 ms auf 20 ms verbessern.
- Durch die Bereitstellung von Cloud Run in verschiedenen Regionen weltweit können wir den Dienst von Servern bereitstellen, die sich in der Nähe des Benutzerstandorts befinden, was zu einer höheren Geschwindigkeit und Kostensenkung führt.
Alle Dienste, die sich auf die Bereitstellung von Inhalten konzentrieren, möchten in der Google-Suche gut sichtbar sein.
Um in der Google-Suche angezeigt zu werden, ist es jedoch erforderlich, dass der Crawler häufig die Website besucht, die neuesten Daten crawlt und diese korrekt widerspiegelt.
Um den Crawler dazu zu bringen, die Website häufiger zu besuchen, kann man das sogenannte "Crawl-Budget" nutzen. Ein höheres Budget führt zu häufigeren Besuchen, wofür die Website einen gewissen Traffic generieren muss.
Wie kann man dieses begrenzte "Crawl-Budget" nun effizient nutzen, um bei gleichem Budget häufiger besucht zu werden?
Die Website muss schnell laden. Beispielsweise wird eine Website mit einer Seitenladezeit von 20ms häufiger gecrawlt als eine Website mit einer Ladezeit von 200ms.
Grundsätzlich strebt durumis (두루미스) einen "globalen Service" an und bietet daher grundlegenden Traffic aus 8 Regionen weltweit an.
GCP Serverregionen
Derzeit nutzt unser Service aus den 40 Regionen von Googledie Regionen Seoul und Singapur in Asien, Mumbai in Indien, Belgien in Europa sowie Los Angeles und South Carolina in den USA. Egal, von wo aus auf die Website zugegriffen wird, die Verbindung sollte in den meisten Fällen schnell und stabil sein.
Aufgrund der oben genannten Gründe haben wir uns jedoch entschieden, die Performance noch weiter zu optimieren.
Aktuell befindet sich unser Service in einem Übergang von der bisherigen URL-Struktur zu einer neuen Subdomain-Struktur. Es gibt daher einige Weiterleitungen (Redirects), die viele Google-Crawler anziehen. Wir müssen Google schnell über die neuen URLs informieren, da die alten URLs durch die neuen ersetzt werden sollen.
Um das vorgegebene Crawl-Budget optimal zu nutzen, müssen wir daher den Traffic der Weiterleitungen so schnell wie möglich bereitstellen.
Bisher waren die GKE-Instanzen in den oben genannten 8 Regionen verteilt und nutzten jeweils Googles GKE Autopilotum Weiterleitungen basierend auf Daten zu realisieren, die nicht mit der Datenbank verbunden sind.
Daher haben wir uns entschieden, einige Logiken, die sich in den GKE-Instanzen und einigen Cloud Run-Instanzen befanden, in eine neue Cloud Run-Instanz zu verschieben. Die zu verschiebende Liste sieht wie folgt aus:
- robots.txt: Obwohl es sich um eine statische Datei handelt, werden verschiedene Inhalte aus verschiedenen Subdomains mit einer bestimmten Logik bereitgestellt.
- favicon.ico: Reine statische Datei
- durumis.com/[lang]/@userId/postID: Weiterleitung (Redirect) zur neuen URL -> userId.durumis.com/[lang]/postID
Wenn die Bereitstellung über das etwas schwergewichtigere Framework in GKE Autopilot erfolgte, lag die Antwortzeit bei etwa 200ms.
Die neue Methode nutzt Cloud Run und da die Logik sehr einfach ist, wird kein Framework verwendet. Stattdessen wird node:http ohne Bibliotheken verwendet und nur der Basiscode wird verwendet.
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}/); });
(Wenn Sie den obigen Code unverändert einfügen, funktioniert er nicht. Sie sollten nur das grundlegende Konzept verstehen.)
Da es sich bei favicon.ico um eine Bilddatei handelt, wird sie aus der Datei geladen, im Speicher abgelegt und dann zum Versand verwendet.
Mit einem Shell-Skript wird gcloud verwendet, um die Bereitstellung gleichzeitig in mehreren Regionen durchzuführen.
Voilà..
Das Ergebnis der Bereitstellung sieht wie folgt aus:
Cloud Run Ansicht
Die Bereitstellung erfolgte in "allen Regionen" der USA sowie in 2 Regionen in Europa, 2 Regionen in Asien, 1 Region in Afrika und 2 Regionen in Südamerika. Das ist einer der Vorteile von Serverless: Selbst wenn man die Bereitstellung so ausführt, steigen die Kosten nicht an. (Wenn Traffic aus der Nähe bereitgestellt wird, können die Kosten sogar sinken.)
Wie viel schneller ist die Website nun geworden?
Die Antwortzeit des vorherigen Servers sah wie folgt aus:
GKE Autopilot
Die verbesserte Geschwindigkeit sieht wie folgt aus:
Cloud Run zur Bereitstellung statischer Dateien
Man könnte denken, dass Cloud Run aufgrund des Serverless-Konzepts eine Kaltstartzeit hat. Bei regelmäßigem Crawling ist dies jedoch kein großes Problem. Eine der Eigenschaften von GCP Serverless ist, dass die Instanzen zwischen Standby und Idle wechseln und im Hintergrund warten. (Es entstehen auch keine zusätzlichen Kosten.)
Im nächsten Beitrag werde ich nicht nur kleine statische Dateien oder 301-Weiterleitungen (Redirects) behandeln, sondern auch Bilddateien und andere Dateien.