- 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.
Текст, переведенный ИИ.
Резюме публикации от ИИ durumis
- Для эффективного использования бюджета сканирования Google мы улучшили скорость передачи веб-страниц и внедрили службу перенаправления на основе Cloud Run.
- Мы перенесли статические файлы, такие как robots.txt, favicon.ico, и логику перенаправления в Cloud Run, что позволило повысить скорость ответа с 200 мс до 20 мс по сравнению с предыдущим GKE Autopilot.
- Развертывание Cloud Run в различных регионах по всему миру обеспечивает предоставление услуг с ближайшего к пользователю сервера, что повышает скорость и снижает затраты.
Все сервисы, основная функция которых — предоставление контента, стремятся к высокой видимости в результатах поиска Google.
Однако для достижения видимости в поиске Google необходимо, чтобы поисковый робот (кроулер) часто посещал сайт, сканировал (кроулинговал) самые свежие данные и правильно их отражал в результатах поиска.
В этом случае, чтобы кроулер посещал веб-сайт чаще, используется понятие "бюджет сканирования" — чем выше бюджет, тем чаще робот будет посещать сайт. А для увеличения бюджета необходим определенный уровень трафика на сайт.
Как же эффективно использовать этот ограниченный "бюджет сканирования", чтобы при том же бюджете робот посещал сайт чаще?
Для этого необходимо ускорить передачу веб-страниц сайта. Например, сайт с временем загрузки страницы 20ms будет сканироваться роботом чаще, чем сайт с временем загрузки 200ms.
По умолчанию сервис durumis (Дурумис) ориентирован на "глобальное обслуживание", поэтому базовая трафика предоставляется из 8 регионов мира.
Регионы серверов GCP
В настоящее время наш сервис использует регионы из 40 регионов Google Cloud— в частности, регионы в Азии (Сеул, Сингапур, Мумбаи), Европе (Бельгия), Северной Америке (Лос-Анджелес, Южная Каролина). Это позволяет обеспечить быстрый доступ к сервису практически из любой точки мира.
Однако, по вышеуказанным причинам, мы решили произвести дополнительную настройку для достижения еще большей скорости.
В данный момент наш сервис проходит процесс перехода от старого формата URL к новому формату с использованием субдоменов, что приводит к появлению перенаправлений (Redirect). Из-за этого Googlebot (поисковый робот Google) часто посещает эти перенаправления. Нам необходимо, чтобы Google как можно быстрее узнал о новых URL и связал их со старыми.
Поэтому, для максимального использования выделенного бюджета сканирования, нам необходимо обеспечить максимально высокую скорость для трафика, связанного с перенаправлениями.
Ранее кластеры GKE располагались в 8 упомянутых регионах. Каждый кластер GKE использует технологию GKE Autopilot для обработки перенаправлений с использованием данных, которые не связаны с базой данных.
Поэтому мы решили перенести часть логики, которая располагалась в кластерах GKE и ранее в Cloud Run, в новый сервис Cloud Run. Список элементов, которые планируется перенести, следующий:
- robots.txt: Несмотря на то, что это статический файл, он обслуживается с использованием определенной логики на нескольких субдоменах.
- favicon.ico: Чисто статический файл.
- durumis.com/[lang]/@userId/postID: Перенаправление на новый URL —> userId.durumis.com/[lang]/postID
При использовании старого подхода, когда обработка осуществлялась с помощью относительно «тяжелого» фреймворка в GKE Autopilot, время ответа составляло около 200 мс.
В новом подходе мы используем Cloud Run, а так как логика очень простая, то не используем фреймворки, а применяем `node:http` без библиотек, используя базовый код.
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}/); });
( Код выше не будет работать, если просто скопировать его. Необходимо понимать только основную идею.)
В случае с `favicon.ico` это файл изображения, поэтому мы считываем его из файла и сохраняем в оперативной памяти. Затем, при запросе, отправляем его из памяти.
С помощью shell-скрипта и команды `gcloud` мы производим одновременную деплой (развертывание) в несколько регионов.
Вуаля..
Результаты деплоя представлены ниже:
Экран Cloud Run
Развертывание произведено во "всех регионах" США, а также в 2 регионах Европы, 2 регионах Азии, 1 регионе Африки и 2 регионах Южной Америки. Это одно из преимуществ Serverless — даже при таком развертывании затраты не увеличиваются. (Более того, если обслуживать трафик из ближайших регионов, то затраты могут даже снизиться.)
Итак, насколько же увеличилась скорость?
Результаты измерения скорости ответа сервера до оптимизации:
GKE Autopilot
Результаты измерения скорости ответа сервера после оптимизации:
Использование Cloud Run для статических файлов
Вы можете подумать: «Раз уж мы используем Cloud Run, то наверняка есть время холодного запуска (cold start)...» Но в ситуации, когда кроулер регулярно и часто сканирует сайт, это не является большой проблемой. Одна из особенностей Serverless в GCP — это постоянное переключение между состояниями «ожидание» (Standby) и «бездействие» (Idle). Таким образом, сервис постоянно готов к работе. (И при этом затраты не увеличиваются.)
В следующем посте мы расскажем не только о маленьких статических файлах и перенаправлениях 301, но и об обработке файлов изображений и других файлов.