- 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.
AI által fordított szöveg.
A bejegyzés durumis AI által generált összefoglalója
- A Google kereső crawl budget (keresési forgalom költségvetés) hatékonyabb felhasználása érdekében javítottuk a weboldalak betöltési sebességét, és bevezettünk egy Cloud Run alapú átirányítási szolgáltatást.
- A robots.txt, favicon.ico és egyéb statikus fájlok, valamint az átirányítási logika a Cloud Run-re való áthelyezésével a válaszidő 200 ms-ról 20 ms-ra csökkent a korábbi GKE Autopilot megoldáshoz képest.
- A Cloud Run globális elhelyezésének köszönhetően a felhasználók a hozzájuk legközelebb eső szerverről kapják a szolgáltatást, ami javítja a sebességet és csökkenti a költségeket.
Minden olyan szolgáltatás, amely a tartalomra fókuszál, szeretne minél többet megjelenni a Google keresési eredményeiben.
A Google keresési találati listáján való megjelenéshez azonban a crawlernek gyakran kell látogatnia a webhelyet a legfrissebb adatok betöltéséhez, és ezeket megfelelően tükröznie kell.
A crawler webhelyre történő gyakrabbi látogatásának elősegítéséhez a "kúszási költségvetés" fogalmát használhatjuk, amely azt jelenti, hogy minél nagyobb a költségvetés, annál gyakrabban látogatja a crawler a webhelyet. Ehhez azonban a webhelynek kellő mennyiségű forgalommal kell rendelkeznie.
Hogyan használhatjuk ki hatékonyan ezt a korlátozott "kúszási költségvetést", hogy ugyanannyi költségvetéssel a crawler gyakrabban látogassa a webhelyünket?
A webhely weboldalainak betöltési sebességének gyorsnak kell lennie. Például egy olyan webhely, amelynek az oldala 200 ms alatt töltődik be, kevesebbszer lesz becsúszva, mint egy olyan, amelynek oldala 20 ms alatt töltődik be.
A durumis alapvetően "globális szolgáltatásra" törekszik, ezért 8 globális régióban biztosítja az alapvető forgalmat.
GCP szerver régiók
Jelenleg a szolgáltatásunk a Google 40 régiójánakegyikéből, nevezetesen Ázsiában a szöuli, szingapúri és mumbai, Európában a belga, Amerikában a Los Angeles-i és Dél-Karolinai régióból használja a forgalmat. Ez azt jelenti, hogy gyakorlatilag bárhonnan a világon elérhető a szolgáltatásunk, és a sebesség általában nem jelent problémát.
A fenti okok miatt azonban úgy döntöttünk, hogy a sebességet még tovább optimalizáljuk.
Jelenleg a szolgáltatásunk átalakul a URL-alapú rendszerből új al-domain rendszerre, ami miatt némi átirányítás (Redirect) van jelen, és a Google crawlerjei gyakran látogatják ezeket a részeket. Fontos, hogy a Google gyorsan felismerje a régi URL-eket az új URL-ekkel.
Ezért a rendelkezésre álló kúszási költségvetés maximális kihasználása érdekében az átirányításra használt forgalomnak a lehető leggyorsabbnak kell lennie.
Korábban a fent említett 8 régióban volt GKE telepítve, és mindegyik GKE a Google GKE Autopilot funkcióját használta az adatbázissal nem kapcsolatos adatok átirányítására.
Ezért úgy döntöttünk, hogy a GKE-n és a korábbi Cloud Run-en futó néhány logikát új Cloud Run környezetbe helyezzük át. Az áthelyezendő elemek a következők:
- robots.txt: Bár statikus fájl, de több al-domainen is dinamikus tartalommal látja el a felhasználókat.
- favicon.ico: Teljesen statikus fájl.
- durumis.com/[lang]/@userId/postID: Átirányítás új URL-re -> userId.durumis.com/[lang]/postID
Korábban, amikor a GKE Autopilot egy kissé nehezebb keretrendszeren keresztül szolgáltatta a tartalmat, a válaszidő körülbelül 200 ms volt.
Az új megoldás a Cloud Run használatán alapul, és mivel a logika nagyon egyszerű, nem használunk keretrendszert, hanem a node:http-t és a beépített kódot, külső könyvtárak nélkül.
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}/); });
( Ha ezt a kódot beilleszti, nem fog működni. Csak az alapötletet kell megérteni. )
A favicon.ico esetében, mivel képállományról van szó, betöltjük a fájlból a memóriába, és onnan küldjük el a felhasználónak.
Shell script segítségével a gcloud-ot használva több régióba is egyidejűleg telepítjük a kódot.
Íme...
A telepítés eredménye a következő:
Cloud Run felület
Az Egyesült Államok "összes régiójába" telepítettük, valamint Európában 2, Ázsiában 2, Afrikában 1 és Dél-Amerikában 2 régióba. Ez a Serverless előnye, hogy még ha így telepítjük is, a költségek nem növekednek. ( Sőt, ha a forgalom a közelebbi régiókban keletkezik, akkor akár csökkenhetnek is a költségek. )
Nézzük meg, hogy mennyivel lett gyorsabb a sebesség.
A szerver oldali válaszidő a telepítés előtt a következő volt:
GKE Autopilot
A fejlesztett sebesség a következő:
Statikus fájlok kiszolgálása Cloud Run használatával
Természetesen a Cloud Run Serverless rendszer, így van hidegindítási ideje. De ha folyamatosan érkeznek a crawler lekérdezései, akkor ez nem jelentős probléma. Ez a GCP Serverless funkcióinak egyik jellemzője: a rendszer várakozási és inaktív állapot között vált, miközben készenlétben van. ( És nem növeli a költségeket sem. )
A következő bejegyzésben a statikus fájlok és a 301-es átirányítások mellett a képfájlokra és egyéb fájlokra vonatkozó megoldásokat fogjuk bemutatni.