코어 웹 바이탈과 지연 시간: 더 빠른 페이지가 더 많은 AI 인용을 받을까?

코어 웹 바이탈과 지연 시간: 더 빠른 페이지가 더 많은 인공지능 인용을 받을까?

서론

빠른 웹사이트는 사람들이 사용하기 편리합니다. 또한 검색 엔진과 인공지능 시스템이 콘텐츠를 가져오고, 렌더링하며, 이해하는 데도 더 쉬울 수 있습니다.

하지만 중요한 차이점이 종종 간과됩니다:

더 빠른 페이지는 크롤링 및 콘텐츠 가용성을 향상시킬 수 있습니다. 그렇다고 해서 속도만으로 인공지능 시스템이 해당 페이지를 인용하게 되는 것은 아닙니다.

2026년 8월 2일 현재, Google은 안정적인 서버 응답 시간과 낮은 지연 시간이 사이트의 크롤링 용량을 증가시킬 수 있다고 밝히고 있습니다. 또한 Google은 자사의 인공지능 검색 기능이 기존 검색과 동일한 기본 검색 및 색인 시스템을 사용하며, 특별한 인공지능 마크업이나 속도 최적화가 필요하지 않다고 말합니다. (developers.google.com)

이 글은 이미 완료된 실험이 있었다고 주장하기보다는, 증거 기반의 테스트 계획을 제시합니다. 어떠한 사이트, 페이지 세트, 서버 로그 또는 인용 데이터셋도 제공되지 않았습니다. 목표는 다음을 측정할 수 있는 통제된 연구를 정의하는 것입니다:

1. 낮은 **첫 바이트까지의 시간(TTFB)**이 크롤링 빈도를 증가시키는지 여부.
2. 낮은 **최대 콘텐츠 렌더링 시간(LCP)**이 검색 또는 색인 생성을 개선하는지 여부.
3. 낮은 **누적 레이아웃 이동(CLS)**이 크롤링 또는 인공지능 검색에 영향을 미치는지 여부.
4. 성능 개선이 인공지능 검색 시스템에 의해 페이지가 시각적으로 인용되는 비율을 증가시키는지 여부.

간략한 답변

적절한 조건에서 첫 바이트까지의 시간을 줄이면 크롤링이 개선될 수 있습니다.

Google의 현재 크롤링 문서는 첫 바이트까지의 시간을 포함하여 사이트의 응답 시간이 안정적이거나 개선될 때 크롤링 용량 제한이 증가할 수 있다고 말합니다. 응답 시간이 증가하거나, 사이트가 너무 많은 서버 오류나 속도 제한 응답을 반환하면 Google은 크롤링을 줄일 수 있습니다. (developers.google.com)

하지만 더 빠른 응답 시간이 더 많은 크롤링을 보장하지는 않습니다. 크롤링 수요는 다음 요소에도 달려 있습니다:

• 사이트가 얼마나 자주 변경되는지.
• 사이트와 페이지의 인기도.
• 콘텐츠가 유용하고 독특한지 여부.
• 중복되거나 가치가 낮은 URL이 얼마나 많은지.
• 업데이트된 URL이 사이트맵에 포함되어 있는지 여부.

이는 낮은 지연 시간이 규모가 크거나, 자주 업데이트되거나, 서버 제약이 있는 웹사이트에 가장 큰 영향을 미칠 것이며, 새로운 콘텐츠가 제한적인 작은 사이트에 반드시 영향을 미치는 것은 아님을 의미합니다.

최대 콘텐츠 렌더링 시간(LCP)을 낮추면 간접적으로 도움이 될 수 있습니다.

최대 콘텐츠 렌더링 시간(LCP)은 사용자에게 주요 가시 콘텐츠가 나타나는 시점을 측정합니다. Google은 또한 서버 응답 시간과 페이지 및 포함된 리소스를 렌더링하는 데 필요한 시간 모두가 크롤링 효율성에 영향을 미칠 수 있다고 말합니다. (developers.google.com)

가능한 관계는 간접적입니다:

낮은 지연 시간 → 빠른 리소스 전달 → 더 효율적인 렌더링 또는 가져오기 → 더 적은 크롤링 시간 초과 또는 불완전한 가져오기.

이 효과는 중요한 콘텐츠가 다음에 의존할 때 가장 강력할 것입니다:

• 느린 JavaScript.
• 큰 이미지.
• 렌더링을 차단하는 스타일시트.
• 클라이언트 측 렌더링.
• 무거운 임베디드 리소스.

빠른 최대 콘텐츠 렌더링 시간(LCP) 점수 자체는 직접적인 인공지능 인용 신호가 될 가능성이 낮습니다.

누적 레이아웃 이동(CLS)을 낮추는 것은 직접적인 크롤링 효과가 거의 없을 것입니다.

누적 레이아웃 이동(CLS)은 가시 콘텐츠의 예상치 못한 움직임을 측정합니다. 이는 주로 사용자 경험 지표입니다. 일반적인 원인으로는 크기가 지정되지 않은 이미지, 동적으로 삽입된 광고, 임베디드 콘텐츠 및 웹 폰트가 있습니다. (web.dev)

크롤러는 인간 방문객과 같은 방식으로 레이아웃 이동을 경험하지 않습니다. 따라서 낮은 누적 레이아웃 이동(CLS)과 더 많은 크롤링 사이에 직접적인 관계는 없을 것입니다.

높은 레이아웃 이동이 다음으로 인해 발생할 경우 간접적인 관계가 있을 수 있습니다:

• JavaScript에 의해 늦게 삽입된 콘텐츠.
• 스크립트가 실행될 때까지 숨겨진 중요한 텍스트.
• 페이지 구성을 지연시키는 이미지 또는 임베드.
• 다른 가져오기 시 다른 콘텐츠를 생성하는 불안정한 템플릿.

이러한 경우, 실제 문제는 레이아웃 이동 점수가 아닙니다. 실제 문제는 페이지 처리가 어렵거나 중요한 콘텐츠가 너무 늦게 노출될 수 있다는 것입니다.

더 빠른 페이지가 자동으로 더 자주 인용되는 것은 아닙니다.

Google은 인공지능 기능에 나타나는 페이지는 먼저 색인되어야 하며 일반 검색 결과에 스니펫과 함께 표시될 자격이 있어야 한다고 말합니다. Google은 또한 자사의 인공지능 개요 및 인공지능 모드에 대한 추가 기술 요구 사항이나 특별한 인공지능 최적화는 없다고 말합니다. (developers.google.com)

OpenAI 역시 ChatGPT 검색 순위가 여러 요소에 따라 달라지며, 검색 크롤러인 OAI-SearchBot을 허용하는 것이 포함에 중요하다고 말합니다. 낮은 코어 웹 바이탈이 직접적으로 인용 확률을 높인다고는 명시하지 않습니다. (help.openai.com)

이는 4단계 모델을 시사합니다:

1. 발견 — 시스템이 URL의 존재를 알게 되는가?
2. 가져오기 및 처리 — 시스템이 페이지를 검색하고 이해할 수 있는가?
3. 색인 생성 및 검색 — 페이지가 특정 쿼리에 대해 선택되는가?
4. 인용 선택 — 페이지가 답변에서 시각적 출처로 표시되는가?

페이지 속도는 처음 두 단계에 영향을 미칠 수 있습니다. 하지만 네 번째 단계의 직접적인 원인으로 확립되지는 않았습니다.

최근 연구에 따르면 인공지능 시스템은 많은 관련 페이지를 읽을 수 있지만 그중 일부만 인용합니다. 즉, 검색과 인용은 별개의 사건입니다. (cambridge.org)

무엇을 테스트해야 하는가?

이 연구는 '인공지능 가시성'을 하나의 지표로 다루기보다는 두 가지 다른 질문을 테스트해야 합니다.

질문 1: 성능이 크롤링에 영향을 미치는가?

주요 결과:

• 게시부터 첫 크롤러 요청까지의 시간.
• 페이지당 하루 크롤러 요청 수.
• 성공적인 재크롤링 사이의 시간.
• 게시된 페이지 1,000개당 크롤링된 페이지 수.
• 성공적인 가져오기 비율.
• 서버 오류 및 속도 제한 응답 비율.
• 게시부터 색인 생성까지의 시간.

질문 2: 성능이 인용 선택에 영향을 미치는가?

주요 결과:

• 시각적 인용을 생성하는 테스트된 쿼리 비율.
• 자격 있는 페이지당 인용률.
• 쿼리 내 인용 점유율.
• 시각적 인용이 되는 검색된 페이지 비율.
• 시간에 따른 인용 지속성.
• 인공지능 시스템별 인용률.

이러한 결과는 제공업체별로 분리되어야 합니다. Google 인공지능 개요, ChatGPT 검색 결과, Microsoft Copilot 답변, Perplexity 답변, Claude 검색 응답은 각각 다른 색인, 크롤러, 순위 시스템 및 새로 고침 일정을 사용할 수 있습니다.

실험 설계

1. 통제된 페이지 세트 구축

의미 있는 크롤러 및 인용 데이터를 생성할 수 있을 만큼 충분히 큰 페이지 세트를 사용하십시오.

실질적인 초기 설계는 다음을 포함할 것입니다:

• 240개에서 800개 페이지.
• 페이지 템플릿당 최소 20페이지.
• 세 가지에서 다섯 가지 콘텐츠 카테고리.
• 에버그린 페이지와 정기적으로 업데이트되는 페이지의 혼합.
• 각 처리 그룹에 동일한 수의 페이지.

각 페이지는 다음을 포함해야 합니다:

• 유사한 HTML 구조.
• 유사한 콘텐츠 길이.
• 동일한 게시 시스템.
• 동일한 내부 링크 패턴.
• 동일한 캐노니컬 규칙.
• 동일한 사이트맵 처리.
• 동일한 robots.txt 권한.
• 고유하고 유용한 주제.

실험을 위해서만 수백 개의 얇거나 거의 중복된 페이지를 생성하지 마십시오. Google의 지침은 중복되고 가치가 낮은 URL이 크롤링 리소스를 낭비하고 사이트 효율성을 저하시킬 수 있다고 경고합니다. (developers.google.com)

짝 지어진 쌍 설계가 유용합니다. 예를 들어, 유사한 속성을 가진 페이지를 짝 지으십시오:

• 콘텐츠 길이.
• 주제 수요.
• 업데이트 빈도.
• 내부 링크 수.
• 외부 링크 수.
• 과거 트래픽.
• 검색 순위 위치.

그런 다음 각 쌍의 한 페이지는 대조군에, 다른 페이지는 처리군에 배치하십시오.

2. 요인 처리 설계 사용

주요 성능 처리는 독립적으로 그리고 함께 테스트되어야 합니다.

이는 요청된 세 가지 최적화에 대한 통제된 실험을 생성합니다:

• HTTP/3.
• 콘텐츠 전송 네트워크 엣지 캐싱.
• 이미지 압축.

레이아웃 안정성 처리는 첫 세 가지 최적화가 누적 레이아웃 이동(CLS)을 안정적으로 분리하지 못하기 때문에 필요합니다. 이미지 압축은 레이아웃 안정성을 전혀 변경하지 않고도 최대 콘텐츠 렌더링 시간(LCP)을 낮출 수 있습니다.

HTTP/3가 자체 측정을 필요로 하는 이유

HTTP/3는 QUIC 전송 프로토콜을 사용하며 독립적인 스트림을 제공하여 TCP를 통한 HTTP/2에서 발견되는 전송 계층의 HOL(Head-of-Line) 블로킹을 피할 수 있습니다. 그 이점은 클라이언트나 크롤러가 실제로 HTTP/3를 협상하는지 여부에 따라 달라집니다. (rfc-editor.org)

따라서 모든 요청에 대해 협상된 프로토콜을 기록하십시오:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

HTTP/3를 활성화한다고 해서 모든 크롤러가 이를 사용한다고 가정하지 마십시오. Googlebot, OAI-SearchBot 또는 다른 크롤러가 계속 HTTP/2를 사용한다면 HTTP/3는 해당 크롤러의 요청에 영향을 미칠 수 없습니다.

엣지 캐싱을 신중하게 테스트해야 하는 이유

콘텐츠 전송 네트워크는 요청자에게 더 가까운 곳에서 콘텐츠를 제공하여 첫 바이트까지의 시간을 줄일 수 있습니다. 또한 원본 서버에 도달하는 요청 수를 줄일 수도 있습니다. (web.dev)

최소 세 가지 캐시 상태를 테스트하십시오:

1. 콜드 캐시 — 엣지가 원본에 연락해야 합니다.
2. 웜 캐시 — 엣지가 원본에 연락하지 않고 페이지를 제공합니다.
3. 재검증된 캐시 — 엣지 또는 크롤러가 ETag 또는 Last-Modified 값을 사용하고 304 Not Modified 응답을 받습니다.

Google은 특히 효율적인 HTTP 캐싱을 권장하며, 불필요한 처리 및 대역폭을 줄이기 위해 304 Not Modified 응답 사용을 지원합니다. (developers.google.com)

캐싱이 크롤러에게 오래되거나 잘못된 콘텐츠를 제공하도록 허용하지 마십시오. 다음을 기록하십시오:

• 캐시 히트 또는 미스.
• 캐시 수명.
• 엣지 위치.
• 원본 응답 시간.
• 콘텐츠 버전.
• 상태 코드.
• 검증 헤더.

이미지 압축이 최대 콘텐츠 렌더링 시간(LCP)과 연결되어야 하는 이유

WebP 및 AVIF는 일반적으로 이전 이미지 형식보다 더 나은 압축을 제공합니다. 더 작은 이미지는 전송 시간을 줄일 수 있으며, 이미지가 최대 콘텐츠 렌더링 시간(LCP) 요소일 때 LCP를 개선할 수 있습니다. (web.dev)

테스트는 다음을 사용해야 합니다:

• 동일한 이미지 크기.
• 동일한 시각적 품질 목표.
• 반응형 srcset 이미지.
• 적절한 폴백이 있는 최신 형식.
• 명시적 width 및 height 값.
• 최대 콘텐츠 렌더링 시간(LCP) 이미지에 대한 지연 로딩 없음.
• 초기 HTML에 보이는 이미지 URL.

실제 지연이 JavaScript 또는 늦은 리소스 발견에서 비롯된다면 이미지 압축만으로는 최대 콘텐츠 렌더링 시간(LCP)을 개선하지 못할 수 있습니다. Google의 성능 지침은 LCP 요소가 늦게 나타나는 경우 이미지 다운로드 시간을 줄이는 것이 단순히 지연을 페이지의 다른 부분으로 옮길 수 있다고 지적합니다. (web.dev)

3. 충분히 오랫동안 테스트 실행

짧은 테스트는 크롤링 일정 및 색인 새로 고침의 영향을 놓칠 수 있습니다.

실질적인 설계는 다음과 같습니다:

• 2주간의 기준선 측정.
• 6주에서 12주간의 처리 측정.
• 가능하다면 최종 반전 또는 교차 기간.

교차 테스트의 경우, 짝 지어진 페이지 그룹 간에 처리를 전환합니다. 처리가 제거될 때 성능 효과가 사라진다면, 그 결과는 단순한 전후 비교보다 더 강력합니다.

코어 웹 바이탈 현장 데이터는 적절한 기간 동안 평가되어야 합니다. Chrome 사용자 경험 보고서(CrUX)는 28일 누적 집계를 사용하므로 배포 후 즉각적인 변화를 보여주도록 설계되지 않았습니다. (developer.chrome.com)

4. 전체 크롤러 집단 측정

모든 자동화된 트래픽을 하나의 그룹으로 취급하지 마십시오.

최소한 다음을 분리하십시오:

검색 크롤러

• Googlebot.
• Bingbot.

인공지능 검색 크롤러

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

사용자 요청 가져오기

• Perplexity-User.
• Claude-User.
• 식별 가능한 ChatGPT 사용자 가져오기.

학습 크롤러

• GPTBot.
• ClaudeBot.
• Google-Extended 제어.

학습 크롤러는 인공지능 검색 인용의 대용으로 사용되어서는 안 됩니다. Anthropic, OpenAI, Google은 학습, 검색 또는 사용자 요청 검색에 사용되는 크롤러를 구분합니다. Google은 또한 Google-Extended가 Google 검색 포함 또는 순위에 영향을 미치지 않는다고 밝힙니다. (help.openai.com)

Perplexity 역시 검색 색인 생성을 지원하는 PerplexityBot과 사용자 요청에 응답하여 페이지를 가져올 수 있는 Perplexity-User를 구분합니다. (docs.perplexity.ai)

제공업체가 지원하는 경우 게시된 IP 범위 또는 역방향 DNS를 사용하여 크롤러 ID를 확인하십시오. 사용자 에이전트 문자열은 관련 없는 크롤러에 의해 복사될 수 있습니다. Google은 Googlebot 사용자 에이전트 문자열이 위조될 수 있다고 특별히 경고합니다. (developers.google.com)

수집할 지표

성능 지표

실험실 및 실제 사용자 데이터를 모두 수집하십시오:

• 첫 바이트까지의 시간(TTFB).
• 첫 콘텐츠풀 페인트(FCP).
• 최대 콘텐츠 렌더링 시간(LCP).
• 누적 레이아웃 이동(CLS).
• 다음 페인트까지의 상호작용(INP).
• 총 페이지 가중치.
• 초기 HTML 크기.
• 이미지 전송 크기.
• 요청 수.
• 서버 처리 시간.
• 최대 콘텐츠 렌더링 시간(LCP) 리소스를 기다리는 시간.
• HTTP 프로토콜.
• 캐시 상태.

Google은 첫 바이트까지의 시간(TTFB) 목표를 800밀리초 이하로 권장하지만, TTFB 자체는 코어 웹 바이탈이 아닙니다. (web.dev)

현재 75번째 백분위수에서 코어 웹 바이탈의 '좋음' 임계값은 다음과 같습니다:

• 최대 콘텐츠 렌더링 시간(LCP): 2.5초 이하.
• 누적 레이아웃 이동(CLS): 0.1 이하.
• 다음 페인트까지의 상호작용(INP): 200밀리초 이하. (web.dev)

크롤링 지표

모든 검증된 크롤러 요청에 대해 다음을 기록하십시오:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

다음 계산:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

인공지능 인용 지표

각 플랫폼에 걸쳐 고정된 쿼리 세트를 사용하십시오. 쿼리 세트에는 다음이 포함되어야 합니다:

• 직접적인 사실 질문.
• 비교 질문.
• “최고” 또는 추천 질문.
• 신선도에 민감한 질문.
• 테스트된 페이지가 가장 강력한 답변인 질문.
• 테스트된 페이지가 관련이 있지만 지배적이지는 않은 질문.

각 쿼리에 대해 다음을 기록하십시오:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

인공지능 답변은 다를 수 있으므로 쿼리를 반복하십시오. 주 3회와 같은 고정된 일정을 사용하고 엔진 또는 모델의 변경 사항을 기록하십시오.

Microsoft Bing 웹마스터 도구는 이제 지원되는 Microsoft 인공지능 경험 전반에 걸쳐 인용된 페이지, 근거 쿼리 및 인용 추세를 보여주는 인공지능 성능 보고서를 제공합니다. Microsoft는 데이터가 집계되고, 샘플링되었으며, 관찰적이라고 경고합니다. 특정 페이지 변경이 인용 변경을 유발했음을 증명할 수는 없습니다. (bing.com)

Google은 또한 2026년 6월부터 검색 콘솔에서 전용 생성형 인공지능 성능 보고서를 출시하기 시작했습니다. 이 보고서는 초기에는 일부 웹사이트에서만 제공되었으므로 접근성은 다를 수 있습니다. (developers.google.com)

통계 분석

크롤링 빈도

음이항 모델과 같은 혼합 효과 개수 모델을 사용하십시오:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

페이지와 크롤러 효과는 일부 페이지가 다른 페이지보다 자연스럽게 더 많은 관심을 받고, 다른 크롤러가 다른 일정을 가지고 있기 때문에 중요합니다.

발견 및 색인 생성

다음 항목에 대해 생존 분석을 사용하십시오:

• 게시부터 첫 가져오기까지의 시간.
• 게시부터 첫 색인 생성까지의 시간.
• 업데이트부터 재크롤링까지의 시간.

주요 결과는 단순히 페이지가 결국 크롤링되었는지 여부가 아닙니다. 그것은 처리가 페이지가 발견되고 처리되는 데 필요한 시간을 단축시켰는지 여부입니다.

인공지능 인용 선택

계층적 로지스틱 모델을 사용하십시오:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

두 가지 별도의 모델을 실행하십시오:

1. 검색 모델 — 페이지가 검색되었거나 후보로 표시되었는가?
2. 인용 모델 — 검색된 경우, 페이지가 시각적으로 인용되었는가?

이러한 구분은 필수적입니다. 크롤링은 증가시키지만 검색은 증가시키지 않는 성능 개선은 인공지능 인용 효과가 아닙니다. 검색은 증가시키지만 인용은 증가시키지 않는 성능 개선은 페이지가 고려되었지만 출처 선택 과정에서 탈락했음을 시사합니다.

예상 결과

이것들은 작업 가설이며, 주장된 실험 결과가 아닙니다.

가설 1: 첫 바이트까지의 시간(TTFB)이 가장 명확한 크롤링 효과를 가질 것이다.

다음과 같은 경우, 낮은 첫 바이트까지의 시간(TTFB)과 크롤링 용량 사이에 긍정적인 관계를 기대하십시오:

• 사이트에 많은 페이지가 있을 때.
• 페이지가 자주 변경될 때.
• 원본 서버가 느리거나 과부하되었을 때.
• 사이트가 5xx 또는 429 응답을 반환할 때.
• 크롤러가 응답을 기다리는 데 상당한 시간을 보낼 때.

크롤링 수요가 낮은 작은 사이트에서는 측정 가능한 효과가 거의 없을 것으로 예상됩니다.

가설 2: 최대 콘텐츠 렌더링 시간(LCP)은 렌더링 및 리소스 전달을 통해 중요할 것이다.

다음과 같은 경우, 낮은 최대 콘텐츠 렌더링 시간(LCP)이 도움이 될 것으로 예상됩니다:

• 페이지가 브라우저 렌더링에 의존할 때.
• 중요한 콘텐츠가 JavaScript 뒤에 있을 때.
• 색인 생성을 위해 큰 이미지 또는 스타일시트가 필요할 때.
• 크롤러가 많은 페이지 리소스를 가져올 때.
• 느린 처리가 시간 초과 또는 불완전한 렌더링을 유발할 때.

페이지의 중요한 텍스트가 초기 HTML에 이미 존재할 때는 약한 관계를 예상하십시오.

가설 3: 누적 레이아웃 이동(CLS)은 직접적인 영향이 거의 없을 것이다.

페이지 구조 및 JavaScript 동작을 제어한 후에는 누적 레이아웃 이동(CLS)과 크롤링 빈도 또는 인용률 사이에 의미 있는 직접적인 관계가 없을 것으로 예상됩니다.

만약 누적 레이아웃 이동(CLS)이 인용을 예측하는 것으로 보인다면, 다음의 대리 역할을 하는지 조사하십시오:

• 클라이언트 측 렌더링.
• 늦은 콘텐츠 삽입.
• 불안정한 광고.
• 숨겨지거나 지연된 텍스트.
• 구조가 좋지 않은 HTML.

가설 4: 속도만으로는 더 많은 인공지능 인용을 생성하지 못할 것이다.

인용 선택의 가장 강력한 예측 변수는 다음과 같을 것입니다:

• 쿼리와의 관련성.
• 콘텐츠 품질.
• 명확한 답변.
• 신선도.
• 권위와 신뢰.
• 검색 색인 적격성.
• 검색 순위.
• 페이지가 주장되는 내용을 직접적으로 뒷받침하는지 여부.

Google의 지침은 유용하고 신뢰할 수 있는 사람 중심 콘텐츠를 강조하며, 인공지능 검색 기능이 기존 검색 및 색인 시스템에 기반을 두고 있다고 말합니다. (developers.google.com)

인공지능 검색에 맞춰 조정된 성능 예산

다음은 제안된 운영 예산입니다. 이는 공개된 인공지능 순위 결정 공식이 아닙니다.

Google의 현재 문서는 Googlebot이 지원되는 파일의 처음 2메가바이트를 가져오고 외부 스크립트와 스타일시트를 별도로 가져온다고 말합니다. 또한 중요한 메타데이터와 구조화된 데이터를 HTML 초기에 배치할 것을 권장합니다. (developers.google.com)

구현 권장 사항

HTTP/3

호스팅 제공업체와 콘텐츠 전송 네트워크가 지원하는 경우 HTTP/3를 사용하십시오.

측정:

• HTTP/3 협상률.
• HTTP/2 폴백률.
• 연결 설정 시간.
• 첫 바이트까지의 시간(TTFB).
• 지리적 지역별 성능.
• 크롤러별 성능.

HTTP/3를 보장된 검색 또는 인공지능 최적화로 간주하지 마십시오. 이는 이를 사용하는 클라이언트에게만 도움이 될 수 있는 전송 개선 사항입니다.

콘텐츠 전송 네트워크 엣지 캐싱

공개적이고 개인화되지 않은 페이지의 경우:

• 명확한 Cache-Control 규칙을 설정하십시오.
• 버전 관리되는 정적 자산에 대해 장기 캐싱을 사용하십시오.
• 자주 업데이트되는 HTML에 대해 짧지만 유용한 캐싱을 사용하십시오.
• 불필요한 쿼리 매개변수로 인한 캐시 조각화를 피하십시오.
• 캐노니컬 URL을 보존하십시오.
• ETag 및 Last-Modified를 지원하십시오.
• 콜드, 웜 및 재검증된 캐시 상태를 테스트하십시오.
• 크롤러 요청이 사람의 요청과 동일한 중요한 콘텐츠를 받는지 확인하십시오.

콘텐츠 전송 네트워크는 오래되거나, 일관성 없거나, 봇 전용 페이지 버전을 생성하지 않으면서 지연 시간을 줄여야 합니다.

이미지 압축

이미지의 경우:

• 시각적 품질이 허용되는 경우 AVIF 또는 WebP를 사용하십시오.
• 반응형 이미지 크기를 제공하십시오.
• 작은 모바일 화면에 데스크톱 크기 이미지를 제공하지 마십시오.
• 최대 콘텐츠 렌더링 시간(LCP) 이미지를 지연 로딩하지 마십시오.
• 이미지 크기를 포함하십시오.
• 초기 HTML에 최대 콘텐츠 렌더링 시간(LCP) 이미지를 배치하십시오.
• 적절한 경우에만 fetchpriority="high"를 사용하십시오.
• 중요한 설명은 이미지 안에만 포함시키지 말고 텍스트로 유지하십시오.

이미지 압축은 이미지가 최대 콘텐츠 렌더링 시간(LCP) 요소일 때 가장 가치가 있습니다. 서버 렌더링 또는 JavaScript 실행으로 인해 주요 지연이 발생하는 페이지를 고치지는 못할 것입니다. (web.dev)

레이아웃 안정성

누적 레이아웃 이동(CLS)을 낮추려면:

• 이미지에 너비와 높이 속성을 설정하십시오.
• 광고를 위한 공간을 확보하십시오.
• 임베디드 비디오 및 소셜 콘텐츠를 위한 공간을 확보하십시오.
• 기존 텍스트 위에 배너를 삽입하는 것을 피하십시오.
• 안정적인 폰트 로딩 전략을 사용하십시오.
• 페이지 로드 후 서버 렌더링된 콘텐츠의 큰 블록을 교체하는 것을 피하십시오.

이러한 변경 사항은 크롤링이나 인용에 측정 가능한 영향을 미치지 않더라도 사용자 경험을 개선합니다. (web.dev)

도구 및 모니터링

성능 도구

사용:

• 실제 사용자 코어 웹 바이탈을 위한 Chrome 사용자 경험 보고서(CrUX).
• 자동화된 현장 데이터 수집을 위한 Chrome 사용자 경험 보고서 API.
• 실험실 감사 및 현장 데이터를 위한 PageSpeed Insights.
• 반복 가능한 실험실 테스트를 위한 Lighthouse.
• 풀 요청 성능 예산을 위한 Lighthouse 지속적 통합(CI).
• 다중 위치 테스트, 캐시 상태 및 프로토콜 비교를 위한 WebPageTest.
• 최대 콘텐츠 렌더링 시간(LCP) 및 레이아웃 이동 디버깅을 위한 Chrome 개발자 도구.
• 실제 사용자 모니터링을 위한 web-vitals JavaScript 라이브러리.

Chrome 사용자 경험 보고서(CrUX) API는 최대 콘텐츠 렌더링 시간(LCP), 누적 레이아웃 이동(CLS), 다음 페인트까지의 상호작용(INP) 및 실험적인 첫 바이트까지의 시간(TTFB)을 포함한 페이지 수준 및 원본 수준 집계된 현장 데이터를 제공합니다. (developer.chrome.com)

Lighthouse 지속적 통합(CI)은 모든 코드 변경에 대해 성능 검사를 실행하고 예산이 초과되면 빌드를 실패시킬 수 있습니다. (github.com)

크롤러 모니터링

서버 로그, 엣지 로그 및 소규모 합성 프로브 세트를 사용하십시오.

예시 프로브:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

다음으로 동일한 테스트를 실행하십시오:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• 일반 브라우저 사용자 에이전트.

테스트는 다음을 확인해야 합니다:

• 상태 코드.
• Robots 권한.
• 응답 헤더.
• HTML 콘텐츠.
• HTTP 버전.
• 캐시 상태.
• 응답 시간.
• JavaScript 없이 중요한 텍스트가 존재하는지 여부.

검색 및 색인 생성 모니터링

사용:

• Google Search Console 크롤링 통계.
• Google Search Console 페이지 색인 생성 보고서.
• Google Search Console URL 검사.
• Google Search Console 사이트맵 데이터.
• 사용 가능한 경우 Google Search Console 생성형 인공지능 보고서.
• Bing 웹마스터 도구 크롤링 요청 및 색인 생성된 페이지.
• Bing 웹마스터 도구 인공지능 성능.
• 일일 사이트맵 및 lastmod 확인.

Search Console API는 데이터 제한에 따라 페이지, 쿼리, 날짜, 기기 및 검색 노출별로 성능 데이터를 검색할 수 있습니다. (developers.google.com)

인용 모니터링

주제당 50~200개의 안정적인 쿼리로 구성된 인용 패널을 생성하십시오. 고정된 일정에 따라 패널을 실행하고 다음을 기록하십시오:

• 플랫폼이 검색했는지 여부.
• 어떤 출처가 나타났는지.
• 테스트된 URL이 인용되었는지 여부.
• 인용 순서.
• 답변 날짜 및 시간.
• 페이지가 변경되었는지 여부.
• 모델 또는 검색 경험이 변경되었는지 여부.

서로 다른 시스템의 인용 횟수를 동등한 것처럼 비교하지 마십시오. Microsoft는 인용 활동이 순위 점수, 권위 점수, 트래픽 측정 또는 품질 점수가 아니라고 명시합니다. (bing.com)

경고 규칙

다음 항목에 대한 경고를 생성하십시오:

• 첫 바이트까지의 시간(TTFB)이 25% 이상 증가.
• 75번째 백분위수에서 최대 콘텐츠 렌더링 시간(LCP)이 2.5초 이상으로 이동.
• 누적 레이아웃 이동(CLS)이 0.1 이상으로 이동.
• 5xx 또는 429 응답의 지속적인 증가.
• 크롤러 성공률 하락.
• robots.txt 변경.
• 사이트맵 오류.
• 색인 생성된 페이지의 급격한 감소.
• 여러 플랫폼에서 인공지능 인용의 급격한 감소.
• 하나의 플랫폼에만 영향을 미치는 인용량 변화.

하나의 플랫폼에 영향을 미치는 인용 감소는 페이지 성능 문제보다는 모델, 색인, 쿼리 또는 제품 변경으로 인해 발생할 수 있습니다. Microsoft는 인용 추세가 관찰적이며 콘텐츠 업데이트, 사용자 수요 및 시스템 또는 모델 변경으로 인해 변경될 수 있다고 명시적으로 경고합니다. (bing.com)

최종 결론

가장 방어 가능한 결론은 다음과 같습니다:

더 빠른 페이지는 특히 서버 지연 시간, 리소스 크기, 오류 또는 렌더링 지연이 제한 요소인 경우 크롤링 효율성을 향상시킬 수 있습니다. 하지만 낮은 코어 웹 바이탈이 인공지능 시스템이 페이지를 인용으로 선택하도록 직접적으로 유발한다는 강력한 증거는 현재 없습니다.

예상되는 인과 관계는 다음과 같습니다:

text 낮은 지연 시간 → 더 나은 서버 용량 → 실패하거나 지연된 가져오기 감소 → 더 빠른 발견 및 처리 → 색인 및 검색될 가능성 증가 → 인용 가능성 증가

인용 선택은 관련성, 품질, 신선도, 권위, 쿼리 의도, 검색 순위 및 각 인공지능 시스템의 동작에 따라 달라지기 때문에 최종 단계는 불확실합니다.

따라서 대부분의 웹사이트에 있어 올바른 성능 전략은 단순히 '인공지능 인용을 위한 최적화'가 아닙니다. 그것은 다음과 같습니다:

1. 초기 HTML에 중요한 콘텐츠를 유지하십시오.
2. 첫 바이트까지의 시간을 안정적으로 유지하십시오.
3. 공개 콘텐츠에 엣지 캐싱을 사용하십시오.
4. 중요한 이미지를 압축하고 우선순위를 지정하십시오.
5. 레이아웃 이동을 방지하십시오.
6. 신뢰할 수 있는 상태 코드를 반환하십시오.
7. 사이트맵과 내부 링크를 최신 상태로 유지하십시오.
8. 올바른 검색 크롤러를 허용하십시오.
9. 크롤링, 색인 생성, 검색 및 인용을 별개의 단계로 측정하십시오.

이러한 접근 방식은 사람들을 위한 더 빠른 웹사이트, 검색 크롤러를 위한 더 건강한 사이트, 그리고 인공지능 가시성을 이해하기 위한 테스트 가능한 기반을 제공합니다.