SQL을 사용한 프런트엔드 안정성 모니터링
프런트엔드 안정성은 단일 사이트 전체 성능 점수 그 이상입니다. 유용한 조사에는 개별 지표, 해당 단위, 안정적인 경로, 프런트엔드 릴리스 및 일반적인 변형과 회귀를 구별할 수 있는 충분한 샘플이 필요합니다. 구조화된 브라우저 이벤트는 이러한 경계를 명시적으로 만들고 동일한 SQL이 릴리스 검토, 대시보드 및 사고 대응을 지원하도록 합니다.
제한된 브라우저 이벤트 디자인
metric_name, metric_value, metric_unit, route_template, release, threshold_version, passed를 사용하여 지원되는 측정당 하나의 이벤트를 방출합니다. environment. 원시 URL이 아닌 /projects/:id와 같은 경로를 사용하십시오. 실제 결정이 변경되는 경우에만 제한된 장치 클래스를 추가하면 세그먼트가 충분한 샘플을 받게 됩니다.
쿼리 문자열, DOM 콘텐츠, 양식 값, 쿠키, 인증 데이터 또는 무제한 사용자 식별자를 수집하지 마세요. 정의와 제품 타겟은 코드 릴리스와 관계없이 변경될 수 있으므로 임계값 버전을 유지하세요.
경로 및 릴리스 비교
코어 웹 바이탈 SQL 레시피는 LCP, INP 및 CLS 측정을 경로 및 릴리스당 하나의 행으로 피벗합니다. 메트릭 평균 옆에 샘플 수와 합격 샘플 비율을 유지하고 결정론적 입력 행을 포함하며 브라우저 SQL 놀이터에서 실행할 수 있습니다.
다음 순서로 결과를 사용하십시오.
- 샘플 볼륨과 관찰 창이 비슷한지 확인합니다.
- 가장 약한 통과 샘플 속도로 경로를 찾고 릴리스합니다.
- 요약을 원인으로 다루기보다는 이동한 개별 바이탈을 검사합니다.
- 릴리스를 이전 릴리스와 비교하고 전체 시간 버킷에서 복구를 확인합니다.
프로덕션 보고에는 평균뿐만 아니라 백분위수를 활용하는 경우가 많습니다. 추가할 때 동일한 경로, 릴리스, 메트릭 및 단위 계약을 유지하십시오.
릴리스 가드레일 구축
대시보드에는 샘플 수, LCP, INP, CLS 및 임계값 버전이 표시되어야 합니다. 릴리스 가드레일에는 검토된 최소 볼륨과 지속적인 회귀가 필요합니다. 하나의 희박한 장치 또는 경로 세그먼트로 인해 배포를 차단해서는 안 됩니다.
프런트엔드 성능 사용 사례는 계측 프롬프트 및 검토 체크리스트를 제공합니다. 브라우저 텔레메트리 프록시 가이드를 사용하여 Telemetry API 키를 서버 측에 유지하고 허용 목록에 있는 브라우저 계약을 시행하세요. 느린 페이지가 백엔드 경로 또는 종속성에서 시작될 수 있는 경우 브라우저 환경을 API 안정성 SQL와 페어링합니다.