- 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.
Testo tradotto dall'IA.
Riepilogo del post generato dall'IA di durumis
- Per utilizzare in modo efficiente il budget di scansione di Google Search, abbiamo migliorato la velocità di trasmissione delle pagine web e implementato un servizio di reindirizzamento basato su Cloud Run.
- Abbiamo trasferito su Cloud Run i file statici come robots.txt, favicon.ico e la logica di reindirizzamento, migliorando la velocità di risposta da 200 ms a 20 ms rispetto al precedente GKE Autopilot.
- La distribuzione di Cloud Run in diverse regioni globali consente di fornire il servizio dal server più vicino alla posizione dell'utente, migliorando la velocità e riducendo i costi.
Tutti i servizi che si basano su contenuti desiderano ottenere una maggiore visibilità nei risultati di ricerca di Google.
Tuttavia, per apparire nei risultati di ricerca di Google, è necessario che i crawler visitino frequentemente il sito Web per eseguire il crawling dei dati più recenti e che questi dati vengano correttamente indicizzati.
A questo punto, per incoraggiare i crawler a visitare il sito Web più spesso, è possibile sfruttare il concetto di "budget di crawl" che, se più elevato, permette ai crawler di visitare il sito più frequentemente. Per ottenere un budget di crawl più alto, è necessario generare un certo traffico sul sito.
Come possiamo quindi ottimizzare l'utilizzo di questo "budget di crawl" limitato per ottenere un numero maggiore di visite da parte dei crawler con lo stesso budget?
È fondamentale garantire una velocità di trasferimento delle pagine Web elevata. Ad esempio, un sito con un tempo di download della pagina di 20ms verrà crawlato più frequentemente rispetto a un sito con un tempo di download di 200ms.
Il servizio durumis punta fondamentalmente ad essere un "servizio globale" e, per questo motivo, offre un servizio di base con traffico da 8 regioni in tutto il mondo.
Regioni server GCP
Attualmente, il nostro servizio utilizza40 regioni di Google Cloudtra cui le regioni di Seul, Singapore e Mumbai in Asia, Belgio in Europa, Los Angeles e South Carolina negli Stati Uniti. In questo modo, indipendentemente da dove ci si connette da tutto il mondo, è possibile garantire una connessione generalmente rapida.
Tuttavia, per i motivi sopra menzionati, abbiamo deciso di eseguire un'ulteriore ottimizzazione per ottenere velocità ancora maggiori.
Attualmente, il nostro servizio sta passando da un sistema di URL tradizionale a un nuovo sistema basato su sottodomini, con conseguenti alcuni redirect. Questa operazione sta generando molte visite da parte dei crawler di Google. È fondamentale far sì che Google riconosca rapidamente i nuovi URL al posto di quelli vecchi.
Pertanto, per sfruttare al massimo il budget di crawl disponibile, è necessario mantenere la massima velocità possibile per il traffico generato dai redirect.
In precedenza, i 8 GKE (Google Kubernetes Engine) menzionati erano distribuiti nelle 8 regioni, e ognuno di essi utilizzava GKE Autopilot di Google per gestire i redirect senza utilizzare il database.
Pertanto, abbiamo deciso di trasferire su una nuova istanza di Cloud Run alcuni dei codici presenti nei GKE e in altre istanze di Cloud Run esistenti. L'elenco degli elementi da trasferire è il seguente:
- robots.txt: si tratta di un file statico, ma diversi sottodomini servono contenuti generati dinamicamente.
- favicon.ico: file statico puro
- durumis.com/[lang]/@userId/postID: reindirizzamento a un nuovo URL -> userId.durumis.com/[lang]/postID
In precedenza, quando il servizio veniva erogato tramite un framework leggermente più complesso su GKE Autopilot, il tempo di risposta era di circa 200ms.
Il nuovo approccio prevede l'utilizzo di Cloud Run e, poiché la logica è molto semplice, non abbiamo utilizzato alcun framework, optando per "node:http" senza librerie e utilizzando solo il codice base.
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}/); });
( Il codice sopra non funzionerà così com'è. Serve solo per comprendere il concetto.)
Nel caso di favicon.ico, trattandosi di un file immagine, abbiamo scelto di caricarlo da un file, mantenerlo in memoria e utilizzarlo per la trasmissione.
Utilizzando uno script shell e gcloud, possiamo distribuire contemporaneamente su diverse regioni.
Ecco fatto..
Di seguito sono riportati i risultati della distribuzione.
Schermata Cloud Run
Abbiamo distribuito il servizio in "tutte le regioni" degli Stati Uniti e in altre 2 regioni in Europa, 2 in Asia, 1 in Africa e 2 in Sud America. Questo è uno dei vantaggi del Serverless: anche distribuendo il servizio in così tante regioni, i costi non aumentano (anzi, se il traffico proviene da una regione vicina, i costi potrebbero anche diminuire).
Vediamo ora quanto è aumentata la velocità.
Di seguito è riportato il tempo di risposta del server precedente.
GKE Autopilot
Di seguito è riportato il tempo di risposta dopo l'ottimizzazione.
File statici con Cloud Run
Potreste pensare che, trattandosi di Cloud Run, ci sia il problema del tempo di avvio a freddo (cold start). Tuttavia, dato che i crawler accedono al sito a intervalli regolari, questo problema non si presenta. Questa è una delle caratteristiche del Serverless di GCP: il sistema passa da uno stato di Standby a Idle in attesa di richieste, senza alcun aumento dei costi.
Nel prossimo articolo, invece di trattare file statici o redirect 301 come in questo caso, parleremo di come gestire immagini e altri tipi di file.