구글은 5초 후 렌더링을 중단하지 않는다: WRS의 시간 관리 방식

핵심

5초 렌더링 제한설은 거짓이다. 다만 그런 통설이 생긴 이유는 웹 렌더링 서비스(WRS, Web Rendering Service)의 독특한 시간 처리 방식 때문이다.

구글의 페이지 렌더링 방식

• 구글이 페이지를 크롤링할 때 Googlebot이 초기 페이지를 가져온 후 HTML을 **웹 렌더링 서비스(WRS)**에 전달한다.
• WRS는 본질적으로 헤드리스 Chrome 인스턴스(사용자 인터페이스 없는 브라우저)다.
• CSS, JS 파일 같은 추가 리소스는 크롤링 인프라가 가져와서 다시 헤드리스 Chrome 인스턴스로 보낸다.
• 일반 브라우저와의 주요 차이점: 일반 브라우저는 브라우저 자신이 리소스를 가져오지만, WRS는 크롤링 인프라가 관리한다.

5초 제한설을 검증한 실험

테스트 페이지를 만들어 3~6초 사이의 랜덤 지연을 설정했다.

• 첫 번째 측정: setInterval 루프로 1초마다 페이지 제목(title)을 업데이트했다.
• 두 번째 측정: PHP 스크립트에 3~6초 지연의 fetch 요청을 여러 차례 보냈다.

URL 검사 도구로 렌더링 결과를 확인하면:

• setInterval() 루프는 5초 동안 실행되어 제목 요소를 업데이트했다.
• 타임스탬프는 오전 10:59:37 AM PST였다.
• 겉으로는 WRS가 정확히 5초 후 멈춘 것처럼 보인다.

오해의 원인: WRS의 가상 시간(Virtual Clock)

그런데 이것이 진실이 아닌 이유:

• WRS는 하드웨어 시계가 아닌 가상 시간을 사용한다. 구글은 헤드리스 Chrome 인스턴스를 위해 시간을 앞당기거나, 늦추거나, 멈출 수 있다.
• 실험에서 API 호출 두 개는 각각 3~6초의 서버 지연을 가졌으므로 총 6~12초가 걸려야 한다.
• 그런데도 WRS는 페이지를 완전히 렌더링하고 콘텐츠를 반환했다. 만약 5초 제한이 있었다면 불가능하다.

타임스탬프가 이상한 이유

• 첫 번째 API 호출: 5초 지연 후 반환
• 두 번째 API 호출: 4초 지연 후 반환
• 보고된 총 시간: 0.02초

WRS가 요청을 하는 동안 시간을 얼린다(freeze). 따라서 0.02초는 실제 요청 시간이 아니라 WRS가 요청을 처리하고 DOM에 결과를 삽입하는 시간일 뿐이다. 시작 및 종료 타임스탐프(UTC)가 이를 확인해준다.

실제 인덱싱에서도 동일

• Google Search Console의 URL 검사 도구로 확인하면 같은 동작이 반복된다.
• 한 가지 차이: 인덱싱 시 시간은 항상 자정 UTC부터 시작한다.
• 페이지가 오전 10:57:42 GMT에 인덱싱되었지만, API 호출의 타임스탬프는 자정 UTC(00:00:00)로 표시되고, 총 시간은 0.02초다.

렌더링이 언제 끝나는가?

• 하드 타임 리미트가 아니라 이벤트 루프(Event Loop) 관찰에 기반한다.
• 구글은 페이지가 유휴 상태이고 더 이상의 렌더링이 필요 없을 때를 판단해 렌더링을 종료한다.
• Google Search Advocate인 Martin Splitt의 동영상에서 이 이벤트 루프 동작이 상세히 설명되어 있다.

그래도 제한은 있는가?

WRS는 당연히 제한이 있다. 무한 루프나 끝없이 데이터를 계속 가져오는 페이지를 고려하면, 이벤트 루프가 절대 유휴 상태가 되지 않으므로 렌더링이 영영 끝나지 않는다.

무한 요청 페이지 테스트:

• 3초 서버 지연으로 계속 데이터를 가져오도록 설정했다.
• 라이브 테스트: 16~18번 호출(48~54초) 후 대부분 중단됐다.
• 실제 인덱싱: 10번 호출(30초) 후 인덱싱됐다.

이 수치는 다소 변동이 있으며, 실제로는 아무 사용자도 페이지 로딩에 30초를 기다리지 않으므로 현실적 시나리오가 아니다.

결론: WRS의 인내심은 무한하지 않지만, 5초보다는 훨씬 길고, 평균 사용자의 인내심보다는 훨씬 크다.

참고 자료

Tony McCreath의 "Tony's Theory of Googlebot Relativity" 글에서 WRS의 시간 처리 방식과 다른 흥미로운 통찰을 볼 수 있다.