페이지 속도는 AI 검색에서 무엇을 하고 무엇을 하지 않나

먼저 결론부터 적겠습니다. 페이지 속도를 올리면 AI 답변에 더 자주 인용된다는 공개된 근거는 없습니다. 그래서 속도를 인용 성과 지표로 두면 다음 달에 설명할 수 없는 숫자가 남습니다.

그렇다고 볼 필요가 없는 값은 아닙니다. 속도는 수집이 성공하는지의 문제로 다루면 정확합니다.

수집이 끊기는 구간

페이지를 열어 보는 쪽은 응답을 무한정 기다리지 않습니다. 첫 바이트가 늦게 오면 요청이 중단되고, 그 페이지는 내용 없이 실패로 남습니다.

여기서 볼 값은 화면이 다 그려지는 시간보다 응답이 시작되는 시간입니다. 서버가 첫 바이트를 보내기까지 몇 초가 걸리는지를 봅니다. 이 값이 큰 원인은 대개 세 가지입니다.

1. 요청마다 데이터베이스를 여러 번 조회하는 페이지 구조
2. 캐시가 없거나 캐시 적중률이 낮은 상태
3. 외부 API 응답을 기다린 뒤에 HTML을 만드는 순서

세 가지 모두 화면 애니메이션이나 이미지 최적화와는 다른 작업입니다. 이미지를 줄여도 첫 바이트 시간은 그대로인 경우가 많습니다.

그래서 무엇을 보는가

세 번째 줄을 두 번째 줄과 섞지 않는 것이 이 글의 요지입니다. 화면 표시 지표는 사용자 이탈을 줄이는 근거로 충분하지만, AI 인용의 근거로 쓰면 설명이 어긋납니다.

측정값이 비어 있을 때

성능 측정은 실패하거나 데이터가 없는 경우가 자주 있습니다. 이때 세 가지를 구분해야 합니다.

• 측정 실패는 성능 나쁨이 아닙니다. 값이 없는 상태와 값이 나쁜 상태를 같은 칸에 적으면 리포트가 틀립니다.
• 미측정 항목은 점수에 넣지 않습니다. 없는 값을 0으로 두면 점수가 실제보다 낮게 나오고, 다음 달에 측정이 성공하면 개선한 것이 없는데 점수가 오릅니다.
• 한 페이지 측정은 사이트 전체 결론이 아닙니다. 대표 페이지 한 건으로 측정했다면 그 사실을 함께 적습니다.

이번 주에 할 일

1. 핵심 페이지 5개의 응답 시작 시간을 재고 표에 적습니다.
2. 응답이 실패하는 페이지가 있는지 확인합니다. 있으면 이것이 속도 개선보다 앞순위입니다.
3. 리포트에서 화면 표시 지표를 AI 인용 항목 아래에서 빼내 사용자 경험 항목으로 옮깁니다.

3번은 코드 수정이 아니라 리포트 구조 정리인데, 다음 달 회의에서 설명할 수 있는 숫자를 남기는 데는 이쪽이 더 크게 작용합니다.