- 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.
Tekst przetłumaczony przez AI.
Podsumowanie posta wygenerowane przez AI durumis
- W celu efektywnego wykorzystania budżetu indeksowania Google, przeprowadziliśmy optymalizację prędkości przesyłania stron internetowych oraz wdrożyliśmy usługę przekierowań opartą na Cloud Run.
- Przenieśliśmy pliki statyczne, takie jak robots.txt, favicon.ico, oraz logikę przekierowań do Cloud Run, co pozwoliło na poprawę szybkości odpowiedzi z 200 ms do 20 ms w porównaniu do poprzedniego rozwiązania opartego na GKE Autopilot.
- Wdrożenie Cloud Run w różnych regionach na całym świecie umożliwia dostarczanie usług z serwerów najbliższych użytkownikom, co przekłada się na wyższą prędkość i redukcję kosztów.
Wszystkie usługi oparte na treściach dążą do wysokiej widoczności w wyszukiwarce Google.
Aby jednak pojawić się w wynikach wyszukiwania Google, roboty indeksujące muszą regularnie odwiedzać witrynę, pobierać najnowsze dane i prawidłowo je odzwierciedlać.
W tym celu, aby roboty indeksujące odwiedzały witrynę częściej, należy wykorzystać " budżet crawlowania" – im wyższy budżet, tym częstsze wizyty. Wymaga to jednak osiągnięcia pewnego poziomu ruchu na stronie.
W jaki sposób można zatem efektywnie wykorzystać ten ograniczony "budżet crawlowania", aby roboty indeksujące odwiedzały witrynę częściej przy tym samym budżecie?
Kluczem jest szybkie ładowanie stron witryny. Na przykład strona ładująca się w 20 ms będzie crawlowana częściej niż strona ładująca się w 200 ms.
Usługa Durumis (durumis) jest domyślnie zorientowana na "globalną obsługę", dlatego podstawowy ruch jest obsługiwany w 8 regionach na całym świecie.
Regiony serwerów GCP
Obecnie nasza usługa korzysta z 40 regionów Google Cloud – konkretnie z regionów w Azji (Seul, Singapur, Bombaj), Europie (Belgia), oraz w Stanach Zjednoczonych (Los Angeles, Karolina Południowa). Dzięki temu, niezależnie od lokalizacji użytkownika, połączenie jest zazwyczaj szybkie i stabilne.
Ze względu na wcześniej wspomniane powody, postanowiliśmy przeprowadzić dodatkowe dostrojenie, aby osiągnąć jeszcze większą prędkość.
Obecnie nasza usługa przechodzi proces zmiany z modelu adresów URL na nowy model z subdomenami, co wiąże się z pewnymi przekierowaniami (redirect). W związku z tym, duża liczba robotów indeksujących Google odwiedza te fragmenty witryny. Istnieje potrzeba szybkiego poinformowania Google o nowych adresach URL, zastępujących stare.
Dlatego też, aby w pełni wykorzystać dostępny budżet crawlowania, ruch generowany przez przekierowania musi być obsługiwany z maksymalną prędkością.
Dotychczas klaster GKE (Google Kubernetes Engine) był rozmieszczony w 8 wspomnianych regionach, a każdy klaster GKE korzystał z GKE Autopilot do obsługi przekierowań na podstawie danych niezwiązanych z bazą danych.
W związku z tym, zdecydowaliśmy się przenieść część logiki z klastra GKE oraz z istniejącej usługi Cloud Run do nowej instancji Cloud Run. Lista elementów do przeniesienia jest następująca:
- robots.txt: Chociaż jest to plik statyczny, to obsługuje on treści generowane dynamicznie w ramach określonej logiki dla wielu subdomen.
- favicon.ico: Czysto statyczny plik.
- durumis.com/[lang]/@userId/postID: Przekierowanie do nowego adresu URL –> userId.durumis.com/[lang]/postID
Wcześniej, gdy obsługa odbywała się za pośrednictwem nieco cięższej struktury w GKE Autopilot, czas odpowiedzi wynosił około 200 ms.
Nowe rozwiązanie wykorzystuje Cloud Run i ze względu na prostotę logiki nie wymaga frameworka. Zamiast tego, wykorzystuje bibliotekę node:http bez dodatkowych zależności.
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}/); });
( Powyższy kod nie zadziała wprost – jest to jedynie przykład ilustrujący koncepcję. )
W przypadku favicon.ico, który jest plikiem graficznym, zastosowano metodę wczytywania go z pliku i przechowywania w pamięci, a następnie przesyłania go do użytkownika.
Do wdrożenia w wielu regionach jednocześnie wykorzystano skrypt shellowy i narzędzie gcloud.
I oto efekt...
Oto wyniki wdrożenia:
Ekran Cloud Run
Wdrożenie zostało przeprowadzone we "wszystkich regionach" Stanów Zjednoczonych, a także w dwóch regionach w Europie, dwóch w Azji, jednym w Afryce i dwóch w Ameryce Południowej. Jest to zaleta rozwiązań Serverless – takie wdrożenie nie powoduje wzrostu kosztów. (Wręcz przeciwnie, obsługa ruchu z bliższych lokalizacji może prowadzić do obniżenia kosztów.)
A jak wpłynęło to na prędkość?
Poniżej przedstawiono wyniki prędkości odpowiedzi serwera przed optymalizacją.
GKE Autopilot
A oto wyniki po optymalizacji.
Wykorzystanie Cloud Run do plików statycznych
Można by pomyśleć, że w przypadku Cloud Run, będącego rozwiązaniem Serverless, wystąpią opóźnienia związane z zimnym startem. Jednakże, w przypadku regularnych żądań crawlowania, nie jest to znaczący problem. Jest to jedna z cech rozwiązań Serverless GCP – utrzymywanie stanu gotowości (Standby) i bezczynności (Idle), co pozwala na szybkie reagowanie na żądania. (Bez zwiększania kosztów.)
W następnym poście omówimy obsługę nie tylko małych plików statycznych lub przekierowań 301, ale także plików graficznych i innych typów danych.