내 웹사이트 LCP 점수 떡상 비법? 브라우저 렌더링 파고든 비개발자의 탐구 일지

안녕하세요, 코딩은 못 하지만 IT가 너무 궁금한 비개발자 루카(Luka)입니다.

thumbnail

혹시 웹사이트를 이용하다가 답답함을 느낀 적 없으신가요? 저는 블로그를 운영하다 보니 방문자분들이 페이지 로딩이 느리다고 느낄까 봐 늘 신경 쓰이더라고요. 그러다 우연히 'LCP 점수'라는 걸 알게 됐는데, 이 점수가 웹사이트의 첫인상과 직결된다고 해서 너무 궁금해졌어요. "이게 뭔데 내 블로그의 운명을 좌우한다는 거야?" 싶은 마음에 직접 파보고 기록해봤습니다. 저처럼 코딩은 몰라도 웹사이트 성능에 관심 있는 분들께 작은 도움이 되기를 바라요!

LCP 점수, 대체 이게 뭔데 이렇게 중요할까?

먼저, LCP가 뭔지부터 알아봤습니다. LCP는 'Largest Contentful Paint'의 약자예요. 직역하면 '가장 큰 콘텐츠가 그려지는 시간' 정도? 쉽게 말해, 사용자가 웹페이지에 접속했을 때 화면에 보이는 가장 큰 이미지나 텍스트 블록 같은 핵심 콘텐츠가 완전히 로딩되는 데 걸리는 시간을 측정하는 지표입니다.

이게 왜 중요하냐면, 사용자는 페이지에 접속했을 때 "어떤 내용이 보이는구나!"라고 인지하는 순간부터 웹사이트가 로딩되었다고 생각하거든요. 아무리 다른 자잘한 요소들이 먼저 로딩되어도, 정작 중요한 메인 이미지가 안 보이면 답답하게 느끼는 거죠.

구글은 이 LCP 점수를 매우 중요하게 생각해서, 검색 엔진 순위에도 영향을 미친다고 합니다. 공식 문서에서는 LCP 점수가 2.5초 이내여야 '좋음(Good)'으로 분류하고, 4초가 넘어가면 '나쁨(Poor)'으로 판단해요. 제가 개발자 도구의 'Lighthouse'로 제 블로그를 돌려봤을 때 처음에는 3.8초가 나왔는데, 이 글을 쓰면서 배운 것들을 적용해보니 2.1초까지 줄어들었어요! (아직 완벽하진 않지만 만족!)

브라우저는 어떻게 웹 페이지를 그릴까? (비개발자의 눈높이 설명)

LCP를 개선하려면 브라우저가 웹 페이지를 어떻게 화면에 보여주는지 그 과정을 살짝 이해해야 하더라고요. 개발자는 아니지만, "이게 뭔데" 싶어서 찾아보니 대략 이런 과정을 거친다고 합니다.

HTML 파싱 (Parsing): 브라우저가 웹 서버에서 받은 HTML 파일을 한 줄 한 줄 읽어서 'DOM 트리'라는 걸 만들어요. 우리가 아는 웹페이지의 뼈대 같은 거죠.
CSS 파싱: HTML에 연결된 CSS 파일들을 읽어서 'CSSOM 트리'를 만들어요. 이건 웹페이지의 스타일(색깔, 크기, 배치 등) 정보를 담고 있습니다.
렌더 트리 (Render Tree) 생성: DOM 트리와 CSSOM 트리를 합쳐서 '렌더 트리'를 만들어요. "어떤 요소가 어떤 스타일로 그려질지"가 결정되는 거죠.
레이아웃 (Layout/Reflow): 이제 렌더 트리를 기반으로 각 요소가 화면의 어느 위치에, 어떤 크기로 자리 잡을지 계산합니다.
페인트 (Paint): 레이아웃 계산이 끝나면, 실제로 픽셀을 채워서 화면에 요소를 그려 넣는 단계예요.
컴포지팅 (Compositing): 그려진 여러 레이어를 합쳐서 최종적인 이미지를 만들고, 이걸 화면에 보여줍니다.

이 과정에서 CSS나 JavaScript 파일 같은 일부 리소스들은 브라우저가 페이지를 그리는 걸 잠시 멈추게 할 수 있는데, 이걸 '렌더링 블로킹(Render-blocking)'이라고 부릅니다. LCP 점수를 좋게 만들려면 이 렌더링 블로킹 요소를 최대한 줄이는 게 핵심이더라고요!

LCP 점수 수직 상승시키는 실전 팁 (루카의 탐구 결과!)

제가 직접 찾아보고 시도해본 LCP 개선 팁들을 공유합니다. 코딩을 못 해도 원리를 이해하면 "아, 그래서 이렇게 하는 거구나!" 하고 고개를 끄덕이게 될 거예요.

1. 이미지 최적화: 시각적 LCP의 핵심!

웹페이지에서 가장 큰 콘텐츠(Largest Contentful Content)는 보통 이미지인 경우가 많습니다. 그래서 이미지 최적화는 LCP 개선의 가장 중요한 부분 중 하나입니다.

크기 조절 및 압축: 저는 제 블로그에 올릴 이미지를 항상 포토샵 같은 프로그램으로 미리 가로 사이즈 1000px 이하로 줄이고 압축해서 올립니다. 찾아보니, 최적화된 이미지는 원본 대비 평균 50% 이상 파일 크기가 줄어든다고 해요. (실제로 저는 1MB짜리 이미지를 150KB 정도로 줄여서 사용하고 있어요!)
차세대 이미지 포맷 사용: 요즘은 JPEG나 PNG 대신 WebP나 AVIF 같은 포맷을 많이 쓴다고 해요. 이 포맷들은 화질 손상 없이 파일 크기를 훨씬 더 줄여줍니다.
- WebP: JPEG보다 평균 25-34% 더 작은 파일 크기를 제공한다고 합니다.
- AVIF: WebP보다도 10-20% 더 작은 파일 크기를 자랑하지만, 아직 모든 브라우저에서 완벽하게 지원되지는 않는다고 하네요. 저는 현재 WebP를 주로 사용하고 있습니다.
지연 로딩 (Lazy Loading): 당장 화면에 보이지 않는(스크롤 해야 보이는) 이미지는 나중에 로딩되도록 설정할 수 있습니다. HTML <img /> 태그에 loading="lazy" 속성만 추가하면 끝! html <img src="my-image.jpg" alt="예쁜 풍경 사진" loading="lazy"> 이걸 적용하니 초기 로딩 시 불필요한 이미지 요청이 줄어들어 LCP 점수가 눈에 띄게 개선됐습니다. 제 블로그의 경우, 첫 화면에 보이는 이미지를 제외한 나머지 이미지 로딩 시간이 평균 0.5초 이상 단축되었습니다.

2. 렌더링 블로킹 리소스 줄이기: CSS와 JavaScript

브라우저가 페이지를 그리는 걸 방해하는 CSS나 JavaScript 파일들을 적절히 처리하는 것이 중요합니다.

CSS:
- 핵심 CSS 인라인화 (Critical CSS Inlining): 페이지를 처음 로딩할 때 당장 필요한 CSS만 <style> 태그 안에 직접 넣는 방법입니다. 이렇게 하면 브라우저가 외부 CSS 파일을 기다릴 필요 없이 바로 렌더링을 시작할 수 있죠. (이건 개발자분들의 도움이 필요하더라고요.)
- 미니파이 (Minify) & 압축: CSS 파일의 불필요한 공백, 주석 등을 제거해서 파일 크기를 줄입니다. 빌드 도구를 사용하면 자동으로 해준다고 합니다.
JavaScript:
- async와 defer 속성 사용: script 태그에 이 속성들을 추가하면 JavaScript가 페이지 렌더링을 방해하지 않고 비동기적으로 로딩됩니다. 이 두 가지는 작동 방식이 달라서 비교표로 정리해봤습니다. html <script src="my-script.js" async></script> <script src="another-script.js" defer></script> 이 속성들을 사용하면, 브라우저가 HTML을 파싱하다가 JavaScript 파일을 만나도 파싱을 멈추지 않고 계속 진행할 수 있게 됩니다. async를 사용한 스크립트는 로딩이 끝나는 대로 바로 실행되고, defer를 사용한 스크립트는 HTML 파싱이 완료된 후에 실행됩니다.

3. 웹폰트 최적화: 글자도 빠르게!

웹폰트도 LCP에 큰 영향을 줄 수 있습니다. 외부에서 폰트를 불러오는 동안 텍스트가 안 보이거나 기본 폰트로 보이다가 바뀌는 현상(FOIT/FOUT)이 발생할 수 있기 때문입니다.

font-display 속성 사용: CSS의 @font-face 규칙에 font-display: swap;을 추가하면, 웹폰트가 로딩되기 전까지는 시스템 기본 폰트를 먼저 보여주고, 웹폰트 로딩이 완료되면 웹폰트로 바꿔줍니다. 사용자 입장에서는 글자가 아예 안 보이는 것보다 훨씬 덜 답답하죠. css @font-face { font-family: 'MyCustomFont'; src: url('mycustomfont.woff2') format('woff2'); font-display: swap; /* 이걸 추가하면 돼요! */ } 이 설정 하나로 폰트 로딩으로 인한 시각적 지연이 평균 0.2초 이상 줄어드는 효과를 봤습니다.

4. 캐싱 전략 활용: 두 번째 방문부터는 더 빠르게!

브라우저 캐싱은 한 번 방문했던 웹사이트의 리소스(이미지, CSS, JS 등)를 사용자의 컴퓨터에 임시로 저장해두는 것을 말합니다. 다음에 다시 방문했을 때는 서버에서 다시 받아올 필요 없이 캐시된 파일을 사용하기 때문에 훨씬 빠르게 페이지를 로딩할 수 있습니다.

CDN (콘텐츠 전송 네트워크) 사용: CDN은 전 세계 여러 곳에 분산된 서버에 콘텐츠를 저장해두고, 사용자와 가장 가까운 서버에서 콘텐츠를 전송해주는 서비스입니다. 이를 통해 콘텐츠 전송 속도를 크게 높일 수 있습니다. 제 블로그도 CDN을 사용 중인데, 해외 접속자의 로딩 시간이 평균 1초 이상 단축되는 효과를 봤어요.
HTTP 캐시 헤더 설정: 웹 서버에서 파일에 캐시 만료 기간을 설정해두면, 브라우저는 그 기간 동안 파일을 다시 요청하지 않고 로컬 캐시를 사용합니다.

5. 측정 도구 활용: 어디가 문제인지 알아야 고치죠!

어떤 부분이 문제인지 정확히 알아야 개선할 수 있습니다. 저는 주로 Google Lighthouse를 사용합니다. 개발자 도구(F12)에 내장되어 있어서 쉽게 실행할 수 있고, LCP 점수를 포함한 다양한 성능 지표와 함께 개선 방안까지 알려줘서 비개발자도 참고하기 좋습니다.

터미널을 사용할 수 있다면, 아래 명령어로 Lighthouse를 설치하고 특정 URL의 성능을 측정할 수도 있습니다. (저는 개발자 지인분께 부탁해서 해봤어요!)

# Lighthouse CLI 설치 (Node.js 필요)
npm install -g lighthouse

# 특정 URL의 성능 측정 및 결과 보기
lighthouse https://www.your-blog-url.com --view

이 명령어를 실행하면 브라우저가 자동으로 열리면서 자세한 리포트를 보여줍니다. 제 블로그의 초기 LCP 점수인 3.8초를 Lighthouse를 통해 확인하고 어떤 부분에서 시간이 오래 걸리는지 시각적으로 확인할 수 있었어요.

비개발자가 헷갈리기 쉬운 부분 (루카도 처음엔 헤맸어요!)

저처럼 비개발자 입장에서는 처음 접하면 "이게 무슨 말이야?" 싶은 것들이 꽤 있었습니다. 제가 헤맸던 몇 가지 부분을 정리해봤습니다.

1. "LCP 점수는 낮을수록 좋은 건가요, 높을수록 좋은 건가요?"

저도 처음엔 점수라고 하니 높을수록 좋은 줄 알았어요! 하지만 LCP는 시간을 측정하는 지표이기 때문에 낮을수록 좋습니다. 2.5초 이하면 '좋음', 4초 이상이면 '나쁨'으로 평가됩니다. 마치 100미터 달리기 기록처럼 숫자가 낮을수록 빠른 거니까 좋은 거죠!

2. "CSS 파일은 왜 꼭 안에 있어야 하고, JS 파일은 왜 끝에 두라는 걸까요?"

이건 위에서 설명한 브라우저 렌더링 과정과 관련이 깊어요.

CSS 파일은 <head> 안에: CSS는 웹페이지의 '스타일'을 정의하잖아요? 브라우저가 HTML을 읽다가 스타일 정보를 나중에 알게 되면, 이미 그려진 화면을 다시 그려야 하는 번거로움이 생깁니다. 이걸 'FOUC(Flash Of Unstyled Content)'라고 하는데, 스타일 없는 페이지가 잠깐 보이다가 스타일이 적용되는 현상이죠. 사용자 경험에 안 좋기 때문에, 브라우저가 처음부터 스타일을 알고 페이지를 올바르게 그리도록 <head> 안에 두는 게 일반적입니다. (단, 렌더링 블로킹 요소가 되니 꼭 필요한 CSS만 넣는 게 좋다고 합니다!)
JS 파일은 <body> 끝에: JavaScript는 주로 페이지의 '동작'을 담당합니다. 만약 JS 파일이 페이지 중간이나 <head> 안에 있으면, 브라우저가 JS를 로딩하고 실행하는 동안 HTML 파싱을 멈춰야 할 수 있습니다. 그렇게 되면 사용자는 빈 화면만 보거나 페이지 로딩이 지연되는 걸 경험하게 되죠. 그래서 페이지의 핵심 콘텐츠(HTML)가 먼저 로딩되어 보인 후에 JavaScript가 실행되도록 <body> 태그 닫히기 직전에 배치하는 것이 일반적입니다. 다만, 위에서 설명한 async나 defer 속성을 사용하면 <head> 안에서도 렌더링 블로킹을 최소화하며 JS를 로딩할 수 있습니다.

3. "번들러(Webpack, Rollup)가 뭔가요? 개발자 도구의 '네트워크' 탭에서 뭐가 다른 건가요?"

번들러는 쉽게 말해, 개발자들이 여러 개의 작은 JavaScript나 CSS 파일을 만들어서 작업한 다음, 이걸 웹사이트에 배포할 때는 하나 또는 몇 개의 큰 파일로 합쳐주고, 필요 없는 부분을 제거하고 압축까지 해주는 도구입니다.

번들러의 역할:
- 합치기 (Bundling): 수십 개의 JS/CSS 파일을 하나로 합쳐서 브라우저가 서버에 요청해야 하는 횟수를 줄여줍니다. (네트워크 요청 수가 줄어들면 로딩 속도가 빨라져요!)
- 압축/최적화 (Minification/Optimization): 파일 크기를 줄여서 전송 속도를 높입니다.
- 코드 분할 (Code Splitting): 모든 코드를 한 번에 로딩하지 않고, 당장 필요한 코드만 먼저 로딩하고 나머지는 나중에 로딩되도록 분할합니다. (이건 LCP에 정말 중요하다고 합니다!)

'네트워크' 탭에서 다른 점: 번들러를 사용하지 않으면 네트워크 탭에서 자잘한 JS/CSS 파일이 수십 개씩 로딩되는 걸 볼 수 있습니다. 하지만 번들러를 사용하면 이런 파일들이 하나의 bundle.js나 app.css 같은 파일로 합쳐져서 요청 횟수가 확 줄어든 것을 확인할 수 있죠. 제 블로그도 번들러를 통해 초기 JS 파일 요청 수가 12개에서 3개로, 총 파일 크기는 300KB에서 110KB로 줄어들었습니다. 이로 인해 LCP 점수 개선에 상당한 기여를 했습니다.

`async` vs `defer` 비교표 (언제 뭘 써야 할까?)

특징	`async` 속성	`defer` 속성
HTML 파싱	중단하지 않고 동시에 JS 파일 다운로드	중단하지 않고 동시에 JS 파일 다운로드
JS 실행 시점	다운로드 완료 즉시 (HTML 파싱 중에도)	HTML 파싱이 모두 완료된 후 (DOM이 준비된 후)
실행 순서	다운로드 완료되는 대로 실행되므로 순서 보장 안 됨	스크립트가 선언된 순서대로 실행이 보장됨
주로 사용될 때	페이지 렌더링에 영향을 주지 않는 독립적인 스크립트 (예: 구글 애널리틱스)	HTML 구조를 조작하거나 다른 스크립트에 의존하는 스크립트

저는 제 블로그에 외부 광고 스크립트나 통계 스크립트에는 async를 사용하고, 페이지 내 상호작용 관련 스크립트에는 defer를 사용하고 있습니다.

마무리하며: 비개발자도 웹 성능 최적화, 충분히 할 수 있어요!

처음에는 '브라우저 렌더링', 'LCP 점수' 같은 단어들이 너무 어렵게 느껴졌습니다. 하지만 제가 직접 파고들면서 "이게 뭔데?"라는 질문을 던져보니, 개발 지식이 없어도 충분히 원리를 이해하고 실제 웹사이트에 적용해볼 수 있는 부분이 많다는 걸 알게 됐습니다.

결국 웹 성능 최적화는 사용자들이 더 빠르고 쾌적하게 웹사이트를 이용할 수 있도록 돕는 과정이라는 걸 깨달았어요. 저처럼 코딩은 못 하지만 IT가 궁금한 비개발자분들도, 이 글을 통해 웹사이트 성능에 대한 막연한 두려움을 떨쳐내고 '내 웹사이트 LCP 점수 떡상!'을 경험해보시길 바랍니다. 궁금한 건 직접 파보면 답이 보입니다!

핵심 요약

LCP(Largest Contentful Paint)는 웹페이지 핵심 콘텐츠 로딩 시간 지표로, 낮을수록 좋으며 2.5초 이내가 목표입니다.
이미지 최적화(WebP/AVIF, 지연 로딩)와 렌더링 블로킹 CSS/JS 처리(async/defer, critical CSS)가 LCP 개선에 가장 중요합니다.
Google Lighthouse 같은 도구로 현재 LCP 점수를 측정하고, 어떤 부분이 문제인지 파악하는 것이 개선의 시작입니다.

질문 형식 FAQ

Q1: LCP 점수 개선을 위해 제가 직접 코드를 수정해야 하나요?

A1: 모든 부분을 직접 수정할 필요는 없습니다. loading="lazy"나 async/defer 같은 간단한 HTML 속성은 직접 추가해볼 수 있습니다. 하지만 CSS 최적화나 번들러 설정 같은 부분은 개발자나 웹 개발 도구의 도움을 받는 것이 효과적입니다. 원리를 이해하면 개발자에게 어떤 개선을 요청해야 할지 명확해집니다.

Q2: 모바일 LCP 점수가 더 나쁜데, 어떻게 해야 할까요?

A2: 모바일 환경은 네트워크 속도가 불안정하고 기기 성능이 데스크톱보다 낮은 경우가 많아 LCP 점수가 나쁘게 나올 수 있습니다. 모바일 환경에 최적화된 반응형 이미지 사용, 모바일에서 불필요한 스크립트/CSS 로딩 최소화, AMP(Accelerated Mobile Pages) 같은 기술 도입을 고려해볼 수 있습니다. 무엇보다 모바일에서 LCP를 측정하고 분석하는 것이 중요합니다.

Q3: LCP 점수만 좋으면 웹사이트 성능이 좋은 건가요?

A3: LCP는 중요한 지표지만, 웹사이트 성능의 모든 것을 대변하지는 않습니다. 웹사이트가 로딩된 후 얼마나 빠르게 상호작용 가능한지(FID: First Input Delay), 레이아웃이 얼마나 안정적인지(CLS: Cumulative Layout Shift) 등 다른 Core Web Vitals 지표들도 함께 고려해야 합니다. 완벽한 사용자 경험을 위해서는 이 모든 지표를 종합적으로 관리하는 것이 좋습니다.