- 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.
Texto traduzido pela IA.
Resumo do texto pela IA do durumis
- Para usar o orçamento de rastreamento do Google de forma eficiente, melhoramos a velocidade de transferência da página da web e implementamos um serviço de redirecionamento baseado no Cloud Run.
- Movemos arquivos estáticos como robots.txt, favicon.ico e a lógica de redirecionamento para o Cloud Run, o que melhorou a velocidade de resposta de 200ms para 20ms em comparação com o GKE Autopilot existente.
- Por meio da implantação do Cloud Run em várias regiões do mundo, fornecemos serviços de servidores mais próximos da localização do usuário, o que resultou em maior velocidade e redução de custos.
Todos os serviços que hospedam conteúdo desejam ter uma alta visibilidade nas buscas do Google.
No entanto, para aparecer nas buscas do Google, é necessário que o rastreador (crawler) visite o site com frequência para coletar os dados mais recentes e que o site reflita essas informações de forma eficiente.
Nesse contexto, para que o rastreador acesse o site com mais frequência, utiliza-se o conceito de "Orçamento de Rastreamento" que, se maior, permite um acesso mais frequente. Para isso, o site precisa gerar um tráfego considerável.
Então, como otimizar o uso desse "Orçamento de Rastreamento" limitado para que o rastreador acesse o site com mais frequência com o mesmo orçamento?
A resposta é: a velocidade de carregamento das páginas do site precisa ser alta. Por exemplo, um site com tempo de download de página de 20ms será rastreado com mais frequência do que um site com tempo de 200ms.
O Durumis (두루미스) tem como objetivo ser um "serviço global", por isso, oferecemos serviços de tráfego básico em 8 regiões do mundo.
Região do Servidor GCP
Atualmente, nosso serviço utiliza as regiões de 40 regiões do Googlelocalizadas em Seul e Singapura (Ásia), Mumbai (Índia), Bélgica (Europa), Los Angeles e Carolina do Sul (EUA). Isso garante que, independentemente de onde o usuário acesse, a conexão seja rápida na maioria dos casos.
No entanto, pelos motivos mencionados anteriormente, decidimos realizar algumas otimizações para alcançar uma velocidade ainda maior.
Atualmente, nosso serviço está passando por um processo de mudança da estrutura de URL tradicional para uma nova estrutura com subdomínios, o que resulta em alguns redirecionamentos (redirects). Essas páginas de redirecionamento recebem muitas visitas de rastreadores do Google. Precisamos garantir que o Google reconheça rapidamente a nova URL.
Portanto, para aproveitar ao máximo o orçamento de rastreadores disponível, é essencial que o tráfego de redirecionamento seja mantido com a velocidade mais alta possível.
Anteriormente, o GKE estava implantado nas 8 regiões mencionadas, e cada instância do GKE utilizava o GKE Autopilot do Google para realizar os redirecionamentos usando dados que não estavam vinculados ao banco de dados.
Portanto, decidimos migrar algumas partes do código que estavam no GKE e em outros serviços Cloud Run para um novo ambiente Cloud Run. A lista de itens a serem migrados é a seguinte:
- robots.txt: embora seja um arquivo estático, ele serve conteúdo gerado dinamicamente por meio de lógica específica em vários subdomínios.
- favicon.ico: arquivo estático puro.
- durumis.com/[lang]/@userId/postID: redirecionamento para nova URL -> userId.durumis.com/[lang]/postID
Anteriormente, quando o serviço era executado por meio de uma estrutura um pouco mais complexa no GKE Autopilot, o tempo de resposta era de cerca de 200ms.
A nova abordagem utiliza o Cloud Run, e como a lógica é muito simples, não utilizamos nenhuma estrutura (framework) e, em vez disso, empregamos o node:http sem nenhuma biblioteca, utilizando apenas o código básico.
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}/); });
( O código acima não funcionará se for copiado e colado diretamente. É apenas para fins ilustrativos.)
No caso do favicon.ico, como é um arquivo de imagem, optamos por carregá-lo do sistema de arquivos e armazená-lo na memória para posterior transmissão.
Utilizamos um script shell e o comando gcloud para implantar simultaneamente em várias regiões.
Voilà...
O resultado da implantação é o seguinte:
Tela do Cloud Run
Implantamos em "todas as regiões" dos EUA e, em cada continente, implantamos em 2 regiões da Europa, 2 da Ásia, 1 da África e 2 da América do Sul. Na verdade, essa é uma das vantagens do Serverless, pois essa implantação em várias regiões não aumenta o custo. (Na verdade, se o tráfego for direcionado para regiões mais próximas, o custo pode até diminuir.)
Agora, qual foi a melhora na velocidade?
O tempo de resposta do servidor anterior era o seguinte:
GKE Autopilot
E o tempo de resposta após a melhoria é o seguinte:
Arquivo Estático Utilizando Cloud Run
É compreensível que você possa pensar que o Cloud Run, por ser Serverless, tem tempo de inicialização a frio (cold start). No entanto, em situações onde há acesso frequente e constante de rastreadores, esse fator não é um grande problema. Essa é uma das características do Serverless do GCP, pois o sistema alterna entre os estados Standby e Idle, permanecendo em espera. (E sem aumento de custo.)
Em uma próxima publicação, abordaremos outros tipos de arquivos, como imagens e outros tipos de conteúdo, não apenas arquivos estáticos pequenos ou redirecionamentos 301.