라이트하우스 성능 점수 계산법과 지표별 가중치

글 DATAPREPREP · 2026-10-25 기준

라이트하우스는 구글 크롬 팀이 만든 웹 페이지 품질 검사 도구이고, 성능 점수는 지표 5개의 점수를 가중 평균한 값입니다. 가중치가 가장 큰 지표는 TBT(30%)입니다. 구글 검색 순위 시스템이 쓴다고 적은 것은 이 점수가 아니라 실제 사용자 데이터로 판정하는 Core Web Vitals 입니다.

라이트하우스는 페이지를 실험실 환경에서 한 번 불러와 성능, 접근성, 권장사항, SEO 범주를 검사하는 도구입니다. PageSpeed Insights 아래쪽 진단도 이 도구가 만듭니다.

성능 점수는 0에서 100 사이 숫자 하나로 나옵니다. 숫자 하나가 어떤 지표로 이루어지는지 알면 무엇을 고쳐야 점수가 움직이는지 보입니다.

발견 01

성능 점수는 지표 5개 점수의 가중 평균이고, 진단 항목은 점수에 직접 들어가지 않습니다

지표	Lighthouse 화면 이름	재는 것	가중치(13.5.0)	Lighthouse 8 가중치
FCP	First Contentful Paint	첫 콘텐츠가 그려진 시점	10%	10%
SI	Speed Index	화면이 채워지는 속도	10%	10%
LCP	Largest Contentful Paint	가장 큰 요소가 그려진 시점	25%	25%
TBT	Total Blocking Time	로딩 중 기본 스레드가 차단된 시간	30%	30%
CLS	Cumulative Layout Shift	화면이 밀린 정도	25%	15%

가중치는 Lighthouse 13.5.0 설정 파일(default-config.js) 값이고, 공식 문서의 「Lighthouse 10」 표와 같습니다. Lighthouse 8 에 있던 Time to Interactive(10%)는 가중치 0이 되었습니다.

The Performance score is a weighted average of the metric scores. The metric scores are not visible in the report, but are calculated under the hood.

성능 점수는 지표 점수의 가중 평균이다. 지표별 점수는 보고서에 보이지 않고 내부에서 계산된다.

Chrome for Developers 「Lighthouse performance scoring」 (문서 수정일 2019-09-19) · 최종 확인일 2026-10-25 · https://developer.chrome.com/docs/lighthouse/performance/performance-scoring

점수에 들어가는 것	원문
지표만 들어감	In general, only metrics contribute to your Lighthouse Performance score, not the results of Opportunities or Diagnostics.대체로 성능 점수에는 지표만 들어가고, 추천·진단 항목의 결과는 들어가지 않는다.
한국어 화면의 진단 설명	애플리케이션 성능과 관련된 추가 정보입니다. 이러한 숫자는 성능 점수에 직접적인 영향을 미치지 않습니다.
한국어 화면의 지표 안내	값은 추정치이며 달라질 수 있습니다. 이러한 측정항목에서 성능 점수가 직접 계산됩니다.

「추천」·「진단」 항목을 고치면 지표가 좋아져 점수가 간접적으로 오릅니다. 한국어 문구는 Lighthouse 화면에 나오는 공식 번역입니다.

발견 02

TBT 가 30%로 가장 무겁고, 지표 점수는 실제 웹사이트 분포에 놓아 매깁니다

점수 매기는 법	원문
지표 값을 점수로 바꾸는 기준	The scoring distribution is a log-normal distribution derived from the performance metrics of real website performance data on HTTP Archive.점수 분포는 HTTP Archive 의 실제 웹사이트 성능 데이터에서 만든 로그 정규 분포다.
50점과 90점의 자리	The 25th percentile of HTTP Archive data becomes a score of 50 (the median control point), and the 8th percentile becomes a score of 90 (the good/green control point).HTTP Archive 데이터의 25번째 백분위수가 50점(중앙 기준점), 8번째 백분위수가 90점(좋음 기준점)이 된다.
만점	A "perfect" score of 100 is extremely challenging to achieve and not expected.100점 만점은 매우 어렵고, 기대되는 값도 아니다.
높은 점수일수록 어려움	For example, taking a score from 99 to 100 needs about the same amount of metric improvement that would take a 90 to 94.99점을 100점으로 올리는 데 드는 지표 개선은 90점을 94점으로 올리는 것과 비슷하다.

지표 값(밀리초 등)을 실제 웹사이트 데이터 분포 위에 놓아 0~100 점수로 바꿉니다. 같은 1점이라도 높은 구간에서 더 많은 개선이 필요합니다.

점수	색	원문
0~49	빨강	0 to 49 (red): Poor0~49점(빨강): 나쁨
50~89	주황	50 to 89 (orange): Needs Improvement50~89점(주황): 개선 필요
90~100	초록	90 to 100 (green): Good90~100점(초록): 좋음

PageSpeed Insights 문서도 같은 구간을 적었습니다. 90 이상이 「좋음」입니다.

TBT 는 클릭 반응을 재는 INP 를 실험실에서 대신 보는 지표입니다. 실험실에는 클릭하는 사람이 없어 INP 를 잴 수 없기 때문입니다.

그래서 성능 점수의 50%만 Core Web Vitals 지표(LCP·CLS)이고, 나머지는 실험실에서 쓰는 보조 지표입니다.

TBT 와 INP	원문
실험실 도구의 한계	Tools like Lighthouse that load pages in a simulated environment without a user cannot measure INP, as there is no user input.Lighthouse 처럼 사용자 없이 모의 환경에서 페이지를 불러오는 도구는 사용자 입력이 없어 INP 를 잴 수 없다.
TBT 의 자리	TBT may be a reasonable proxy metric for INP for the lab but it's not a substitute for INP in and of itself.TBT 는 실험실에서 INP 를 대신 보는 지표로 쓸 만하지만, INP 자체를 대체하지는 못한다.

TBT 를 줄이는 방법은 INP 를 줄이는 방법과 같습니다. 긴 스크립트 작업을 쪼개고 안 쓰는 스크립트를 걷습니다.

발견 03

구글 검색 순위 시스템이 쓴다고 적은 것은 라이트하우스 점수가 아니라 실제 사용자 데이터의 Core Web Vitals 입니다

질문	원문
순위에 쓰이는 것	Core Web Vitals are used by our ranking systems.코어 웹 바이탈은 구글 순위 시스템에서 사용된다.
실험실 점수와 실제 경험	Any green score (90+) is considered good, but note that having good lab data does not necessarily mean real-user experiences will also be good.녹색 점수(90점 이상)는 좋음으로 보지만, 실험실 데이터가 좋다고 실제 사용자 경험도 반드시 좋은 것은 아니다.
실험실 측정의 자리	While lab measurement is an essential part of delivering great experiences, it is not a substitute for field measurement.실험실 측정은 좋은 경험을 만드는 데 꼭 필요하지만, 실제 사용자 측정을 대신하지는 못한다.
점수가 흔들리는 이유	A lot of the variability in your overall Performance score and metric values is not due to Lighthouse.성능 점수와 지표 값이 흔들리는 원인은 대부분 Lighthouse 가 아니라 측정 조건의 변화다.
점수를 대하는 법	These scores are meant to help you to improve your site for your users overall, and trying to get a perfect score just for SEO reasons may not be the best use of your time.이 점수는 사이트를 사용자 전반에 맞게 개선하도록 돕기 위한 것이며, SEO 때문에만 만점을 노리는 것은 시간을 가장 잘 쓰는 방법이 아닐 수 있다.

Core Web Vitals 합격 판정은 지난 28일 실제 사용자 데이터의 75번째 백분위수로 합니다. 판정 규칙은 「페이지 속도 측정」 편에 자세히 적었습니다.

확인한 구글 검색 센터 문서에서 라이트하우스 점수를 순위 신호로 적은 문장은 찾지 못했습니다. 라이트하우스 점수는 무엇을 고칠지 찾는 진단표로 쓰는 것이 문서의 뜻에 맞습니다.

같은 도구의 SEO 점수가 무엇을 검사하는지는 「구글 SEO 점수」 편에 정리했습니다.

Furthermore, even though Lighthouse can provide you a single overall Performance score, it might be more useful to think of your site performance as a distribution of scores, rather than a single number.

Lighthouse 는 성능 점수를 하나로 보여 주지만, 사이트 성능은 숫자 하나보다 점수의 분포로 보는 편이 더 쓸모 있다.

Chrome for Developers 「Lighthouse performance scoring」 (문서 수정일 2019-09-19) · 최종 확인일 2026-10-25 · https://developer.chrome.com/docs/lighthouse/performance/performance-scoring

발견 04

같은 점수표라도 B2B·B2C·B2G 는 점수를 읽는 자리가 다릅니다

예시 ① 홈페이지 리뉴얼 납품을 검수하는 기업(B2B)

수행사가 「라이트하우스 95점」을 성과로 내밀 때가 있습니다. 검수 기준은 점수 하나가 아니라 대표 페이지 몇 개의 LCP·CLS 값과 측정 조건으로 적습니다.

같은 페이지도 측정할 때마다 점수가 달라집니다. 원문도 점수를 숫자 하나가 아니라 분포로 보라고 적었습니다.

예시 ② 광고 태그가 많은 쇼핑몰(B2C)

점수가 낮은 원인이 TBT 라면 광고·분석 스크립트가 기본 스레드를 붙잡고 있을 가능성이 큽니다. 가중치가 가장 큰 지표라 스크립트 정리만으로 점수가 크게 움직입니다.

점수와 함께 실제 사용자 데이터의 INP 도 봐야 장바구니 버튼 반응이 실제로 좋아졌는지 알 수 있습니다.

예시 ③ 웹 접근성 점검을 받는 공공기관 누리집(B2G)

라이트하우스 보고서에는 성능과 접근성 점수가 나란히 나옵니다. 두 점수는 따로 계산되므로 성능 점수로 접근성을 판단할 수 없습니다.

방문자가 적은 페이지는 실제 사용자 데이터가 모자랄 수 있습니다. 이때는 라이트하우스 지표 값을 개선 단서로 쓰고, 출처 전체 데이터를 함께 봅니다.

그럼 라이트하우스 성능 점수는 어떤 순서로 읽나요?

pagespeed.web.dev 에서 URL 을 분석하고, 아래쪽 「성능」 점수 밑의 지표 5개 값을 적습니다.
가중치가 큰 순서(TBT·LCP·CLS·FCP·SI)로 「좋음」 기준에서 먼 지표를 고릅니다.
「추천」과 「진단」에서 그 지표에 걸린 항목을 찾습니다. 진단 숫자는 점수에 직접 들어가지 않으니 지표 값으로 효과를 확인합니다.
같은 조건으로 세 번 이상 측정해 점수 범위를 적습니다. 한 번 잰 점수로 판단하지 않습니다.
위쪽 실제 사용자 데이터의 LCP·INP·CLS 가 「좋음」인지 확인합니다. 검색과 관련된 판정은 이 값입니다.

조사 방법

Chrome for Developers 「Lighthouse performance scoring」 (문서 수정일 2019-09-19) · 최종 확인일 2026-10-25 · https://developer.chrome.com/docs/lighthouse/performance/performance-scoring
GoogleChrome/lighthouse (GitHub) 「default-config.js (Lighthouse 13.5.0)」 · 최종 확인일 2026-10-25 · https://github.com/GoogleChrome/lighthouse/blob/main/core/config/default-config.js
GoogleChrome/lighthouse (GitHub) 「ko.json (Lighthouse 13.5.0 한국어 화면 문구)」 · 최종 확인일 2026-10-25 · https://github.com/GoogleChrome/lighthouse/blob/main/shared/localization/locales/ko.json
web.dev (Google Chrome) 「Total Blocking Time (TBT)」 (문서 수정일 2025-10-15) · 최종 확인일 2026-10-25 · https://web.dev/articles/tbt
Chrome for Developers 「Introduction to Lighthouse」 (문서 수정일 2025-06-02) · 최종 확인일 2026-10-18 · https://developer.chrome.com/docs/lighthouse/overview
Google for Developers 「About PageSpeed Insights」 (문서 수정일 2024-10-21) · 최종 확인일 2026-10-18 · https://developers.google.com/speed/docs/insights/v5/about
web.dev (Google Chrome) 「Web Vitals」 (문서 수정일 2024-10-31) · 최종 확인일 2026-10-18 · https://web.dev/articles/vitals
Google Search Central 「Understanding page experience in Google Search results」 (문서 수정일 2026-09-22) · 최종 확인일 2026-10-18 · https://developers.google.com/search/docs/appearance/page-experience
지표 5개와 가중치는 Lighthouse 13.5.0 설정 파일에서 직접 읽었고, 공식 문서 「Lighthouse performance scoring」의 「Lighthouse 10」 표와 대조했습니다. 공식 문서의 수정일(2019-09-19)은 오래되었지만 표 값은 지금 설정 파일과 같습니다.
점수와 순위의 관계는 위 문서들이 적은 문장을 짝지어 옮긴 것입니다. 짝짓는 방식은 편집 판단입니다.
예시 ①②③은 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다.
원문은 영어판(hl=en)이고, 화면 이름(성능·진단·추천)은 Lighthouse 한국어 화면 문구(ko.json)를 따랐습니다.