사이트 전체 평균이 아니라 여정에서 시작하세요
지연이 명확한 고객 또는 운영상의 비용을 초래하는 3~5개의 여정을 목록으로 만드세요: 캠페인 랜딩, 상품 찾기, 견적/리드 폼 제출, 로그인, 또는 지원 요청 완료 등. 각 여정에 대해 시작 지점, 유용한 결과, 주요 기기 클래스, 잘 작동해야 하는 페이지나 상호작용을 적습니다.
각 여정마다 별도의 예산 행을 만드세요. 대시보드는 공용 기사보다 코드가 많을 수 있지만 필터 동작은 반응성 목표가 필요합니다. 미디어가 많은 상품 페이지는 큰 이미지를 허용할 수 있지만 주요 표시 이미지에 대한 한도는 필요합니다. 이렇게 하면 약한 크리티컬 패스가 전체 평균에 묻히는 것을 방지합니다.
방문자가 볼 수 있거나 할 수 있는 것을 이름으로 정합니다. 예: 제안을 읽을 수 있음, 결과 보기, 폼 확인 수신 등.
캐싱은 자산 비용을 실질적으로 바꿀 수 있으므로 예산이 첫 방문, 반복 방문 또는 둘 다를 포함하는지 기록합니다.
결과와 제어 가능한 입력을 함께 선택하세요
결과 지표와 입력 한도를 모두 사용하세요. Google은 Largest Contentful Paint(LCP)를 로딩 성능으로, Interaction to Next Paint(INP)를 상호작용 반응성으로, Cumulative Layout Shift(CLS)를 시각적 안정성으로 설명합니다. 권장되는 좋은 임계값은 모바일과 데스크톱을 따로 고려할 때 75번째 백분위수 기준 LCP ≤ 2.5초, INP ≤ 200밀리초, CLS ≤ 0.1입니다.
원인을 조기에 드러내는 한도를 추가하세요: 초기 자바스크립트, 주요 콘텐츠 이전에 필요한 이미지, 경로의 총 전송량, 서드파티 요청 수, 그리고 알려진 고비용 위젯 등. 압축된 전송 크기를 일관되게 추적하세요. Time to First Byte와 같은 진단은 느린 로딩을 조사하는 데 도움이 될 수 있지만, 그 자체가 고객 결과는 아닙니다.
여정이 주요 콘텐츠의 가시성에 의존할 때 LCP를 사용하세요.
검색, 필터링, 메뉴, 결제 등에는 필드 INP를 사용하세요. 필드 데이터가 없을 때만 랩(시험실) 대역을 사용하세요.
초기 경로와 가장 큰 기여자를 제한해 소유자가 위반 후 어떤 것을 변경해야 하는지 알 수 있게 하세요.
기준선에서 수치를 설정하세요
각 여정에 대해 기준선을 캡처하세요. PageSpeed Insights에서 Chrome User Experience Report(CrUX) 필드 데이터(실제 Chrome 사용자 경험 집계)와 Lighthouse 랩 데이터(제어된 테스트)를 구분하세요. 필드 데이터는 사용자에게 도달하는 경험을 확인하고, 랩 테스트는 릴리스 전 변경을 반복 가능하게 만듭니다.
최소한 모바일과 데스크톱으로 분리하고 가능하면 중요한 템플릿이나 URL별로 세분화하세요. PageSpeed Insights는 URL 데이터가 없으면 오리진 데이터로 대체할 수 있으며 일부 페이지는 CrUX 데이터가 없습니다. 그런 경우를 랩 기준선으로 표시하고 중요한 여정에는 실사용자 측정(필드 데이터)을 추가하세요. 각 기준선에는 테스트 URL, 기기 및 네트워크 프로필, 캐시 상태, 날짜, 도구 버전을 함께 보관하세요.
기준선보다 개선되는 계획된 단계를 목표로 선택한 다음 대표 조건에서 테스트하세요. 정상 릴리스를 차단하는 예산은 우회될 것이고, 오늘의 경험보다 높게 설정된 예산은 누구도 보호하지 못합니다.
75번째 백분위수는 관찰된 경험의 75%가 그 값 이하에 위치함을 의미하며 평균이 아닙니다.
예산을 릴리스 규칙으로 만드세요
예산을 코드 또는 릴리스 체크리스트 옆의 버전 관리되고 검토 가능한 장소에 보관하세요. 각 행에는 여정, 지표, 테스트 프로필 또는 모집단, 경고 임계값, 에러 임계값, 담당자, 측정 방법, 예외 경로가 필요합니다. MDN은 경고 및 에러 수준을 권장합니다: 경고는 사전 계획을 지원하고, 에러는 눈에 띄는 부정적 효과가 있는 상한입니다.
신뢰할 수 있는 검사를 자동화하세요. 번들러는 과대한 자산이나 초기 진입점을 거부할 수 있습니다; webpack은 최대 자산 및 진입점 제한과 프로덕션 오류 힌트를 지원합니다. 풀 리퀘스트나 릴리스 후보에서 영향을 받는 여정에 대해 반복 가능한 랩 테스트를 실행하세요. 릴리스 전후 확인을 위해 필드 메트릭을 보관하되, 신뢰할 수 없는 빌드 게이트 대신 릴리스 이후 검증 및 우선순위 지정에 사용하세요.
한도가 실패하면 자산을 줄이거나 비필수 코드를 연기하고, 경험을 변경하거나 릴리스를 분리하거나 예외를 승인하세요. 빌드를 통과시키기 위해 한도를 묵인하고 올리지 마세요.
릴리스 전에 제품 및 기술 담당자, 고객 영향, 만료일, 시정 작업을 기록하세요.
보호된 여정에서 재현 가능한 에러 임계값을 차단하세요. 경고 임계값은 알리고 조사하세요.
출시 후 검증 및 시정 조치
페이지 중량은 전체 경험을 예측하지 못합니다. 요청 순서, 렌더 차단 작업, 기기 성능, 네트워크 조건, 캐싱, 서드파티도 모두 영향을 줍니다. 입력 한도를 유지해 성장을 포착하고 결과 측정으로 경로의 사용성을 시험하세요. W3C Resource Timing 인터페이스는 리소스 타이밍과 전송량, 인코딩 및 디코딩된 크기를 노출해 심층 진단을 돕습니다. 교차 출처 타이밍 세부정보는 타이밍 권한에 의해 제한될 수 있으므로 불완전한 워터폴이 서드파티 비용이 없음을 증명하지는 않습니다.
중요한 템플릿, 플랫폼, 마케팅 태그, 트래픽 변경 후에는 필드 결과를 검토하세요. LCP가 악화되면 서버 응답, LCP 리소스, 렌더 차단 작업을 점검하세요. INP가 악화되면 실제 상호작용을 검사하세요; Lighthouse는 사용자 입력이 없기 때문에 INP를 측정할 수 없으며 Total Blocking Time이 랩 프록시 역할을 합니다. SIU의 사전 예방적 최적화 워크플로를 사용해 위반을 분류하고 크리티컬 패스를 안정화하며 동일한 측정 컨텍스트에서 수정을 검증하세요.
만료된 예외는 일시적 성능 부채가 영구화된 사례를 빠르게 드러냅니다.