Lighthouse로 사이트 속도 측정과 개선 사항 확인하는 방법

Lighthouse는 웹페이지를 정해진 조건에서 검사해 성능·접근성·권장사항·검색엔진 최적화(SEO)의 문제와 개선 단서를 보여 주는 자동 진단 도구입니다. Chrome 개발자 도구의 Lighthouse 패널에서 페이지 로드를 분석한 뒤, 느린 지표에 연결된 요청·파일·실행 작업을 찾아 한 가지씩 수정하고 같은 조건으로 재측정하면 됩니다. 점수 하나를 실제 방문자 전체의 속도나 검색 순위로 해석하지 않는 것이 중요합니다.

Lighthouse와 PageSpeed Insights의 차이

Lighthouse 공식 안내에 따르면 Chrome 개발자 도구, 명령행, Node 모듈 등으로 검사를 실행할 수 있습니다. 처음 사용하는 독자라면 별도 확장 프로그램을 설치하기보다 데스크톱 Chrome에 포함된 패널로 시작할 수 있습니다. 로그인한 상태나 로컬 개발 페이지를 검사할 때도 이 경로가 유용합니다.

PageSpeed Insights 설명은 실험실 데이터와 현장 데이터를 구분합니다. 실험실 데이터는 Lighthouse가 특정 조건에서 생성한 진단이고, 실제 사용자 경험 데이터는 Chrome User Experience Report(CrUX)의 최근 28일 수집 자료입니다. 페이지 표본이 부족하면 출처 전체 자료가 표시되거나 실제 사용자 자료가 없을 수 있습니다. 이 경우 실험실 결과가 있다고 해서 해당 페이지의 실제 방문자 통계가 확보된 것은 아닙니다.

공개 URL을 빠르게 확인하려면 PageSpeed Insights에 주소를 입력해 분석하고 모바일·데스크톱 결과를 각각 선택합니다. 로그인 뒤에만 보이는 페이지나 외부에서 접근할 수 없는 로컬 URL은 이 외부 서비스보다 로컬 개발자 도구로 확인하세요. 비공개 주소나 접근 토큰을 외부 분석 서비스에 넣지 않습니다.

공개 예제 주소를 분석한 PageSpeed Insights 결과에서 실제 사용자 경험과 성능 진단 영역을 구분하는 화면

위 화면은 공개 예제 주소의 PageSpeed Insights 진단을 확인한 예시입니다. 표시된 값과 점수는 그 실행 조건의 결과이며, 이 사이트나 독자 사이트의 성능을 나타내는 수치가 아닙니다. 보고서에서는 실제 사용자 경험 영역과 Lighthouse 진단 영역을 구분해서 읽습니다.

측정 전에 페이지와 조건 정하기

  • 대상: 홈페이지뿐 아니라 실제 방문자가 사용하는 대표 글·목록·상품 등 검사할 URL을 구체적으로 정합니다. 서로 다른 템플릿의 결과를 같은 페이지의 전후 비교로 섞지 않습니다.
  • 상태: 첫 방문인지 재방문인지, 로그인 여부와 동의 배너 처리 상태를 기록합니다. 로그인이 필요 없는 공개 페이지라면 확장 프로그램 영향을 줄인 별도 프로필이나 시크릿 창을 사용할 수 있습니다.
  • 환경: Chrome·Lighthouse 버전, 모바일·데스크톱 선택, 네트워크·CPU 제한 방식과 측정 시각을 기록합니다. 다른 대용량 다운로드나 무거운 작업을 함께 실행하지 않습니다.
  • 저장소: Clear storage는 사이트 저장소를 정리해 초기 방문에 가까운 조건을 만드는 선택입니다. 로그인·동의 상태에 영향을 줄 수 있으므로 꼭 필요한 작업이 열린 세션에서 무심코 실행하지 마세요. 로그인 페이지를 검사할 때는 해당 상태를 유지하는 설정으로 정하고 이후 비교에도 같게 적용합니다.

로그인한 관리자 화면을 보고 측정하면 비로그인 방문자와 다른 스크립트·도구 모음·캐시 정책이 적용될 수 있습니다. 실제 독자 경험을 보려면 비로그인 공개 화면을 따로 측정해야 합니다. 반대로 로그인 사용자를 위한 기능이 대상이면 그 상태 자체를 명확히 기록합니다.

Chrome 개발자 도구에서 페이지 로드 분석

  1. 데스크톱 Chrome에서 검사할 페이지를 엽니다. 예를 들어 공개 페이지의 주소가 맞는지 먼저 확인하고, 페이지가 오류 화면으로 리디렉션되지 않는지 봅니다.
  2. F12 또는 Ctrl+Shift+I로 개발자 도구를 엽니다. Lighthouse 탭이 보이지 않으면 탭 넘침 메뉴나 개발자 도구 메뉴의 More tools에서 Lighthouse를 찾습니다. 메뉴 이름은 브라우저 언어와 버전에 따라 달라질 수 있습니다.
  3. 처음 페이지 로드를 검사하려면 Mode를 Navigation으로 선택합니다. Device는 Mobile 또는 Desktop 중 하나를 정합니다. 모바일 모드는 실제 모든 휴대전화의 성능을 재현하는 것이 아니라 선택한 제한 조건에 따른 실험실 검사입니다.
  4. Categories에서 Performance를 선택하고, 필요하면 Accessibility·Best Practices·SEO도 함께 선택합니다. 저장소 정리와 throttling 설정을 확인하고 비교할 때 같은 값으로 유지합니다.
  5. Analyze page load 또는 해당 버전의 분석 시작 버튼을 누릅니다. 페이지가 다시 로드되므로 작성 중인 폼 등 미저장 내용을 먼저 보관합니다. 분석하는 동안 다른 조작을 하지 말고 보고서가 나올 때까지 기다립니다.
  6. 대상 URL·최종 URL·설정·버전이 맞는지 확인하고 보고서를 HTML 또는 JSON으로 보관합니다. 내보내기 메뉴의 파일 형식 선택이 제공되는 버전에서는 필요한 형식을 고릅니다. 보고서에 내부 주소나 진단 정보가 들어갈 수 있으므로 공유 범위도 확인합니다.

기본 로드 검사와 다른 시나리오는 모드를 바꿉니다. Lighthouse 사용자 흐름 문서에서 Navigation은 한 번의 탐색, Timespan은 상호작용을 포함한 일정 구간, Snapshot은 현재 페이지 상태를 검사합니다. Timespan·Snapshot 결과를 Navigation의 전체 성능 점수와 동일하게 비교해서는 안 됩니다. 메뉴를 연 상태의 접근성처럼 특정 상태가 질문일 때 Snapshot을 검토합니다.

점수보다 먼저 읽을 지표와 개선 단서

성능 점수 계산 설명에서 점수는 측정 지표를 변환한 가중 평균입니다. 진단 항목의 경고 개수를 줄였다고 점수가 같은 폭으로 오르는 구조가 아닙니다. 90~100은 양호, 50~89는 개선 필요, 0~49는 낮음으로 표시되지만, 이 색 구간은 특정 실행의 점수 해석이며 실제 사용자에게 허용되는 모든 지연의 기준은 아닙니다.

지표 무엇을 보는가 우선 확인할 단서
FCP: First Contentful Paint 첫 콘텐츠가 표시되기까지의 시간 초기 서버 응답, 렌더링을 막는 스타일·스크립트
LCP: Largest Contentful Paint 화면의 큰 주요 콘텐츠가 표시되는 시점 보고서가 지목한 요소, 이미지 요청 시작·전송·표시 지연
TBT: Total Blocking Time 로드 중 긴 작업이 메인 스레드를 차단한 시간의 합 긴 자바스크립트 실행, 불필요한 초기 스크립트와 타사 코드
CLS: Cumulative Layout Shift 예상하지 못한 배치 이동의 정도 크기 예약 없는 이미지·광고, 뒤늦게 삽입되는 요소
Speed Index 시각적 콘텐츠가 채워지는 진행 속도 화면 기록과 함께 초기 표시가 늦어지는 구간

TBT 설명에서 긴 작업은 50ms를 초과하는 작업이며, 그 초과분을 차단 시간으로 더합니다. TBT는 실제 사용자 입력마다 측정하는 INP(Interaction to Next Paint)와 같은 지표가 아닙니다. 실제 사용자 Core Web Vitals의 LCP·INP·CLS는 현장 데이터에서 별도로 확인해야 합니다.

보고서의 Insights·진단 항목을 펼쳐 영향을 받은 요소와 리소스를 확인합니다. 예를 들어 LCP 요소가 첫 화면 이미지라면 그 이미지의 전송 크기와 요청 시점부터 보고, 배치 이동이 큰 경우에는 이미지·광고 공간 예약 여부를 확인합니다. 첫 화면의 중요한 이미지를 단순히 지연 로딩으로 바꾸거나 모든 스크립트를 같은 방식으로 늦추면 오히려 필요한 표시·기능이 나빠질 수 있으므로 원인과 사용 위치를 먼저 확인합니다.

상세 원인 분석은 Chrome의 Lighthouse와 Performance 패널 안내처럼 Performance 패널의 기록·Insights로 이어갈 수 있습니다. Accessibility와 SEO의 높은 점수도 전체 접근성 준수나 검색 상위 노출을 인증하는 것은 아닙니다. 자동 검사에서 다루지 못하는 키보드 조작·실제 콘텐츠 품질 등의 검토가 남습니다.

한 가지를 수정하고 같은 조건으로 다시 측정

  1. 보고서에서 사용자에게 영향이 크고 원인이 구체적인 항목 하나를 고릅니다. 예를 들어 첫 화면 이미지가 과도하게 큰 경우에는 표시 크기에 맞는 이미지 선택을 먼저 실험합니다.
  2. 변경 전 파일·설정과 보고서를 보관합니다. 로컬 또는 검증 환경에서 변경하고, 배포 뒤 캐시가 새 파일을 제공하는지도 확인합니다. 속도 점수를 높이려고 필요한 기능을 숨기거나 검사에서만 다른 페이지를 제공하지 않습니다.
  3. 동일한 URL·로그인 상태·기기 모드·제한 설정으로 여러 번 측정합니다. 한 번의 최고점 대신 원시 지표와 반복 실행의 범위·중앙값을 함께 비교합니다. 예를 들어 각 조건을 5회 측정하는 방식을 정했다면 변경 전후 모두 그 횟수를 유지합니다.
  4. 목표 지표가 나아졌는지와 함께 화면·버튼·폼·키보드 조작이 정상인지 확인합니다. 개선이 없거나 기능이 나빠지면 보관한 파일·설정으로 되돌리고 다른 원인을 검사합니다.

측정 변동성 안내는 네트워크·기기·서버·페이지 자체의 변화 때문에 코드 수정이 없어도 점수가 달라질 수 있다고 설명합니다. 광고와 동의 배너의 상태도 비교 조건입니다. 보고서에는 실행 날짜·URL·도구 버전·설정·지표·변경한 항목을 남기고, 실제 사용자 지표는 충분한 수집 기간과 표본이 쌓인 뒤 평가합니다.

분석이 실패하거나 결과가 크게 다른 경우

페이지가 열리지 않거나 접근 차단·리디렉션 오류가 있으면 점수부터 해석하지 말고 최종 도달 URL과 정상 HTTP 응답을 확인합니다. 비공개 페이지를 외부 검사에 열기 위해 인증을 해제하지 마세요. 로컬 측정은 로그인 상태와 저장소 정리 설정을 확인하고, 확장 프로그램 영향이 의심되면 동일한 대상에 대해 확장 영향이 적은 환경으로 다시 검사합니다.

PageSpeed Insights와 내 PC의 점수가 다르면 실패라고 단정하지 않습니다. 두 실행의 Lighthouse 버전·서버 접근 경로·기기와 제한 설정·쿠키 상태가 같은지부터 봅니다. 모바일과 데스크톱 점수를 직접 맞추려 하지 말고 각 조건 안에서 전후 변화와 실제 방문자의 지표를 비교하세요.