구글 페이지스피드 인사이트(PSI)가 라이트하우스 13.6.0을 쓰기 시작했다. 이 버전은 페이지가 얼마나 빨리 뜨는지 추정하는 시뮬레이션 방식을 바꿨다. 그 결과 페이지에 손대지 않았는데도 점수가 달라지는 일이 생길 수 있다. 자사 사이트의 랩 점수를 성과 지표로 보고하는 마케터는 점수 변동의 원인부터 확인해야 한다.

PSI는 웹페이지의 성능을 모바일과 데스크톱 기준으로 평가하고 개선 방법을 제안하는 구글의 도구다. 이 매체에 따르면 크롬 웹 성능 개발자 옹호 담당 배리 폴라드가 소셜미디어 블루스카이에서 PSI에 라이트하우스 13.6.0이 반영됐다고 밝혔다. 폴라드는 시뮬레이션된 FCP(첫 콘텐츠가 화면에 그려지는 시간)와 시뮬레이션된 LCP(가장 큰 콘텐츠가 그려지는 시간)가 이전보다 정확해지고, 대체로 점수가 높아질 것이라고 설명했다. 라이트하우스 13.6.0은 10월 27일 공개됐다.

렌더링 차단 판정 기준이 바뀌었다

라이트하우스는 기본적으로 페이지를 제 속도로 불러온 뒤, 느린 연결에서 어떻게 로딩될지 추정한다. 이 추정을 맡는 시뮬레이션 엔진이 란턴(Lantern)이다. 서치엔진저널은 란턴 관련 문서가 이 방식이 PSI의 설정과 같다고 밝힌다고 전했다. 13.6.0 릴리스 노트에는 란턴의 정확도를 높이기 위한 변경이 여러 개 올라 있다.

첫 번째는 렌더링 차단 판정이다. 라이트하우스 13.5는 각 요청의 가져오기 우선순위(fetch priority)를 보고 그 요청이 화면 렌더링을 막는지 판단했다. 13.6에서는 크롬이 요청마다 붙이는 렌더링 차단 표시를 쓴다. 이 표시가 없을 때만 예전처럼 우선순위를 본다.

두 번째는 텍스트 LCP 추정이다. LCP 요소가 텍스트이고 페이지의 첫 콘텐츠와 같은 프레임에 나타나면, 란턴은 이제 FCP를 계산할 때 쓰는 요청과 페이지 작업만으로 LCP를 추정한다. 예전에는 LCP 이전에 발생한 모든 요청이 섞일 수 있는 범위를 썼다.

개발자 이슈에서 드러난 문제

이 변경의 배경에는 이반 아쿨로프가 깃허브에 올린 이슈가 있다. 서치엔진저널에 따르면 아쿨로프는 프레이머(Framer)로 만든 테스트 페이지를 보여줬다. 이 페이지는 화면 첫 영역에 텍스트만 있어서 한 요소가 FCP이자 LCP였다. 그런데 옛 시뮬레이션은 같은 텍스트인데도 LCP를 FCP보다 훨씬 늦게 보고했다. 페이지의 자바스크립트 모듈을 미리 불러오면 실제 페이지의 상호작용 가능 시점은 빨라졌지만, 시뮬레이션된 LCP는 오히려 나빠졌다. 폴라드는 아쿨로프에게 감사를 전하며 그가 이런 개선 일부를 시작했다고 답했고, 라이트하우스 팀은 이 이슈를 란턴 업그레이드로 해결됐다며 닫았다.

자바스크립트가 많은 사이트가 더 큰 영향을 받는다

폴라드는 SPA(단일 페이지 앱)가 라이트하우스 업데이트 뒤 결과가 크게 좋아졌다고 올린 개발자의 글을 인용하며 동의했다. 그 개발자는 react.dev를 예로 들었다. 폴라드는 이 변화가 SPA에만 해당하는 것이 아니라고 선을 그었다. 다만 자바스크립트 비중이 큰 사이트가 영향을 받을 가능성이 더 높다고 설명했다.

혼동하기 쉬운 것이 하나 있다. 크롬이 실험 중인 소프트 내비게이션 지표는 이번 변경과 별개다. 이 지표의 데이터는 크롬 실사용자 경험 보고서(CrUX)를 통해 실제 크롬 사용자에게서 온다. 라이트하우스는 시뮬레이션 테스트다.

에이전트 리소스 디스커버리 감사도 바뀌었다

점수와 별개로 감사 항목도 달라졌다. 에이전트 리소스 디스커버리(ARD) 감사는 AI 에이전트가 사이트의 리소스를 찾을 수 있게 안내하는 매니페스트가 있는지 검사하는 항목이다. 13.5는 규격이 ard.json으로 바뀌었는데도 옛 ai-catalog 이름 아래에서만 매니페스트를 찾았다. 그래서 새 이름만 쓰고 robots.txt에 Agentmap 줄을 넣지 않은 사이트는 '해당 없음'으로 표시됐다.

13.6은 Agentmap 줄, rel="ard" 링크 태그나 Link 헤더, /.well-known/ard.json을 먼저 확인하고 그다음에 ai-catalog 이름을 찾는다. 매니페스트가 ai-catalog 위치에서만 발견되면, ARD 소비자가 그 위치를 확인할 의무는 없다는 안내를 함께 표시한다.

랩 점수와 실사용자 데이터는 다르다

PSI 공식 문서에 따르면 랩 데이터는 라이트하우스가 단일 기기와 고정된 네트워크 조건에서 페이지 로딩을 시뮬레이션해 만든 결과다. 통제된 환경에서 수집하므로 문제 진단에는 유용하지만 실제 사용 환경의 병목은 놓칠 수 있다. 문서는 랩 데이터가 좋다고 실사용자 경험까지 좋다는 뜻은 아니라고 안내한다. 점수는 90 이상이면 좋음, 50에서 89는 개선 필요, 50 미만은 나쁨이다.

현장 데이터는 CrUX가 집계한 최근 28일간의 실제 방문 경험이다. 같은 리포트에 함께 표시되고, 75번째 백분위수 값으로 보고된다. 문서는 이 값을 좋음, 개선 필요, 나쁨으로 분류한다. 라이트하우스 버전은 PSI 리포트에서 에뮬레이션된 기기 옆에 표시된다.

보고서에 쓰기 전에 버전부터 확인한다

서치엔진저널은 라이트하우스 13.6 업데이트 전후의 PSI 점수가 같은 시뮬레이션으로 측정된 값이 아니라고 지적한다. 방금 최적화한 페이지의 랩 점수 상승분 중 일부는 새 버전 덕일 수 있고, 랩 점수를 시계열로 추적하는 차트는 13.6 적용 시점에 점프가 보일 수 있다. 이 매체는 개선을 보고하기 전에 두 리포트의 라이트하우스 버전이 같은지 확인하고 현장 데이터도 함께 비교하라고 권한다.

앞으로의 일정도 있다. 라이트하우스 릴리스 노트는 13.6이 크롬 159의 개발자 도구에 들어갈 것으로 예상한다. 크롬 159는 현재 데스크톱 Dev 채널과 카나리에 있고, 11월 2일 기준 크롬 릴리스 일정상 안정판 출시는 12월 8일이다. 라이트하우스 깃허브에는 란턴의 시뮬레이션 LCP가 실제 측정 LCP보다 훨씬 높게 나오는 사례를 조사하는 이슈도 열려 있다. 대형 자바스크립트 사이트와 SPA가 사례로 올라와 있다.

국내 담당자가 확인할 지점

변경은 PSI가 쓰는 라이트하우스 시뮬레이션 자체에 관한 것이므로, 자바스크립트 비중이 큰 사이트 담당자라면 자사 점수가 움직였는지 우선 살펴볼 만하다. 점수가 달라졌다면 PSI 리포트의 라이트하우스 버전 표기를 먼저 보고, 변동이 13.6 적용 시점과 겹치는지 확인한다. 성과 보고에 쓸 개선 폭은 CrUX 현장 데이터와 나란히 놓고 해석하는 편이 안전하다.