웹사이트 성능 리포트, 기술 작업을 보여주는 대시보드

바이탈에 관한 모든 대화는 같은 질문으로 끝납니다: 어느 페이지인가. 이 리포트는 두 측정치를 나란히 두어 답합니다. 필드 백분위는 방문자가 실제로 겪은 값입니다: Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift를 75번째 백분위 기준으로, Google 자체의 양호·불량 기준선과 함께 봅니다. 랩 진단은 크롤러가 각 URL에서 통제된 조건으로, 수정이 배포되는 그날 요청 시점에 측정한 값입니다. 하나는 사이트가 통과하는지를 말해 주고, 다른 하나는 어느 템플릿이 원인인지 말해 줍니다.

진단된 페이지 테이블이 바로 이 짝이 드러나는 곳입니다. 크롤링된 모든 URL은 각자의 네 점수를 각자의 랩 LCP·CLS 옆에 지니고 있고, 판정 도넛 차트는 몇 페이지가 확실히 통과하고, 몇 페이지가 개선이 필요하며, 몇 페이지가 실패하는지 셉니다. 그래서 사이트가 느리게 느껴진다는 느낌은 템플릿과 그 뒤의 트래픽, 원인이 된 지표까지 명시하는 작업 지시서가 됩니다. Google이 공개하는 속성 단위 추이와 기기 분포는 Search Console 리포트에 속하고, 이 페이지는 그 아래의 벤치 테스트로 남습니다.

개선 기회 탭은 진단이 찾아낸 것과 고쳤을 때의 가치를 함께 나열합니다: 렌더 차단 리소스, preconnect 힌트, 서버 응답 시간은 밀리초 단위로, 용량이 큰 이미지, 차세대 포맷, 화면 밖 미디어, 사용하지 않는 자바스크립트, 압축하지 않은 CSS, 캐시 유지 기간은 키비바이트 단위로. 모든 행은 해당 영역과 절약 규모에서 도출된 심각도를 함께 지니므로, 개발자의 견적과 대행사의 우선순위가 서로 다른 두 개의 내보내기가 아니라 같은 목록에서 논의될 수 있습니다.

진단은 할 일 목록이 아니라 설명으로 그 옆에 놓입니다: DOM 크기, 메인 스레드 작업, 자바스크립트 실행 시간, 요청 수, 전송 용량, 중요 요청 체인, Largest Contentful Paint를 결정하는 요소, 페인트 이후에도 움직이는 요소까지. 각각은 밑돌아야 할 목표치와 그것이 왜 중요한지 알려 주는 평이한 한 문장을 함께 가지고 있으며, 대개 이것이 클라이언트가 자기 개발자에게 그대로 전달하는 리포트와 질문을 들고 돌아오는 리포트의 차이를 만듭니다.

자동 접근성 점검은 실제로 수정 범위를 나누는 방식, 곧 영향도별로 묶입니다. 레이블 없는 입력창, 대체 텍스트 없는 이미지 같은 치명적 발견은 대비 실패, 이름 없는 링크 같은 심각한 문제와 따로 놓이고, 이는 다시 탭 영역 크기, 제목 순서, 포커스 순서 같은 보통 수준의 문제와 나뉩니다. 모든 행은 관련된 요소 수를 함께 지니므로, 견적은 막연히 접근성을 개선하겠다는 약속이 아니라 숫자에서 만들어집니다.

이 리포트는 자동 점검이 무엇을 다루는지에 관해 일부러 정직합니다. 이런 점검은 수동 검토가 찾아내는 장벽의 일부만 잡아내며, 화면에도 그렇게 표시됩니다. 클라이언트가 깨끗한 결과를 준수 인증서처럼 읽는 것을 막아 주는 장치입니다. 제대로 쓰면 가장 저렴한 첫 번째 점검입니다: 기계적 오류를 정리하고, 무엇을 언제 고쳤는지 기록을 남기며, 수동 점검이 다뤄야 할 범위를 훨씬 줄여 줍니다.

크롤과 마크업 점검 열 가지가 통과·실패 목록으로 실행되며, 크롤이 무엇을 발견했는지 설명하는 한 문장이 함께 표시됩니다: 제목 요소, 메타 설명, 크롤 가능한 링크, 캐노니컬 선언, hreflang 주석, 유효한 robots 파일, 이미지 alt 속성, 읽기 쉬운 글자 크기, 탭 영역 간격, 구조화 데이터 유효성까지. 테이블 위에는 헤드라인 숫자가 있어, 열 가지 중 몇 가지가 깨끗하고 몇 가지가 아직 해야 할 작업인지 가장 먼저 보여줍니다.

이것은 온페이지 점검이지 색인 리포트가 아닙니다: Google이 무엇을 유지하기로 했는지가 아니라 크롤러가 페이지에서 읽어낼 수 있는 것을 다룹니다. 둘은 다른 질문에 답하고 다른 곳에 속하므로, 색인 생성 현황과 검색어, 노출수는 Search Console 리포트에 있고 이 페이지는 마크업에 머뭅니다. 둘을 함께 검토하는 것이 일반적인 흐름입니다: 먼저 이 점검이 표시한 것을 고치고, 이후 몇 주에 걸쳐 색인 생성 현황과 순위가 어떻게 반응하는지 지켜봅니다.

모든 진단은 워크스페이스 전환기를 통해 클라이언트 한 곳으로 한정되고 대행사 브랜드로 표시되어, 같은 구조가 1월 리뷰도 6월 리뷰도 모두 담당합니다. 점수, 바이탈, 개선 기회, 진단, 접근성, 기술 점검이 계약 기간 내내 같은 자리를 지키므로, 월별 비교는 서로 다르게 짜인 두 문서를 맞춰 보는 일이 아니라 같은 섹션을 두 번 읽는 일이 됩니다. 워크스페이스는 검토 화면을 제공하고, 데이터 소스 연결은 별도의 단계로 남습니다.

이 반복이야말로 기술 작업을 클라이언트가 계약을 연장하게 만드는 이유입니다. 개발자는 예상 절감치가 붙은 순위 매긴 수정 목록을 보고, 계정 매니저는 네 개의 점수와 상태 수치, 그 뒤의 페이지를 봅니다. 그리고 둘 다 같은 리포트를 보고 있습니다. 팀은 프레젠테이션 레이아웃을 새로 만드는 대신 다음에 무엇을 고칠지 정하는 데 시간을 씁니다. 그러면 진단은 더 이상 아무도 쓰고 싶어하지 않는 산출물이 아니게 됩니다.