12월 크롤링: HTTP 캐싱

2024년 12월 9일 월요일

Google에서 캐시를 사용할 수 있도록 허용해 주세요.

지난 몇 년간 인터넷이 성장함에 따라 Google에서 실행한 크롤링 양도 증가했습니다. Google의 크롤링 인프라는 휴리스틱 캐싱 메커니즘을 지원합니다. 사실항상 지원해 왔지요. 한편, 로컬 캐시에서 반환할 수 있는 요청 수가 줄어들었습니다. 10년 전에는 총 가져오기 중 약 0.026% 정도를 캐싱할 수 있었지만(그닥 인상적인 수치는 아닙니다) 지금은 0.017%까지 감소했습니다.

캐싱은 왜 중요할까요?

캐싱은 인터넷이라는 거대한 퍼즐에서 중요한 부분이 되는 한 조각입니다. 캐싱을 사용하면 재방문 시 페이지가 매우 빠르게 로드되고, 컴퓨팅 리소스와 자연 리소스가 절약됩니다. 그리고 클라이언트와 서버 모두에서 비용이 많이 드는 대역폭도 크게 절약됩니다.

특히 개별 URL 아래에 거의 변경되지 않는 콘텐츠가 있는 대규모 사이트라면, 로컬 캐싱을 허용하면 사이트가 더 효율적으로 크롤링될 수 있습니다. Google의 크롤링 인프라는 HTTP 캐싱 표준에 정의된 휴리스틱 HTTP 캐싱을 지원합니다. 특히 ETag 응답 및 If-None-Match 요청 헤더, Last-Modified 응답 및 If-Modified-Since 요청 헤더를 통해 이러한 캐싱을 지원합니다.

ETag를 사용하면 오류와 실수가 발생할 가능성이 적으므로 이 방법을 사용하는 것이 적극 권장됩니다. Last-Modified 값과 달리 값이 구조화되지 않습니다. 가능하다면 둘 다 설정해 보세요. 인터넷이 여러분께 감사할 겁니다. 아마도요.

어떤 사항이 있을 때 클라이언트가 캐시를 새로고침해야 하는지는 개발자의 결정에 달렸습니다. 콘텐츠가 크게 변경되었다면 캐시를 새로고침하는 것이 좋습니다. 그러나 페이지 하단의 저작권 날짜만 업데이트했다면 새로고침이 큰 의미가 없습니다.

ETag 및 If-None-Match

Google의 크롤러는 HTTP 캐싱 표준에 정의된 대로 ETag 기반 조건부 요청을 지원합니다. 즉, Google 크롤러에 캐싱 환경설정을 알리려면 Etag 값을 액세스된 URL에서 호스팅되는 콘텐츠 표현에서만 고유하게 사용되는 임의의 ASCII 문자열(일반적으로 콘텐츠 또는 버전 번호의 해시이지만 π의 일부일 수도 있음)로 설정하세요. 예를 들어 동일한 URL(예: 모바일 버전 및 데스크톱 버전) 아래에 동일한 콘텐츠의 여러 가지 버전을 호스팅한다면, 각 버전별로 고유한 ETag 값이 있을 수 있습니다.

캐싱을 지원하는 Google 크롤러는 해당 URL의 이전 크롤링에 대해 반환된 ETag 값을 If-None-Match header에 전송합니다. 크롤러에서 전송한 ETag 값이 서버에서 생성한 현재 값과 일치하면 서버는 HTTP 본문이 없는 HTTP 304(수정되지 않음) 상태 코드를 반환해야 합니다. 이 마지막 부분(HTTP 본문 없음)은 다음과 같은 몇 가지 이유로 중요한 부분입니다.

  • 서버가 실제로 콘텐츠를 생성하는 데 컴퓨팅 리소스를 소비하지 않아도 되므로 비용을 절약할 수 있습니다.
  • 서버가 HTTP 본문을 전송할 필요가 없으므로 비용을 절약할 수 있습니다.

사용자의 브라우저나 Googlebot과 같은 클라이언트 측에서는 해당 URL 아래의 콘텐츠는 클라이언트의 내부 캐시에서 검색됩니다. 이 작업은 데이터 전송 절차가 없어서 매우 빠르게 이루어지므로 사용자가 만족할 뿐만 아니라 일부 리소스를 절약할 수도 있습니다.

Last-Modified 및 If-Modified-Since

ETag와 마찬가지로 Google 크롤러는 HTTP 캐싱 표준에 정의된 대로 Last-Modified based 조건부 요청도 지원합니다. 이는 의미론적 관점에서 ETag와 동일하게 작동합니다. 식별자는 리소스를 캐시할 수 있는지 여부를 결정하는 데 사용되며 클라이언트 측에서 ETag와 동일한 이점을 제공합니다.

그러나 Last-Modified를 캐싱 디렉티브로 사용하는 경우 몇 가지 권장사항이 있습니다.

  1. Last-Modified 헤더의 날짜는 HTTP 표준에 따라 형식이 지정되어야 합니다. 파싱 문제를 방지하려면 '평일, DD Mon YYYY HH:MM:SS 시간대'와 같은 날짜 형식을 사용하는 것이 좋습니다. 예를 들면 'Fri, 4 Sep 1998 19:15:56 GMT'처럼 설정할 수 있습니다.
  2. 필수는 아니지만 크롤러가 특정 URL을 다시 크롤링할 시기를 결정하는 데 도움이 되도록 Cache-Control 헤더의 max-age 필드를 설정하는 것도 고려해 보세요. max-age 필드의 값을 콘텐츠가 변경되지 않을 것으로 예상되는 초 수로 설정합니다. 예를 들면 Cache-Control: max-age=94043처럼 설정할 수 있습니다.

예

저와 비슷한 분이시라면 휴리스틱 캐싱이 작동하는 방식을 이해하기가 쉽지는 않으실 겁니다. 하지만 요청 및 응답 체인의 예시를 보면 도움이 됩니다. 다음은 작동 방식을 시각화하기 위한 두 개의 체인(ETag/If-None-Match용 체인 1개, Last-Modified/If-Modified-Since용 체인 1개)입니다.

ETag/If-None-Match Last-Modified/If-Modified-Since
크롤링에 대한 서버의 응답: 크롤러가 사전 조건 헤더 필드 ETag 및 Last-Modified를 저장할 수 있는 응답입니다. 
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 4 Sep 1998 19:15:50 GMT
ETag: "34aa387-d-1568eb00"
...
 
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 4 Sep 1998 19:15:50 GMT
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT
Cache-Control: max-age=94043
...
후속 크롤러 조건부 요청: 조건부 요청은 이전 요청에서 저장된 전제 조건 헤더 값을 기반으로 합니다. 값은 If-None-Match 및 If-Modified-Since 요청 헤더에서 유효성 검사를 위해 서버로 다시 전송됩니다. 
GET /hello.world HTTP/1.1
Host: www.example.com
Accept-Language: en, hu
User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)
If-None-Match: "34aa387-d-1568eb00"
...
 
GET /hello.world HTTP/1.1
Host: www.example.com
Accept-Language: en, hu
User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT
...
조건부 요청에 대한 서버 응답: 크롤러에서 전송한 사전 조건 헤더 값은 서버 측에서 유효성 검사가 진행되므로 서버는 크롤러에 304 HTTP 상태 코드(HTTP 본문 없음)를 반환합니다. 이는 전제 조건이 검증되지 않을 때까지(서버 측에서 ETag 또는 Last-Modified 날짜가 변경될 때까지) 후속 요청마다 발생합니다. 
HTTP/1.1 304 Not Modified
Date: Fri, 4 Sep 1998 19:15:50 GMT
Expires: Fri, 4 Sep 1998 19:15:52 GMT
Vary: Accept-Encoding
If-None-Match: "34aa387-d-1568eb00"
...
 
HTTP/1.1 304 Not Modified
Date: Fri, 4 Sep 1998 19:15:50 GMT
Expires: Fri, 4 Sep 1998 19:15:51 GMT
Vary: Accept-Encoding
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT
...

사용자를 만족시키면서 호스팅 비용도 살짝 절약하고 싶다면 호스팅/CMS 제공업체나 개발자에게 사이트에 HTTP 캐싱을 사용 설정하는 방법을 문의하세요. 혹시나 다른 큰 효과가 없더라도, 최소한 사용자들은 사이트에 좀 더 만족하게 될 것이라는 점은 확실합니다.

캐싱에 관해 이야기하고 싶다면 가장 가까운 Google 검색 센터 도움말 커뮤니티를 방문하세요. 캐싱 방식에 관한 의견이 있으면 이 블로그 게시물과 함께 게시된 캐싱에 관한 문서에 의견을 남겨 주시기 바랍니다.

게시자: 게리 일리즈

크롤링에 대해 자세히 알아보시겠어요? 12월 크롤링 시리즈 전체를 확인해보세요.

게리 일리스

Google 검색팀의 분석가 게리 일리스는 Google 검색팀의 분석가로, 게시자가 사용자와 Google 검색 모두에 효과적인 웹사이트를 만들 수 있도록 지원하기 위해 Google 검색 시스템에 대한 정보를 게시하는 데 주력하고 있습니다. LinkedIn | Mastodon | Twitter

그렉 그로트하우스

Google 검색 품질관리팀 직원 소프트웨어 엔지니어 Google 검색 센터 블로그에서 그레그 그로트하우스의 게시물을 확인하세요. 웹사이트

니르 칼루쉬

Google 트렌드 및 Search Console 제품 관리자 니르 칼루쉬는 Google 트렌드 및 Search Console팀의 제품 관리자로, 열린 웹 및 뉴스 생태계를 개선하는 도구를 주로 담당하고 있습니다. 이전에는 Google Ads(디스플레이 및 앱)와 관련한 다양한 직무를 수행했습니다. Google에 합류하기 전에는 SAAS 스타트업, 엔지니어링 회사, 연구기관을 비롯한 여러 업계에서 연구, 엔지니어링, 기술 영업, 프로젝트 관리