First Contentful Paint (FCP): 개념, 측정 방법 및 해결 방법

First Contentful Paint 해결하기

First Contentful Paint (FCP)는 브라우저가 방문자가 볼 수 있도록 페이지에 의미 있는 첫 번째 요소를 그리는 순간입니다. 즉, 브라우저가 화면에 무언가를 처음 렌더링하는 순간입니다. 따라서 FCP는 체감되는 페이지 로드 속도를 측정하는 좋은 방법입니다.

브라우저가 지연 없이 렌더링을 시작할 수 있도록 하면 FCP를 개선할 수 있습니다. 아래에서 FCP가 무엇인지, 어떻게 측정하는지, 그리고 이를 단축하기 위해 입증된 15가지 기술에 대해 배울 수 있습니다.

First Contentful Paint (FCP)란 무엇인가요?

First Contentful Paint (FCP)는 페이지 로딩 속도를 측정하는 방법입니다. 페이지 속도를 하나의 시점으로 요약할 수는 없습니다. 로딩 프로세스 동안 방문자가 사이트 로딩 속도가 빠르거나 느리다고 느낄 수 있는 순간은 여러 번 존재합니다. FCP는 페이지를 요청한 시점과 첫 번째 의미 있는 콘텐츠가 화면에 처음 렌더링되는 시점 사이의 시간 차이를 측정합니다.

그렇다면 이것이 정확히 무엇을 의미할까요? 이는 FCP가 방문자가 경험하는 로딩 속도에 대해 말해주기 때문에 주로 "사용자 중심 메트릭"임을 의미합니다. 즉, UX에 대한 지표입니다. FCP 순간에 방문자는 확실히 화면에서 "무언가"를 보게 됩니다.

단어들을 분석해 보겠습니다: 'First', 'Contentful' 그리고 'Paint'.

1. First: First는 물론 브라우저에 의미 있는 무언가가 나타나는 바로 그 첫 번째 순간을 의미합니다.
2. Contentful: Contentful은 콘텐츠가 있는 HTML 요소를 의미합니다. 따라서 빈 요소나 배경색과 같은 레이아웃 요소가 아니라 약간의 텍스트, 이미지(배경 이미지 포함), SVG 또는 캔버스를 의미합니다.
3. Paint: Paint는 (대략적으로) 브라우저가 화면에 무언가를 표시할 준비가 되었음을 의미합니다. 간단해 보이지만 실제로는 브라우저의 가장 복잡한 작업입니다. 화면에 무언가를 표시하기 위해 브라우저는 요소의 모든 특성을 계산할 준비가 되어 있어야 합니다. 아래는 화면에 무언가를 추가하기 전에 필요한 렌더링 프로세스의 예입니다.

FCP vs LCP: 차이점은 무엇인가요?

FCP와 LCP (Largest Contentful Paint)는 모두 로딩 성능을 측정하지만 페이지 로드 타임라인에서 서로 다른 순간을 포착합니다. 차이점을 이해하면 최적화 작업의 우선순위를 올바르게 지정하는 데 도움이 됩니다.

실제로는 FCP가 LCP보다 훨씬 먼저 실행되는 경우가 많습니다. 예를 들어, 페이지가 400ms 이내에 제목(FCP)을 렌더링하지만 히어로 이미지가 로드(LCP)될 때까지 추가로 2초를 기다릴 수 있습니다. FCP는 렌더링 파이프라인의 가장 첫 번째 병목 현상을 포착하기 때문에 FCP가 느리면 LCP도 거의 확실히 느려집니다. 자세한 내용은 당사의 완벽 LCP 가이드에서 읽어보세요.

좋은 First Contentful Paint 점수란 무엇인가요?

좋은 FCP 점수는 1.8초 미만입니다. FCP 점수가 1.8초에서 3초 사이라면 개선이 필요합니다. 3초를 초과하는 FCP 점수는 나쁨으로 간주됩니다. First Contentful Paint에 대한 권장 기준을 충족하려면 방문자의 최소 75%가 "좋은" FCP 점수를 받아야 합니다.

성능 메트릭과 항상 그렇듯이 더 빠른 First Contentful Paint 점수가 느린 점수보다 좋습니다.

First Contentful Paint (FCP)는 어떻게 측정하나요?

FCP는 Google이 실제 사용자로부터 데이터를 수집하여 측정합니다. 해당 데이터는 CrUX 데이터세트에 저장됩니다. 해당 데이터는 CrUX API 또는 Google BigQuery를 통해 공개적으로 사용할 수 있습니다. FCP는 소위 랩 테스트를 통해서도 측정할 수 있습니다. 가장 일반적인 랩 테스트는 Lighthouse입니다.

CrUX 데이터세트에서 First Contentful Paint 가져오기

First Contentful Paint는 pagespeed.web.dev, CrUX API 또는 Google BigQuery를 통해 CrUX 데이터세트에서 읽을 수 있습니다.

Real User Monitoring (RUM)을 통한 First Contentful Paint 측정

RUM Tracking은 Real User Monitoring의 약자입니다. Real User Monitoring을 사용하면 실제 사용자 상호 작용을 통해 First Contentful Paint를 추적할 수 있습니다. RUM Tracking의 장점은 최신 데이터를 위해 28일을 기다릴 필요가 없으며 훨씬 더 자세하게 데이터를 쿼리하고 분석할 수 있다는 것입니다.

Lighthouse에서 FCP 측정하기

1. FCP를 측정하려는 페이지를 Chrome에서 엽니다. 플러그인이 간섭하여 페이지의 FCP를 늦출 가능성을 방지하기 위해 시크릿 모드에서 이 작업을 수행해야 합니다.
2. 페이지를 마우스 오른쪽 버튼으로 클릭하고 요소 검사를 선택합니다. 이렇게 하면 Chrome 개발자 콘솔이 열립니다.
3. 콘솔 상단에 Lighthouse 탭이 표시됩니다. 클릭하세요. 그런 다음 카테고리(Categories)에서 성능(Performance)을 선택하고(다른 항목은 비워 둠) 기기(Device)에서 모바일(Mobile)을 선택합니다.
4. 이제 보고서 생성(Generate Report)을 클릭합니다. Lighthouse가 페이지의 속도 보고서를 생성합니다. 보고서의 왼쪽 상단 모서리에 페이지의 FCP가 표시됩니다.

이것은 이 페이지에 대한 Lighthouse 보고서의 스크린샷입니다. 모바일 기기에서 이 페이지의 FCP는 0.8초입니다! 나쁘지 않죠?

온라인 도구로 FCP 측정하기

수많은 온라인 도구를 사용하여 FCP를 측정할 수도 있습니다. 가장 잘 알려진 것은 GTMetrix, pingdom 및 pagespeed.web.dev입니다. 이러한 도구는 다루기 쉽고 특정 랩 환경 하에서의 FCP에 대한 몇 가지 데이터를 제공합니다.

실제 FCP 데이터가 보여주는 것

CoreDash 데이터에 따르면 FCP는 TTFB를 밀접하게 추적합니다. 전체적으로 p75 FCP는 392ms이며, 데스크톱은 372ms, 모바일은 692ms(1.9배 더 느림)입니다. 데스크톱에서 FCP와 TTFB의 차이는 248ms이고 모바일에서는 376ms에 불과하며, 이는 잘 최적화된 사이트에서 렌더링 차단 시간이 FCP에서 차지하는 비중이 비교적 작다는 것을 나타냅니다.

전 세계적으로, 2025 Web Almanac에 따르면 데스크톱 페이지의 70%가 좋은 FCP를 달성하는 반면 모바일 페이지의 55%만이 이를 달성합니다. 모바일이 4%포인트 상승하는 등 2024년보다 둘 다 개선되었으며, 이는 웹 개발자들이 점점 더 렌더링 차단 리소스를 해결하고 있음을 시사합니다.

FCP와 TTFB 간의 긴밀한 상관관계는 Time to First Byte를 개선하는 것이 First Contentful Paint를 향상시키는 데 가장 효과적인 단일 방법인 경우가 많음을 의미합니다. 이 사이트에서 FCP는 TTFB보다 약 250ms만 더 높으며, 이는 FCP 시간의 대부분이 렌더링 차단 작업에 소요되는 대신 서버 응답을 기다리는 데 소비됨을 의미합니다.

First Contentful Paint 개선하기

FCP를 더 빠르게 만들 시간입니다. 빠른 FCP 이면의 아이디어는 사실 아주 간단합니다. 브라우저가 즉시 렌더링을 시작할 수 있도록 하는 것입니다. 렌더링이 지연될 수 있는 모든 요인은 좋지 않은 FCP 점수로 이어집니다.

Largest Contentful Paint와 마찬가지로 First Contentful Paint는 2가지 또는 4가지 범주로 나눌 수 있습니다.

1. Time to First Byte (TTFB): 브라우저가 페이지 로드를 시작한 시점부터 HTML의 첫 번째 바이트를 받을 때까지의 시간입니다.
2. Resource load delay: TTFB와 브라우저가 FCP 리소스를 로드하기 시작할 때 사이의 시간입니다.
3. Resource load time: FCP 리소스 자체를 로드하는 데 걸리는 시간입니다.
4. Element render delay: FCP 리소스 로드가 완료된 시점부터 FCP 요소가 완전히 렌더링될 때까지의 시간입니다.

Speed tip: FCP 요소에 네트워크 리소스가 필요하지 않도록 확인하여 2단계와 3단계를 쉽게 제거할 수 있습니다. 텍스트 요소의 경우 font-display:swap을 사용하는 것을 고려하세요. 작은 이미지 요소의 경우 이미지를 인라인으로 배치하는 것을 고려하세요.

이렇게 하면 최적화할 부분으로 Time to First Byte와 Element Render delay만 남게 됩니다.

아래는 FCP를 개선하기 위해 제가 자주 사용하는 14가지 솔루션입니다. 하지만 조심하세요. 솔루션을 잘못된 곳에 사용하면 오히려 지연이 발생할 수 있습니다. 그렇기 때문에 스스로 시작하기 전에 페이지 속도 전문가와 상의하는 것이 가장 좋습니다.

1. 빠른 서버 응답 (TTFB)

TTFB (요청과 서버가 보내는 첫 번째 바이트 사이의 시간)는 항상 렌더링 프로세스의 첫 번째 단계입니다. 그 시점부터 브라우저는 멀티태스킹을 시작하고 추가 최적화의 영향이 줄어들기 시작합니다. HTML 코드는 모든 속도 메트릭에 직접적인 영향을 미치는 유일한 요청입니다.

서버에서 HTML 코드를 보내는 속도는 종종 Time to First Byte (TTFB)로 측정됩니다. 이를 최대한 빠르게 만드는 것이 중요합니다. 주로 서버 사이드 캐싱을 활성화하여 이를 수행합니다.

Time to First Byte에 관해서는 항상 낮을수록 좋습니다.

Time to First Byte를 직접 쉽게 측정할 수 있습니다. 방법은 다음과 같습니다.

1. 단축키 Ctrl-Shift-I를 사용하여 Google Chrome의 개발자 콘솔을 엽니다.
2. 콘솔 상단에 네트워크(Network) 탭이 표시됩니다. 클릭하세요.
3. Ctrl-R을 통해 페이지를 다시 로드합니다.
4. 이제 Chrome이 서버로 보낸 모든 네트워크 요청이 표시됩니다.
5. 가장 위에 있는 네트워크 요청(페이지 자체에 대한 요청)을 클릭합니다.
6. 이제 이 네트워크 요청에 대한 더 많은 정보를 얻게 됩니다. 이 정보의 상단에 있는 타이밍(timing) 탭을 클릭하여 페이지의 TTFB가 무엇인지 확인하세요.

2. HTTP/3

HTTP/3은 HTTP 프로토콜의 세 번째 버전입니다. HTTP/3은 구형인 HTTP/1.1 및 HTTP/2 프로토콜에서 발견되는 많은 문제를 해결합니다. 예를 들어, HTTP/2부터는 동일한 연결을 통해 동시에 여러 파일을 보낼 수 있습니다. HTTP/3은 더 빠른 초기 연결을 제공하며 사소한 네트워크 중단으로부터의 문제가 적습니다.

너무 자세히 들어가지 않더라도 HTTP/3을 사용하면 특히 모바일 네트워크와 같은 느린 네트워크에서 속도를 크게 향상시킬 수 있습니다. 네트워크 관리자는 귀하의 웹 서버가 더 빠른 HTTP/3 프로토콜에 이미 적합한지 알려줄 수 있습니다.

귀하의 웹사이트가 이미 더 빠른 HTTP/3 프로토콜을 사용하고 있는지 직접 확인할 수 있습니다. 단축키 Ctrl-Shift-I를 사용하여 Google Chrome의 네트워크 검사기를 엽니다. 표의 헤더를 마우스 오른쪽 버튼으로 클릭하고 프로토콜(Protocol)을 선택합니다. 이제 페이지를 다시 로드하여 사이트가 어떤 프로토콜을 사용하고 있는지 확인하세요.

3. 103 Early Hints

103 Early Hints는 최종 응답이 준비되기 전에 서버가 예비 응답 헤더를 보낼 수 있도록 하는 비교적 새로운 HTTP 상태 코드입니다. 이는 서버가 HTML을 생성하는 데 시간(예: 데이터베이스 쿼리 또는 서버 사이드 로직 실행)이 필요할 때 특히 유용합니다. 브라우저를 유휴 상태로 대기시키는 대신 서버는 브라우저가 즉시 중요한 리소스를 가져오기 시작할 수 있도록 프리로드 및 프리커넥트 힌트가 포함된 103 응답을 보냅니다.

이를 통해 브라우저가 HTML이 도착하기 전에 글꼴, 스타일시트 및 기타 렌더링에 중요한 리소스를 다운로드하기 시작할 수 있으므로 FCP가 직접적으로 향상됩니다. 이러한 영향은 TTFB가 높은 페이지에서 가장 크게 나타납니다.

HTTP/1.1 103 Early Hints
Link: </static/font/outfit.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </static/css/critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

아직 모든 호스팅 제공업체가 103 Early Hints를 지원하는 것은 아닙니다. Cloudflare에는 Early Hints에 대한 기본 제공 지원이 있으며 Apache 및 Nginx는 이를 전송하도록 구성할 수 있습니다. 자세한 내용은 당사의 완벽 103 Early Hints 가이드에서 읽어보세요.

4. 브라우저 캐싱 (Browser Caching)

네트워크 연결은 페이지 속도에 관해 종종 약한 연결고리가 됩니다. 네트워크를 완전히 건너뛰는 것이 훨씬 쉽지 않을까요?

방문자가 이전에 귀하의 사이트를 방문한 적이 있는 경우 네트워크 리소스(예: 스타일시트)가 방문자의 브라우저에 저장될 수 있는지 여부와 그 기간을 나타낼 수 있습니다. 방문자가 이러한 파일 중 하나를 다시 필요로 할 때마다 브라우저의 캐시에서 금방 튀어나옵니다. 결과적으로 브라우저는 훨씬 빠르게 렌더링을 시작하고 FCP 속도를 높일 수 있습니다.

5. 압축 (Compression)

거의 모든 경우에 네트워크 속도는 약한 고리입니다. 좋은 First Contentful Paint를 위해서는 파일을 네트워크를 통해 최대한 빨리 보내는 것이 매우 중요합니다. 압축은 서버에서 전송해야 하는 바이트 수를 줄입니다. 바이트 수가 적다는 것은 네트워크 리소스를 기다리는 시간이 줄어든다는 의미입니다. 제 생각에 압축은 마땅히 받아야 할 만큼의 주목을 받지 못하고 있는 기술입니다. 안타깝게도 너무 많은 웹마스터가 "압축을 켜고" 나서 다시는 살펴보지 않습니다. 속도를 조금 더 빠르게 만드는 쉬운 방법일 뿐이기 때문에 그것은 안타까운 일입니다.

Gzip과 Brotli라는 두 가지 인기 있는 압축 기술이 있습니다. Gzip은 가장 많이 사용되는 압축 기술이지만 Brotli가 빠르게 따라잡고 있습니다. Brotli는 Google 자체에서 제작했으며 HTML, JavaScript 또는 CSS 파일의 경우 15~20% 더 나은 결과를 보여줍니다. 따라서 Brotli는 웹에 이상적입니다.

동적 압축과 정적 압축 간에도 차이가 있습니다. 동적 압축의 경우 웹 서버를 통해 파일을 보내기 직전에 파일을 압축합니다. 정적 압축의 경우 압축된 파일이 서버에 저장됩니다. 이것이 훨씬 더 똑똑한 압축 방법인 경우가 많지만, 거의 사용되지 않습니다.

6. 리소스 힌트를 사용한 조기 웹 폰트 로드

리소스 힌트는 브라우저가 스스로 수행하기 전에 다운로드 또는 네트워크 연결을 시작합니다. 웹 폰트나 이미지와 같은 일부 네트워크 리소스는 브라우저가 이를 표시해야 한다고 확신한 후에만 다운로드됩니다.

사이트의 보이는 부분을 렌더링하기 위해 리소스가 필요하다고 확신하는 경우 "리소스 힌트"를 포함하는 것이 거의 항상 좋은 생각입니다. 이렇게 하면 브라우저가 즉시 리소스 다운로드 또는 연결을 시작합니다. 결과적으로 리소스를 더 빨리 사용할 수 있고 브라우저가 더 일찍 렌더링을 시작할 수 있습니다.

그러나 리소스 힌트를 사용할 때는 주의하세요. 잘못 사용하면 오히려 페이지 속도가 느려질 수 있습니다.

"preloading"을 사용한 조기 다운로드

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

프리로드 링크는 페이지 속도 도구에서 가장 강력한 도구 중 하나입니다. 프리로드 링크를 통해 나중에 필요할 네트워크 리소스를 다운로드합니다. 이것은 사이트의 보이는 부분에 있는 글꼴, 중요한 스크립트 및 이미지에 종종 매우 좋은 아이디어입니다.

preconnect를 사용한 사전 연결

프리커넥트 링크는 이미 서버에 연결되어 있습니다. CDN이나 Google Analytics와 같은 타사 서버에서 파일을 호스팅할 때 유용합니다.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Google Fonts에 프리커넥트하는 것보다 더 좋은 것은 Google Fonts를 셀프 호스팅하는 것입니다. 이를 통해 타사 연결이 완전히 제거되고 캐싱 및 전송에 대한 완벽한 제어가 가능해집니다.

7. prefetch를 사용하여 다음 페이지 프리페치하기

<link rel="prefetch" href="/page2.html">

prefetch를 사용하면 우선순위가 낮은 리소스를 가져올 수 있습니다. 누군가 다음 페이지 링크를 클릭할 것으로 예상될 때처럼 나중에 필요할 것이라고 생각되는 리소스를 가져오는 유용한 방법입니다.

8. 리디렉션 피하기

흔한 실수는 너무 긴 리디렉션 체인을 갖는 것입니다. 설명하자면 이렇습니다. 귀하의 사이트는 보안 연결을 통해 실행될 것입니다. 방문자가 https를 추가하지 않고 귀하의 사이트를 입력하면 방문자는 귀하의 웹사이트의 보안되지 않은 버전으로 리디렉션됩니다. 그러나 모든 것이 올바르게 설정된 경우 방문자는 보안 웹사이트로 리디렉션됩니다. 아래의 녹색 예에서 이를 확인할 수 있습니다.

하지만 때로는 빨간색 예와 같이 리디렉션이 하나 이상의 중간 단계를 거쳐 이루어지는 경우도 있습니다. 웹사이트를 느리게 실행하여 불량한 First Contentful Paint 점수를 초래하는 것은 바로 이 중간 단계입니다. 각 중간 단계는 추가 시간을 소모하며, 이는 빠르게 합산될 수 있습니다. 따라서 항상 한 번의 리디렉션 내에 올바른 페이지로 이동하는지 확인하세요.

9. CSS 최소화

외부 CSS 파일은 항상 렌더링을 차단합니다. 즉, 브라우저는 일반적으로 모든 스타일시트가 다운로드되고 분석될 때까지 콘텐츠 표시를 시작할 수 없습니다. 따라서 스타일시트를 최대한 작게 유지하는 것이 좋습니다. 이렇게 하면 스타일시트가 다운로드될 때까지 오래 기다릴 필요가 없습니다. 더 완전한 가이드를 보려면 사용하지 않는 CSS를 수정하고 제거하는 방법에 대한 기사를 읽어보세요.

단축코드로 CSS 크기 줄이기

CSS 크기를 줄이는 방법 중 하나는 단축코드를 사용하는 것입니다. 한 줄로 CSS 선택기의 가장 중요한 속성을 작성할 수 있게 해주는 한 줄짜리 코드입니다.

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

다음과 같이 쓸 수도 있습니다:

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

CSS 크기 더 줄이기

쉼표로 선택기를 병합하고, 엔터와 공백을 제거하고, 더 짧은 색상 코드를 작성하여 CSS 크기를 훨씬 더 줄일 수 있습니다.

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

다음과 같이 단축될 수 있습니다.

h1,h2,h3,h4,h5{color:#000}

10. 중요 CSS (Critical CSS)

중요 CSS(Critical CSS)를 사용하여 CSS를 한 단계 더 발전시킬 수 있습니다. 중요 CSS는 빠른 웹사이트와 빠른 First Contentful Paint를 위해 반드시 필요합니다.

중요 CSS는 페이지의 표시되는 부분을 보여주는 데 필요한 모든 선택기(body, p, h1 등)의 모음입니다. 이 중요 CSS를 별도의 스타일시트에 넣지 말고 페이지의 <head>에 직접 추가하세요. 이렇게 하면 새 파일을 다운로드할 필요가 없고 브라우저가 번개 같은 속도로 렌더링을 시작할 수 있습니다. 이는 FCP를 더 빠르게 만듭니다. 페이지의 표시되는 부분에 직접적으로 필요하지 않은 CSS는 첫 번째 렌더링 주기가 완료된 후 로드됩니다. 방문자에게 페이지는 이미 완료되었습니다. 아무도 새 스타일이 백그라운드에 여전히 추가되고 있음을 알아채지 못할 것입니다.

중요 CSS는 당사의 자체 중요 CSS 도구로 쉽게 생성할 수 있습니다. 도구에 귀하의 웹페이지 URL을 붙여넣기만 하면 나머지는 저희가 처리하겠습니다!

인라인 중요 CSS 예시

<head>
  <style>
    /* Critical CSS: only what is needed for above-the-fold content */
    body{font:400 1rem/1.6 system-ui,sans-serif;margin:0}
    h1{font-size:2rem;margin:.5em 0}
    .hero{padding:2rem;background:#f5f5f5}
  </style>
  <!-- Non-critical CSS loaded asynchronously -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/full.css"></noscript>
</head>

11. JavaScript 로드 지연

느린 First Contentful Paint의 가장 흔한 이유 중 하나는 JavaScript입니다. JavaScript를 사용하는 방식에 따라 페이지의 렌더링을 차단할 수 있습니다. 일반적으로 JavaScript는 렌더 트리가 빌드되기 전에 다운로드되고 실행됩니다. 렌더 트리가 없으면 브라우저가 화면에 아무것도 표시할 수 없으며 FCP도 여기에 포함됩니다. 지연 기술에 대한 전체 개요는 JavaScript를 지연시키는 14가지 방법을 읽어보세요.

우리는 JavaScript를 연기하여 이 문제를 해결할 수 있습니다. 세 가지 방법으로 이 작업을 수행할 수 있습니다.

비동기(Async) JavaScript

<script async src="async.js"></script>

스크립트 태그에 async 속성을 추가하면 JavaScript가 다운로드되는 동안 페이지의 빌드업이 더 이상 차단되지 않습니다. async 속성은 다운로드와 렌더 트리의 빌드업이 동시에 일어날 수 있음을 나타냅니다.

스크립트가 실행되면 페이지가 차단됩니다. 대부분의 경우 async 속성 덕분에 브라우저는 이미 페이지에 First Contentful Paint가 있는 상태로 페이지의 중요한 부분을 빌드할 충분한 시간을 확보합니다.

지연(Defer) JavaScript

<script defer src="deferred.js"></script>

defer 속성은 async 속성과 대략 동일하게 작동합니다. 스크립트 태그에 defer 속성을 추가하면 페이지를 빌드하는 것과 동시에 스크립트를 다운로드할 수도 있습니다. 모든 스크립트가 다운로드된 후, HTML 코드에서 발견된 순서대로 실행됩니다. 이 역시 페이지 표시를 차단할 수 있지만 많은 경우 First Contentful Paint는 이미 화면에 표시되어 있습니다.

12. 외부 리소스에 의존하지 않기

외부 글꼴, 외부 이미지, 외부 스타일시트 또는 외부 스크립트와 같은 외부 리소스는 First Contentful Paint 측면에서 잠재적인 병목 현상입니다. 파일이 호스팅되는 서버에 대한 통제권이 없으므로 파일이 전송되는 속도를 알 수 없습니다. 또한 웹 서버에 대한 기존 연결을 사용할 수 없습니다. 새 서버에 대한 새 연결을 설정해야 하며 여기에는 시간이 걸립니다.

웹에서 가장 일반적인 외부 리소스 중 하나는 Google Fonts입니다. Google Fonts를 셀프 호스팅하면 타사 연결이 완전히 제거되고 캐싱, 압축 및 font-display 동작에 대한 완벽한 제어 권한이 부여됩니다.

Blocking external resources

No external resources

13. 올바른 글꼴 포맷 사용하기

글꼴은 First Contentful Paint와 관련하여 각별한 주의를 기울여야 합니다. 저희가 살펴보는 페이지의 약 99%에서 FCP 요소는 텍스트 줄입니다. 외부 웹 글꼴을 사용하는 경우 먼저 서버에서 이 글꼴을 다운로드해야 하며, 이는 당연히 시간이 걸립니다.

최근 들어 웹 글꼴이 더 많은 주목을 받고 있으며, 더 새롭고 빠른 글꼴 포맷이 더 많아졌습니다. 현재 가장 빠른 글꼴 포맷은 woff2이고 그 다음이 woff입니다. Woff2는 모든 최신 브라우저에서 지원됩니다.

CSS font-face 선언에서 선호하는 웹 글꼴 순서를 지정할 수 있습니다. 다음과 같이 수행합니다.

 @font-face {
   font-family: 'myFont';
   font-weight: 400;
   font-style: normal;
   font-display: swap;
   unicode-range: U+000-5FF
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

14. Font-display: swap

웹 글꼴을 사용할 때 이 글꼴의 기본 동작은 글꼴이 로드될 때까지 페이지에 텍스트를 표시하지 않는 것입니다. 이것은 일반적으로 First Contentful Paint를 직접적으로 희생시킵니다. 웹 글꼴을 로드하는 동안 텍스트가 계속 표시되도록 보장하는 방법에 대한 완벽 가이드를 읽어보세요.

font-display:swap 선언을 사용하여 이 문제를 해결할 수 있습니다. 이를 사용하면 웹 글꼴이 백그라운드에 로드되는 동안 브라우저가 아는 글꼴로 여전히 페이지에 텍스트를 표시하도록 선택할 수 있습니다.

Without font-display:swap

With font-display:swap

font-display: swap vs optional

FCP 최적화를 위한 두 가지 일반적인 font-display 전략이 있습니다.

/* swap: Shows fallback font immediately, swaps when webfont loads */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Shows fallback font, only uses webfont if already cached */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

font-display: swap을 사용하면 폴백 글꼴로 텍스트가 즉시 렌더링되므로 가능한 가장 빠른 FCP를 보장합니다. font-display: optional을 사용하면 첫 방문 시 스타일이 지정되지 않은 텍스트의 깜박임(FOUT)을 완전히 방지할 수 있지만 웹 폰트는 브라우저 캐시에 이미 있는 경우에만 표시됩니다. 대부분의 사이트에서 FCP를 위해 swap을 선택하는 것이 더 나은 선택입니다.

15. DOM 크기 최소화

웹 페이지는 HTML로 구성됩니다. 브라우저가 가장 먼저 하는 일은 HTML을 DOM 노드로 변환하는 것입니다. 즉, 나중에 렌더 트리를 구성하는 데 사용되는 HTML 요소의 트리 구조입니다. 렌더 트리에서 브라우저는 렌더링을 시작하고 마침내 웹 페이지가 화면에 나타납니다.

얼마나 많은 DOM 노드(HTML 요소)를 가지고 있고 트리 구조에서 이러한 DOM 노드가 얼마나 깊은지에 따라 브라우저가 페이지를 구축하는 것이 얼마나 복잡한지 결정됩니다. DOM 노드가 너무 많으면 CSS 및 JavaScript 분석에도 더 많은 시간이 걸립니다. 이는 다시 한번 전적으로 FCP를 직접적으로 희생시킵니다.

다음 방법으로 이 문제를 해결하세요:

• Lazy load parts of your web page
  초기 디스플레이의 속도를 높이려면 나중에 AJAX를 통해 푸터와 같은 웹사이트의 일부를 로드하는 것을 고려하세요.
• Make use of content-visibility
  CSS 속성 content-visibility는 렌더링 중에 스타일, 레이아웃 및 페인트를 건너뛰도록 브라우저에 지시합니다. 요소가 표시되기 직전에 수행합니다.
• Split large pages into multiple pages
  대규모 페이지를 여러 페이지로 분할하면 DOM 노드의 수를 줄일 수 있습니다.
• Implement infinite scroll
  무한 스크롤(Infinite scroll)은 기본적으로 지연 로딩(lazy loading)입니다. 이미지(Pinterest)나 큰 데이터 테이블과 같이 반복되는 요소를 스크롤할 때 무한 스크롤은 페이지 속도를 크게 향상시킬 수 있습니다.
• Avoid JavaScript DOM interaction
  페이지에 많은 수의 DOM 노드가 있을 때는 JavaScript에 각별히 주의하세요. querySelectorAll과 같은 명령은 많은 수의 DOM 노드를 로드하여 메모리 사용량을 증가시킬 수 있습니다.
• Avoid complicated CSS declarations
  DOM 노드 수가 많은 복잡한 CSS 명령에 특히 주의하세요. 예를 들어, 페이지의 모든 div 요소에 대해 last-child 상태를 확인하는 것은 리소스 소모가 클 수 있습니다.
• Use web workers to spare your browser's main thread
  Web workers는 웹 페이지와 병렬로 실행할 수 있는 JavaScript입니다. 백그라운드에서 실행되는 명령을 이러한 Web workers에게 전달할 수 있습니다. Web worker가 명령을 실행하면 이를 원래 페이지로 전달합니다. 이 방식의 장점은 페이지가 정지하지 않고도 복잡한 JavaScript를 실행할 수 있다는 것입니다.

관련 최적화 가이드

FCP를 개선하려면 여러 영역에 걸친 작업이 필요합니다. 가장 관련된 가이드는 다음과 같습니다.

• Google Fonts 셀프 호스팅: 타사 연결을 제거하고 글꼴 전송에 대한 완벽한 통제권을 확보합니다.
• 웹 폰트 로드 중 텍스트가 표시되도록 보장: font-display를 사용하여 빠른 텍스트 렌더링을 보장합니다.
• JavaScript를 지연시키는 14가지 방법: JavaScript가 FCP를 차단하는 것을 막는 모든 기술.
• 사용하지 않는 CSS 수정 및 제거: 렌더링을 차단하는 CSS를 최소한으로 줄입니다.
• 103 Early Hints: HTML이 도착하기 전에 브라우저가 리소스 가져오기를 시작할 수 있도록 합니다.
• Largest Contentful Paint (LCP) 가이드: FCP와 LCP는 많은 최적화 전략을 공유합니다. FCP가 느리면 LCP도 느려질 것입니다.
• Time to First Byte (TTFB) 가이드: TTFB는 FCP에 가장 크게 기여하는 단일 요소입니다. 서버 응답이 느린 경우 여기서 시작하세요.