홈페이지 로딩 2초 안에 끝내는 이미지·폰트 구조, 실제로 이렇게 만든다

# 홈페이지 로딩 2초 안에 끝내는 이미지·폰트 구조, 실제로 이렇게 만든다
2026년 기준 Core Web Vitals와 LCP 개선 실무 가이드

홈페이지를 열었는데 이미지가 뜨는 데 3초, 4초씩 걸린다면 방문자는 이미 이탈했을 가능성이 높습니다. LCP(최대 콘텐츠풀 페인트)의 양호 기준은 2.5초 이하이며, 이 기준은 2026년 현재까지도 그대로 유지되고 있습니다. 문제는 대부분의 홈페이지가 이 2.5초를 못 지키는 이유가 서버 성능이 아니라 이미지와 폰트를 다루는 구조 자체에 있다는 점입니다.

이 글은 디자인 단계에서 "무게 예산을 얼마로 잡을지" 같은 기획 논의를 다루지 않습니다. 대신 이미 만들어진 홈페이지를 놓고 실제 구현 단계에서 무엇을, 어떤 순서로 손봐야 하는지를 다룹니다.
이미지 포맷을 WebP·AVIF 중 무엇으로 바꿀지, 히어로 이미지와 스크롤 아래 이미지를 왜 다르게 취급해야 하는지, 폰트를 왜 서브셋하고 하나로 합쳐야 하는지, font-display 값을 상황에 따라 어떻게 고를지, preload는 왜 아무 데나 걸면 안 되는지를 원리 중심으로 정리했습니다.

이 글을 다 읽고 나면 브라우저 개발자도구에서 성능 탭을 열었을 때 "왜 이 이미지가 늦게 뜨는지", "왜 텍스트가 잠깐 사라졌다 나타나는지"를 스스로 진단하고 고칠 수 있게 될 겁니다.

시작 전 알아둬야 할 개념과 준비물

이 작업을 시작하기 전에 Core Web Vitals가 무엇을 어떻게 측정하는지부터 정확히 알아야 엉뚱한 곳에 시간을 쓰지 않습니다. Core Web Vitals는 2024년 3월 12일부터 LCP, CLS, INP 세 가지 지표로 평가됩니다. 기존에 쓰이던 FID(최초 입력 지연)는 이날 INP(다음 페인트까지의 상호작용)로 완전히 대체되었습니다.

여기서 중요한 건 판정 방식입니다.
평균값이 아니라 실제 방문자 데이터의 75번째 백분위수(75th percentile)로 판정합니다.
즉 방문자 100명 중 75명이 2.5초 이내에 LCP를 경험해야 "양호"로 분류되고, 25명이 느리게 겪었다고 해도 평균이 낮으면 통과되는 게 아니라 백분위수 자체가 기준을 넘어야 합니다. 이 때문에 특정 네트워크 환경이나 특정 기기에서만 느린 문제도 반드시 잡아야 전체 판정이 좋아집니다.

작업 전에 준비해두면 좋은 것들이 있습니다.

먼저, 원본 해상도의 이미지 파일입니다. 이미 압축되어 화질이 깨진 파일로는 최적화 작업의 의미가 줄어듭니다.

다음으로, 현재 웹폰트 파일 목록과 실제 사용 중인 두께(weight)·글자셋 확인이 필요합니다. 대부분 웹사이트는 실제로 쓰지 않는 두께의 폰트 파일까지 함께 불러오고 있는 경우가 많습니다.

그리고, 브라우저 개발자도구의 Network 탭과 Lighthouse(또는 PageSpeed Insights) 접근 권한입니다. 개선 전후를 비교할 측정 도구가 없으면 감으로 작업하게 됩니다.

마지막으로, 이미지 변환 도구(포맷 변환·리사이징이 가능한 도구) 준비입니다. 별도 소프트웨어든 온라인 도구든 WebP·AVIF로 변환하고 여러 크기로 리사이징할 수 있는 환경이 있어야 합니다.

Step 1. 이미지 포맷을 WebP부터 검토하고 AVIF는 조건부로 적용하기

이미지 포맷 선택은 압축률과 인코딩 비용 사이의 트레이드오프 문제이지, 무조건 최신 포맷을 쓰는 게 정답이 아닙니다. WebP와 AVIF 둘 다 JPEG·PNG보다 파일 크기가 작지만, 그만큼 얻는 이득과 치러야 할 비용이 다릅니다.

WebP는 JPEG 대비 일반적으로 25~35% 파일 크기를 줄이는 것으로 알려져 있습니다. AVIF는 자료에 따라 JPEG 대비 40~60% 더 작다고 하거나, WebP 대비 약 50% 작다고 하거나, 또 다른 자료에서는 WebP 대비 20~40% 작다고 하는 등 수치 편차가 상당히 큽니다. 이미지의 종류(사진인지 일러스트인지), 압축 설정값에 따라 결과가 크게 달라지기 때문에 이 수치를 절대 기준으로 삼기보다는 "AVIF가 WebP보다 더 작을 가능성이 높다" 정도로 이해하는 게 안전합니다.

문제는 AVIF의 인코딩 속도입니다. 기본 설정 기준 1920×1080 이미지 한 장을 인코딩하는 데 AVIF는 약 4초가 걸리는 반면, 동일 품질의 WebP는 약 90밀리초밖에 걸리지 않습니다. 이는 단순히 "변환하는 사람이 좀 더 기다리면 되는" 문제가 아닙니다.

이미지 수가 많은 쇼핑몰이나 갤러리형 사이트에서 빌드 시점(또는 업로드 시점)에 실시간으로 이미지를 변환하는 구조라면, AVIF는 서버 자원과 처리 시간을 훨씬 많이 잡아먹습니다. 이미지가 수십 장, 수백 장 단위로 쌓이는 상황이라면 이 차이가 누적되어 배포 파이프라인 전체를 느리게 만들 수 있습니다.

그래서 실무에서는 이렇게 판단 기준을 나눠서 접근하는 것이 합리적입니다.

① 이미지 수가 적고(수십 장 이내) 자주 바뀌지 않는 정적인 페이지 → AVIF를 우선 검토. 한 번 인코딩해두면 그 이후로는 인코딩 비용이 반복되지 않기 때문입니다.

② 이미지가 실시간으로 업로드되고 수량이 많은 쇼핑몰·게시판형 서비스 → WebP를 기본으로 하고, 트래픽이 많은 핵심 이미지 몇 개만 선별적으로 AVIF 추가 변환.

③ 구형 브라우저 지원이 중요한 서비스 → JPEG/PNG를 폴백(fallback)으로 반드시 유지하고, WebP·AVIF를 지원 브라우저에게만 우선 제공.

여기서 주의할 점은, 포맷만 바꾼다고 끝이 아니라는 것입니다. 원본 이미지가 화면에 표시되는 크기보다 훨씬 큰 해상도로 업로드되어 있다면, 포맷을 아무리 최신으로 바꿔도 근본적인 크기 문제는 해결되지 않습니다. 실제 표시 영역에 맞는 여러 해상도(예: 모바일용, 태블릿용, 데스크톱용)로 리사이징한 뒤 반응형으로 제공하는 작업이 포맷 변환과 함께 이뤄져야 진짜 효과가 납니다.

Step 2. 히어로 이미지는 최우선으로, 스크롤 아래 이미지는 지연 로딩으로 분리하기

같은 페이지 안의 이미지라도 화면에 보이는 위치에 따라 완전히 반대로 처리해야 합니다. 첫 화면(뷰포트 안, 흔히 히어로 영역)에 있는 이미지는 최대한 빨리 받아야 하고, 스크롤을 내려야 보이는 이미지는 오히려 늦게 받아도 상관없습니다. 이 둘을 같은 방식으로 처리하는 것이 로딩 속도를 망치는 가장 흔한 원인 중 하나입니다.

여기서 실무자들이 자주 저지르는 실수가 하나 있습니다. "이미지는 다 늦게 불러오는 게 빠른 거 아니야?"라는 생각으로 페이지의 모든 `img` 태그에 `loading="lazy"`를 일괄 적용하는 것입니다. 이건 명백히 틀린 접근입니다.

브라우저에는 프리로드 스캐너(preload scanner)라는 게 있습니다. 이 스캐너는 HTML 문서가 파싱되는 동안 앞으로 필요할 자원(이미지, 폰트, 스크립트 등)을 미리 훑어보고 다운로드를 조기에 시작시키는 역할을 합니다. 그런데 프리로드 스캐너는 원본 HTML에 `loading="lazy"`가 적혀 있으면 그 이미지 요청의 우선순위를 낮춰버립니다. 자바스크립트가 개입해서 "사실 이 이미지는 화면에 보이니까 지금 받아야 해"라고 정정하기도 전에, 이미 우선순위가 낮아진 상태로 굳어지는 겁니다.

문제는 LCP 요소가 대부분 히어로 이미지라는 점입니다. 즉, `loading="lazy"`를 무심코 히어로 이미지에 걸어버리면 그게 곧 LCP를 직접 지연시키는 원인이 됩니다. 가장 빨리 떠야 할 이미지를 스스로 늦게 받도록 만든 셈입니다.

그래서 실무에서는 이런 기준으로 나눠서 처리해야 합니다.

첫째, 뷰포트 안에 들어오는 히어로 이미지(LCP 후보)는 지연 로딩을 걸지 않습니다. 오히려 이 이미지는 우선순위를 높이는 방향(다음 섹션에서 다룰 preload)으로 다뤄야 합니다.

둘째, 스크롤을 내려야 보이는 이미지들은 `loading="lazy"`를 적극적으로 적용합니다. 사용자가 그 위치까지 스크롤하지 않으면 애초에 다운로드될 필요가 없는 자원이기 때문에, 초기 로딩 부담을 줄여주는 효과가 명확합니다.

셋째, 뷰포트 경계에 걸쳐 있어서 히어로인지 스크롤 아래인지 애매한 이미지는 보수적으로 판단해서 우선 로딩 쪽으로 처리하는 게 안전합니다. LCP 측정은 실제 방문자의 화면 크기·기기에 따라 달라지므로, 데스크톱에서는 스크롤 아래였던 이미지가 모바일 세로 화면에서는 첫 화면 안에 들어올 수도 있습니다.

이 판단을 위해서는 개발자도구의 Performance 탭이나 Lighthouse 리포트에서 "LCP element"로 지정된 요소가 무엇인지 직접 확인하는 습관이 필요합니다. 감으로 "이건 위에 있으니까 빨리 받아야지"라고 판단하지 말고, 실제로 브라우저가 무엇을 LCP 요소로 지목하는지 확인한 뒤 그 요소만 정확히 우선 처리하는 게 핵심입니다.

Step 3. 웹폰트는 서브셋 처리하고 파일 개수를 최소한으로 줄이기

웹폰트가 느린 이유는 폰트 자체가 무거워서가 아니라 필요 이상으로 많은 글자와 두께를 함께 불러오기 때문입니다. 폰트 최적화는 포맷 선택, 서브셋(subset) 처리, 파일 개수 축소라는 세 가지 축으로 접근해야 합니다.

먼저 포맷입니다. WOFF2가 사실상 표준이며, 2026년 기준 주요 브라우저는 모두 WOFF2를 지원합니다. WOFF2는 기존 WOFF 대비 약 30%, TTF(TrueType Font) 대비 약 50% 더 작은 파일 크기를 만듭니다. 아직도 TTF나 OTF 파일을 그대로 웹에 올려서 쓰고 있다면, 포맷을 WOFF2로 바꾸는 것만으로도 상당한 용량 절감이 가능합니다.

다음은 서브셋(subset) 처리입니다. 서브셋이란 폰트 파일에서 실제로 쓰는 글자만 남기고 나머지 언어·기호는 잘라내는 작업을 말합니다. 예를 들어 한글 사이트에서 라틴 알파벳 확장 문자나 키릴 문자, 그리스 문자까지 포함된 풀세트 폰트 파일을 그대로 쓰고 있다면 전혀 쓰지 않는 글자들의 용량까지 방문자가 다운로드하고 있는 셈입니다. Inter 폰트를 예로 들면, 전체 파일은 약 300KB인데 라틴 서브셋만 남기면 약 30KB로 줄어드는 사례가 보고되어 있습니다. 약 10분의 1 수준으로 줄어드는 셈이니, 한글 웹사이트에서 한글·숫자·기본 특수문자만 남기는 서브셋 작업의 효과는 상당히 클 수 있습니다.

마지막은 파일 개수를 줄이는 것입니다. Regular, Bold, Medium, Light, SemiBold 등 두께별로 파일을 전부 따로 불러오고 있다면, 실제 디자인에서 몇 개나 쓰이는지부터 점검해야 합니다. 실무에서 종종 발견되는 패턴은 디자인 시스템에는 5~6단계 두께가 정의되어 있지만 실제 화면에서는 2~3단계만 쓰이는 경우입니다. 쓰지 않는 두께 파일을 그대로 불러오는 것은 방문자에게 아무 이득 없는 다운로드 비용만 지우는 셈입니다.

여기에 더해, 가변 폰트(variable font)를 활용하면 여러 두께를 하나의 파일 안에 담아 요청 횟수 자체를 줄일 수 있습니다. 다만 가변 폰트 파일은 단일 두께 폰트보다 파일 하나의 용량이 클 수 있으므로, "두께를 3개 이상 실제로 쓰는가"를 먼저 따져보고 도입 여부를 결정하는 게 좋습니다. 두께를 1~2개만 쓴다면 가변 폰트보다 정적(static) 폰트 파일 하나만 쓰는 게 더 가벼울 수 있습니다.

정리하면 다음 순서로 점검하면 됩니다.

먼저, 현재 사용 중인 폰트 파일 포맷을 WOFF2로 통일합니다.

다음으로, 실제 화면에 노출되는 언어·글자셋만 남기고 서브셋 처리합니다.

그리고, 실제 디자인에서 쓰이는 두께만 남기고 나머지 두께 파일 요청을 제거합니다.

마지막으로, 두께가 3개 이상 필요한 경우에만 가변 폰트 도입을 검토합니다.

Step 4. font-display 값은 텍스트 노출과 레이아웃 안정성 중 무엇을 우선할지로 결정하기

font-display 값 선택은 "폰트가 늦게 와도 글자를 먼저 보여줄지" 아니면 "화면이 흔들리더라도 원래 폰트만 쓸지"를 고르는 문제입니다. 이 둘 중 어느 쪽이 항상 옳다고 말할 수 없고, 페이지 성격에 따라 선택이 달라져야 합니다.

font-display: swap은 폰트가 아직 도착하지 않았을 때 일단 시스템 기본 글꼴로 텍스트를 즉시 보여주고, 웹폰트가 도착하면 그때 바꿔치기하는 방식입니다. 장점은 텍스트가 화면에 뜨는 시점이 폰트 다운로드 완료 시점과 무관해진다는 것입니다. 방문자 입장에서는 글자가 안 보이는 "깜박이는 텍스트 없음(FOIT, Flash of Invisible Text)" 상황을 겪지 않고, 대신 폰트가 기본 글꼴에서 웹폰트로 바뀌는 "스타일 바뀐 텍스트 반짝임(FOUT, Flash of Unstyled Text)"을 겪게 됩니다.

문제는 이 폰트 교체 시점에 레이아웃 흔들림(CLS, Cumulative Layout Shift)이 발생할 수 있다는 점입니다. 기본 글꼴과 웹폰트의 글자 폭·행간이 다르면, 폰트가 바뀌는 순간 텍스트 줄바꿈 위치가 달라지고 그 아래 배치된 요소들이 밀리는 현상이 생깁니다. CLS 역시 Core Web Vitals의 한 축이므로, LCP를 개선하려다 CLS를 악화시키는 상황이 생길 수 있습니다.

그래서 실무에서는 페이지 성격에 따라 값을 다르게 골라야 합니다.

본문 텍스트가 많고 콘텐츠 가독성이 중요한 페이지(블로그, 뉴스, 정보성 페이지)라면 swap을 우선 고려할 만합니다. 텍스트가 조금이라도 빨리 보이는 게 방문자의 체감 속도에 직접적인 영향을 주기 때문입니다. 레이아웃 흔들림은 폰트 매칭(대체 글꼴의 글자 폭을 웹폰트와 비슷하게 맞추는 설정)으로 어느 정도 완화할 수 있습니다.

로고, 브랜드 타이포그래피처럼 폰트 자체가 디자인의 핵심인 요소라면 상황이 다릅니다. 여기서는 폰트가 바뀌는 순간의 시각적 불일치가 브랜드 경험을 해칠 수 있어서, 짧은 시간 동안 텍스트를 숨겼다가(block 기간) 웹폰트가 오면 그때 보여주는 방식을 고려할 수 있습니다. 다만 이 경우에도 무한정 기다리게 하면 안 되고, 일정 시간이 지나면 폴백 글꼴로 전환되는 타임아웃이 있는 값을 쓰는 것이 안전합니다.

이미 레이아웃 흔들림 문제로 CLS 지표가 나쁘게 나오고 있는 페이지라면, 텍스트 노출 속도보다 안정성을 우선해서 폰트 교체 자체를 최소화하는 방향(폴백 글꼴을 그대로 유지하고 웹폰트로의 전환을 생략하거나 지연시키는 방식)을 검토할 수 있습니다.

결국 이 선택은 "이 페이지에서 방문자가 더 못 견디는 게 뭔가"를 기준으로 판단해야 합니다.
텍스트가 안 보이는 몇백 밀리초를 못 견디는 페이지인지, 아니면 화면이 갑자기 움직이는 걸 못 견디는 페이지인지를 구분해서 값을 고르는 게 핵심입니다.

자주 발생하는 오류와 원인 진단하기

preload를 여러 개 걸었더니 오히려 페이지가 더 느려지는 현상이 가장 흔하게 발생하는 실수입니다. preload는 브라우저에게 "이 파일은 다른 것보다 먼저 받아둬"라고 알려주는 힌트인데, 이 힌트를 너무 많은 자원에 걸어버리면 브라우저 입장에서는 "전부 최우선"이라는 모순된 지시를 받는 셈이 됩니다. 결과적으로 정작 중요한 히어로 이미지나 핵심 폰트 파일이 다른 preload 자원들과 대역폭을 나눠 쓰면서 오히려 늦게 도착하는 역설이 벌어집니다.

이 문제의 원인은 대체로 "preload를 걸면 무조건 빨라진다"는 오해에서 시작됩니다. preload는 우선순위를 재배치하는 도구이지, 다운로드 자체를 공짜로 빠르게 만드는 마법이 아닙니다. 네트워크 대역폭은 한정되어 있으므로, preload로 우선순위를 올린 자원이 늘어날수록 상대적으로 "덜 중요한" 자원으로 밀려나는 것도 늘어난다는 점을 기억해야 합니다. 그래서 preload는 정말로 LCP나 초기 렌더링에 직접 영향을 주는 1~2개 자원(히어로 이미지, 핵심 본문 폰트 파일 정도)으로 제한하는 것이 원칙입니다.

LCP 이미지에 loading="lazy"가 실수로 남아 있는 경우도 자주 발견됩니다. 특히 CMS나 에디터에서 이미지를 삽입할 때 기본값으로 lazy가 자동 적용되는 경우, 히어로 영역에 넣은 이미지에도 이 속성이 그대로 남아있는 걸 놓치기 쉽습니다. 개발자도구의 Elements 탭에서 히어로 이미지 태그를 직접 확인해서 loading 속성이 어떻게 되어 있는지 점검하는 습관이 필요합니다.

폰트 서브셋을 했는데도 용량이 줄지 않는 경우는, 서브셋 도구가 실제 페이지에서 쓰이는 문자를 정확히 인식하지 못했거나, 서브셋된 파일이 아니라 원본 파일이 여전히 로드되고 있는 경우가 많습니다. Network 탭에서 실제로 다운로드되는 폰트 파일의 크기를 직접 확인해서 예상한 용량과 일치하는지 검증해야 합니다.

이미지 포맷을 WebP·AVIF로 바꿨는데 체감 속도가 그대로인 경우는 대부분 원본 해상도 문제입니다. 포맷만 바꾸고 실제 표시 크기보다 훨씬 큰 원본을 그대로 서빙하고 있다면, 파일 형식이 바뀌어도 전체 용량 감소 폭은 제한적입니다. 표시 영역에 맞는 리사이징이 함께 이뤄졌는지 다시 확인해야 합니다.

실무에서 더 챙기면 좋은 활용 팁

preload를 걸 때는 "이 페이지에서 LCP 요소가 무엇인지" 먼저 확정한 다음에 그 하나에만 집중하는 것이 가장 확실한 접근입니다. 페이지마다 LCP 요소는 다를 수 있습니다. 어떤 페이지는 히어로 이미지가 LCP 요소이고, 어떤 페이지는 큰 제목 텍스트가 LCP 요소일 수 있습니다. 텍스트가 LCP 요소라면 이미지 preload보다 해당 텍스트에 쓰이는 폰트 파일을 preload하는 게 더 효과적일 수 있습니다.

반응형 이미지를 쓸 때 여러 해상도 중 어떤 것이 실제로 로드될지 브라우저에 미리 알려주는 방식(sizes 속성 등)을 정확히 설정하는 것도 중요한 포인트입니다. 이 설정이 부정확하면 브라우저가 필요 이상으로 큰 이미지를 선택해서 받아오는 경우가 생깁니다. 모바일 화면인데 데스크톱용 큰 이미지를 받아오고 있는 건 아닌지 개발자도구의 디바이스 시뮬레이션 모드로 확인해보는 것이 좋습니다.

폰트 파일을 preload할 때는 실제로 페이지 렌더링 초기에 쓰이는 폰트인지 확인해야 합니다. 스크롤을 내려야 나오는 특수한 섹션에서만 쓰이는 폰트를 초기 preload에 넣으면, 정작 초기 화면 렌더링에 필요한 자원과 대역폭을 나눠 쓰게 됩니다.

이미지 CDN이나 이미지 처리 서비스를 활용하고 있다면, 포맷 자동 협상(Accept 헤더를 보고 브라우저가 지원하는 최적 포맷을 서버가 알아서 골라주는 방식) 기능이 있는지 확인해보는 것도 좋은 접근입니다. 이 기능이 있으면 WebP·AVIF·JPEG를 브라우저별로 일일이 분기 처리하지 않아도 서버 쪽에서 자동으로 최적 포맷을 내려줍니다.

정기적으로 실제 사용자 데이터(필드 데이터)를 확인하는 습관도 챙겨야 합니다. 개발 환경에서 측정한 랩(lab) 데이터와 실제 방문자가 겪는 필드 데이터는 다를 수 있습니다. 앞서 설명했듯 판정 기준이 75번째 백분위수이기 때문에, 실제 방문자들의 다양한 네트워크 환경과 기기 조건에서의 데이터를 주기적으로 살펴봐야 진짜 개선 여부를 확인할 수 있습니다.

이미지·폰트 구조를 넘어 전체 성능으로 확장하기

이미지와 폰트 최적화는 로딩 속도 개선의 시작점이지 전부가 아닙니다. 이 두 요소를 정리하고 나면 자연스럽게 다음 단계로 확장해서 점검해볼 부분들이 보이기 시작합니다.

CLS(레이아웃 흔들림) 관점에서 이미지에 명시적인 width·height(또는 aspect-ratio) 값을 지정하는 것은 폰트 최적화와도 연결되는 지점입니다. 이미지 크기가 사전에 지정되어 있지 않으면 이미지가 로드되기 전과 후로 레이아웃이 흔들리는데, 이는 font-display 전환 시의 흔들림과 합쳐져서 CLS 지표를 더 악화시킬 수 있습니다. 이미지와 폰트 두 요소가 같은 페이지에서 동시에 레이아웃을 흔들지 않도록 함께 점검하는 게 좋습니다.

INP(다음 페인트까지의 상호작용) 관점에서는 이미지 지연 로딩을 처리하는 자바스크립트 코드가 메인 스레드를 오래 붙잡고 있지 않은지도 확인할 필요가 있습니다. 이미지 개수가 매우 많은 페이지에서 지연 로딩 감지 로직이 무겁게 작동하면, 스크롤 중 다른 상호작용(버튼 클릭 등)에 대한 응답이 늦어지는 원인이 될 수 있습니다.

서브셋과 preload 원칙은 이미지·폰트 외의 다른 자원(아이콘 스프라이트, 초기 렌더링에 필요한 최소 스타일시트 등)에도 동일하게 적용할 수 있는 사고방식입니다. "이 자원이 정말 초기 렌더링에 필요한가"라는 질문 자체가 핵심이므로, 이미지·폰트뿐 아니라 페이지 전체 자원을 놓고 같은 기준으로 재검토해보는 습관을 들이면 성능 개선 작업의 시야가 넓어집니다.

쇼핑몰처럼 상품 이미지가 매우 많은 페이지 구조라면, 앞서 다룬 히어로/스크롤 아래 구분 원칙을 상품 목록 페이지에도 그대로 적용할 수 있습니다. 첫 화면에 노출되는 상품 몇 개만 우선 로딩하고, 스크롤해서 보이는 나머지 상품 이미지는 지연 로딩으로 처리하는 구조가 대표적인 응용 사례입니다.

마무리 전 최종 점검 체크리스트

작업을 마무리하기 전에 아래 항목들을 순서대로 점검해보세요.

① 히어로(LCP 후보) 이미지에 loading="lazy"가 걸려 있지 않은지 개발자도구로 직접 확인했는가

② 스크롤 아래 이미지들에는 loading="lazy"가 적용되어 있는지 확인했는가

③ 이미지 포맷이 페이지 성격(이미지 수량, 갱신 빈도)에 맞게 WebP 또는 AVIF로 전환되었는가

④ 원본 이미지가 실제 표시 크기에 맞게 리사이징되었는가 (포맷 변환만으로 끝내지 않았는가)

⑤ 폰트 파일이 WOFF2 포맷이고, 실제 사용하는 언어·글자셋으로 서브셋 처리되었는가

⑥ 실제 쓰지 않는 두께의 폰트 파일 요청이 남아있지 않은지 Network 탭으로 확인했는가

⑦ font-display 값이 페이지 성격(텍스트 중심 vs 브랜드 타이포그래피 중심)에 맞게 선택되었는가

⑧ preload가 1~2개의 핵심 자원(LCP 이미지 또는 핵심 폰트)에만 걸려 있는지, 과도하게 많은 자원에 걸려 있지 않은지 확인했는가

⑨ Lighthouse나 PageSpeed Insights로 개선 전후 LCP 수치를 실제로 비교했는가

자주 묻는 질문 FAQ

Q1. WebP와 AVIF 중 하나만 골라야 한다면 뭘 선택해야 하나요?
페이지 성격에 따라 다릅니다. 이미지 수가 적고 자주 바뀌지 않는 정적 페이지라면 AVIF가 압축률 면에서 유리할 가능성이 높습니다. 반대로 이미지가 실시간으로 대량 업로드되는 구조라면 인코딩 속도가 훨씬 빠른 WebP를 기본으로 두는 것이 서버 부담 관리 측면에서 안전합니다.

Q2. font-display: swap을 쓰면 항상 좋은 건가요?
아닙니다. swap은 텍스트 노출 속도를 우선시하는 대신 폰트 교체 시점의 레이아웃 흔들림(CLS) 위험을 감수하는 선택입니다. 본문 텍스트 중심 페이지에는 적합할 수 있지만, 브랜드 타이포그래피가 중요한 랜딩페이지에서는 다른 값을 검토할 필요가 있습니다.

Q3. preload를 아예 안 거는 게 더 안전한가요?
그렇지 않습니다. LCP 요소로 확인된 자원 1~2개에는 preload를 거는 것이 명확히 도움이 됩니다. 다만 "혹시 몰라서" 여러 자원에 preload를 걸어두는 습관이 문제가 되는 것이지, preload 자체가 나쁜 도구는 아닙니다.

Q4. 폰트 서브셋 작업은 한 번 하면 계속 유지되나요?
아닙니다. 페이지에 새로운 언어나 특수문자가 추가되면 기존 서브셋 파일에 해당 글자가 없어서 깨져 보일 수 있습니다. 콘텐츠가 바뀔 때마다 서브셋 범위가 여전히 충분한지 주기적으로 점검하는 것이 필요합니다.

Q5. Lighthouse 점수와 실제 방문자 체감 속도가 다른 이유는 뭔가요?
Lighthouse는 특정 환경에서 한 번 측정하는 랩 데이터이고, Core Web Vitals의 실제 판정은 다양한 실제 방문자의 75번째 백분위수 데이터로 이뤄지기 때문입니다. 랩 데이터가 좋아도 특정 네트워크·기기 조건에서 느리게 겪는 방문자 비율이 높으면 필드 데이터 기준으로는 여전히 개선이 필요할 수 있습니다.

---

이미지와 폰트는 홈페이지에서 가장 무거우면서도 가장 손대기 쉬운 자원입니다. 오늘 다룬 원칙들 — 포맷 선택의 트레이드오프, 히어로와 스크롤 아래의 분리, 폰트 서브셋과 파일 통합, font-display의 상황별 선택, preload의 절제된 사용 — 을 순서대로 적용해보면 개발자도구의 Performance 탭에서 확실히 달라진 그래프를 확인할 수 있을 겁니다. 오늘 바로 개발자도구를 열어서 현재 LCP 요소가 무엇인지부터 확인해보세요.