- 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.
Texte traduit par l'IA.
Résumé du texte par durumis AI
- Afin d'utiliser efficacement le budget d'exploration de Google Search, nous avons amélioré la vitesse de transfert des pages Web et mis en place un service de redirection basé sur Cloud Run.
- Nous avons déplacé les fichiers statiques tels que robots.txt, favicon.ico et la logique de redirection vers Cloud Run, ce qui a permis d'améliorer la vitesse de réponse de 200 ms à 20 ms par rapport à GKE Autopilot existant.
- Le déploiement de Cloud Run dans diverses régions du monde permet de fournir des services à partir de serveurs situés à proximité de l'emplacement de l'utilisateur, ce qui améliore la vitesse et réduit les coûts.
Tous les services qui proposent du contenu souhaitent être largement visibles dans les résultats de recherche Google.
Cependant, pour apparaître dans les résultats de recherche Google, il est essentiel que les robots d'exploration (crawlers) visitent fréquemment le site Web afin de récupérer les données les plus récentes et que ces données soient correctement indexées.
Pour encourager les robots d'exploration à visiter un site Web plus souvent, il est possible d'utiliser le concept de "budget d'exploration" qui, s'il est plus élevé, permet aux robots d'exploration de visiter le site plus fréquemment. Pour ce faire, le site doit générer un certain trafic.
Comment optimiser l'utilisation de ce "budget d'exploration" limité pour maximiser la fréquence des visites des robots d'exploration ?
Il faut que la vitesse de chargement des pages Web du site soit rapide. Par exemple, un site avec un temps de téléchargement de 20 ms sera exploré plus fréquemment qu'un site avec un temps de téléchargement de 200 ms.
Par défaut, les services de Durumis sont conçus pour être "globaux". Ils sont donc disponibles dans 8 régions du monde pour un trafic de base.
Région de serveur GCP
Actuellement, nos services utilisent les régions suivantes parmi les 40 régions de Google Cloud : Séoul et Singapour en Asie, Mumbai en Inde, la Belgique en Europe, Los Angeles et la Caroline du Sud aux États-Unis. Ainsi, quel que soit l'endroit où l'utilisateur se connecte dans le monde, la connexion est généralement rapide.
Cependant, pour des raisons évoquées précédemment, nous avons décidé d'optimiser encore plus la vitesse.
Actuellement, nos services sont en cours de transition d'une URL classique vers une nouvelle approche basée sur des sous-domaines. Cela implique des redirections (redirects) et une augmentation des visites des robots d'exploration Google sur ces parties du site. Il est important que Google reconnaisse rapidement les nouvelles URL à partir des anciennes.
Par conséquent, pour tirer le meilleur parti du budget d'exploration alloué, il est essentiel de maintenir une vitesse maximale pour le trafic lié aux redirections.
Initialement, les 8 régions mentionnées hébergeaient des instances GKE (Google Kubernetes Engine). Chaque instance GKE utilise GKE Autopilot pour gérer les redirections sans interaction avec la base de données.
Nous avons donc décidé de migrer certaines parties du code situées sur GKE et Cloud Run vers une nouvelle instance Cloud Run. La liste des éléments à migrer est la suivante :
- robots.txt : Bien qu'il s'agisse d'un fichier statique, il sert du contenu généré dynamiquement à partir de différents sous-domaines.
- favicon.ico : Fichier statique.
- durumis.com/[lang]/@userId/postID : Redirection vers une nouvelle URL -> userId.durumis.com/[lang]/postID
Initialement, avec le framework relativement lourd hébergé sur GKE Autopilot, le temps de réponse était d'environ 200 ms.
La nouvelle solution utilise Cloud Run, et étant donné la simplicité des tâches, nous avons choisi de ne pas utiliser de framework et de nous appuyer sur `node:http` sans librairie, en utilisant le code de 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}/); });
( Ce code ne fonctionnera pas tel quel. Il ne sert qu'à illustrer le concept. )
Pour `favicon.ico`, étant donné qu'il s'agit d'un fichier image, nous avons opté pour une approche où le fichier est chargé en mémoire et servi à partir de celle-ci.
Nous utilisons un script shell et `gcloud` pour déployer simultanément sur plusieurs régions.
Et voilà...
Voici les résultats du déploiement :
Écran Cloud Run
Le déploiement a été effectué sur "toutes les régions" des États-Unis, ainsi que sur 2 régions en Europe, 2 en Asie, 1 en Afrique et 2 en Amérique du Sud. L'un des avantages de Serverless est que ce type de déploiement n'entraîne aucune augmentation des coûts. (En fait, si le trafic provient d'une région proche, les coûts peuvent même diminuer.)
Maintenant, voyons à quel point la vitesse a été améliorée.
Voici les performances du serveur avant l'optimisation :
GKE Autopilot
Et voici les performances après l'optimisation :
Fichier statique utilisant Cloud Run
Vous vous demandez peut-être si le temps de démarrage à froid (cold start) de Cloud Run, étant donné sa nature Serverless, n'est pas un problème. Cependant, dans un contexte où les robots d'exploration visitent le site régulièrement, ce n'est pas vraiment un problème. C'est l'une des caractéristiques de Serverless sur GCP : les instances passent d'un état d'attente (Standby) à un état inactif (Idle) en attendant les requêtes. (Et cela n'entraîne aucune augmentation des coûts.)
Dans un prochain article, nous aborderons les aspects liés aux fichiers autres que les petits fichiers statiques ou les redirections 301, comme les images et autres types de fichiers.