홈페이지 성능 최적화
— 속도와 Core Web Vitals
홈페이지 속도는 Core Web Vitals 세 지표로 평가합니다. LCP(최대 콘텐츠 표시) 2.5초 이하, INP(상호작용 반응) 200ms 이하, CLS(레이아웃 이동) 0.1 이하가 '좋음' 기준입니다. 빨라지려면 이미지를 WebP/AVIF로 줄이고 width·height를 명시하고, 첫 화면 자원에 preload·fetchpriority를, 나머지엔 lazy를 쓰고, 외부 폰트·스크립트를 절제하면 됩니다. 점수는 약속하지 않습니다 — 측정 가능한 개선만 합니다.
- Core Web Vitals 합격선 = LCP 2.5초 · INP 200ms · CLS 0.1 (현장 데이터 75퍼센타일 기준).
- 느린 사이트는 이탈↑ · 전환↓ · SEO 불리 — 손실이 운영 내내 누적됩니다.
- 핵심 기법 = 이미지 WebP/AVIF · width/height · lazy · fetchpriority · preload · 코드 최소화 · 외부 스크립트 절제 · 시스템폰트.
- 측정은 Lighthouse · PageSpeed Insights · CrUX로. PLOT은 외부 CDN 0·시스템폰트로 빠른 기본값을 둡니다.
Core Web Vitals란 무엇이고 합격 기준은?
Core Web Vitals는 구글이 정한 사용자 체감 성능 지표입니다. 세 가지로 나뉩니다. LCP(Largest Contentful Paint)는 화면에서 가장 큰 콘텐츠가 뜨는 시점으로 2.5초 이하가 좋음입니다. INP(Interaction to Next Paint)는 사용자가 누른 뒤 화면이 반응하는 속도로 200ms 이하가 좋음입니다. CLS(Cumulative Layout Shift)는 로딩 중 요소가 밀려나는 정도로 0.1 이하가 좋음입니다. 이 값들은 실제 방문자 데이터의 75퍼센타일로 평가하므로, 셋 모두 좋음 구간에 들어야 통과로 봅니다.
사이트가 느리면 실제로 어떤 비용이 드나?
느림의 비용은 세 갈래로 나타납니다. 첫째 이탈입니다. 첫 화면이 늦게 뜨면 방문자는 기다리지 않고 떠납니다. 둘째 전환 손실입니다. 폼이나 버튼 반응이 둔하면(INP 악화) 문의 직전에 이탈이 생깁니다. 셋째 SEO 불이익입니다. Core Web Vitals는 구글 랭킹 신호의 일부라, 느린 사이트는 같은 콘텐츠로도 노출에서 밀립니다. 광고비로 모은 트래픽이 느린 첫 화면에서 새면, 절약한 제작 시간보다 훨씬 큰 비용이 됩니다.
이미지는 어떻게 줄여야 빨라지나?
이미지는 대부분 페이지에서 가장 무거운 자원이라 가장 먼저 손봐야 합니다. 핵심은 네 가지입니다.
- 차세대 포맷 — JPG/PNG 대신 WebP·AVIF로 변환하면 같은 화질에서 용량이 크게 줄어 LCP가 빨라집니다.
- 크기 명시 — 모든
<img>에width·height를 넣으면 브라우저가 자리를 미리 잡아 CLS를 막습니다. - 지연 로딩 — 첫 화면 아래 이미지는
loading="lazy"로 나중에 불러옵니다. - 우선순위 — 첫 화면 핵심 이미지 하나에는
fetchpriority="high"를 줘 LCP 요소를 먼저 당겨옵니다.
| 지표 | '좋음' 기준 | 대표 개선법 |
|---|---|---|
| LCP (최대 콘텐츠) | 2.5초 이하 | 첫 화면 이미지 WebP/AVIF + fetchpriority·preload, 서버 응답 단축 |
| INP (상호작용 반응) | 200ms 이하 | 무거운 JS 분할·지연, 외부 스크립트 절제, 메인 스레드 점유 축소 |
| CLS (레이아웃 이동) | 0.1 이하 | img·iframe에 width/height, 폰트 스왑 안정화, 동적 삽입 자리 예약 |
▲ 세 지표는 실제 방문자 데이터의 75퍼센타일로 평가합니다. 랩 점수가 높아도 현장 데이터가 나쁠 수 있으니 둘을 함께 봅니다.
코드와 외부 자원은 어떻게 절제하나?
이미지 다음으로 큰 변수는 코드와 외부 의존입니다. CSS·JS는 최소화(공백·주석 제거)하고, 첫 화면에 필요 없는 스크립트는 defer·async로 미룹니다. 가장 무거운 건 외부 스크립트입니다 — 광고·분석·채팅 위젯·외부 CDN은 추가 요청과 메인 스레드 점유를 만들어 INP를 떨어뜨립니다. 첫 화면 LCP 자원에는 <link rel="preload">로 우선 로딩을 거는 것이 효과적입니다. PLOT은 외부 CDN 의존을 0으로 두고 자원을 같은 도메인에서 직접 서빙해, 외부 서버 지연·차단 변수를 제거합니다.
웹폰트 대신 시스템폰트를 쓰면 왜 빠른가?
외부 웹폰트는 별도 네트워크 요청을 만들고, 폰트가 도착할 때까지 글자 표시가 지연되거나(FOIT) 뒤늦게 바뀌며 레이아웃이 흔들립니다(CLS 악화). 시스템 폰트(기기에 이미 깔린 폰트)를 쓰면 폰트 요청 자체가 사라져 글자가 즉시 뜨고, CLS도 안정됩니다. PLOT이 시스템폰트를 기본값으로 두는 이유가 이것입니다 — 빠르고, 한글 가독성도 충분합니다. 디자인상 꼭 필요한 경우에만 자체 호스팅 폰트를 font-display:swap과 함께 절제해 씁니다.
성능은 어떤 도구로 측정하나?
- Lighthouse — 크롬 개발자도구 내장. 내 환경의 랩 데이터로 빠르게 진단하고 개선 항목을 받습니다.
- PageSpeed Insights — 랩 데이터와 실제 사용자 데이터를 함께 보여줘 둘의 차이를 확인합니다.
- CrUX(Chrome User Experience Report) — 실제 방문자 경험 기반 현장 데이터. Core Web Vitals 통과 판단의 최종 근거입니다.
※ 랩 점수는 진단용 참고치입니다. PLOT은 특정 점수(예: 100점)를 약속하지 않습니다 — 측정 가능한 개선만 하고, 현장 데이터로 결과를 확인합니다.
분양 사이트에서 속도가 특히 중요한 이유는?
분양 사이트는 트래픽 대부분이 모바일·광고 유입입니다. 첫 화면이 늦게 뜨면 비싼 광고비가 그대로 샙니다. 모바일 최적화는 분양 사이트 모바일 최적화 체크리스트에서, 화면 크기별 대응은 반응형 웹이란에서 더 다룹니다. 속도를 전환으로 잇는 설계는 전환되는 홈페이지의 조건으로 이어집니다. 분양 사이트 전반은 분양 사이트 제작에서 한눈에 볼 수 있습니다.
속도·모바일·전환을 한 흐름으로 보려면 → 전환되는 홈페이지의 조건. 화면 대응 기초는 반응형 웹이란으로 이어집니다.
자주 묻는 질문
Core Web Vitals 합격 기준은 무엇인가요?
사이트가 느리면 실제로 어떤 손해를 보나요?
이미지를 어떻게 줄여야 사이트가 빨라지나요?
성능은 어떤 도구로 측정하나요?
외부 폰트와 스크립트가 속도에 영향을 주나요?
우리 사이트는 얼마나 빠를까?
현장 정보만 주시면 속도·Core Web Vitals를 고려한 설계로 현장 맞춤 견적을 무료로 보내드립니다. 점수를 부풀리지 않고, 무엇을 어떻게 빠르게 만드는지 항목으로 보여드립니다.
무료 견적 받기※ 본 글의 Core Web Vitals 기준(LCP 2.5초·INP 200ms·CLS 0.1)은 구글이 공개한 '좋음' 임계값을 따른 것으로, 기준은 변경될 수 있으니 측정 시점의 공식 문서를 확인하세요. PLOT은 외부 CDN 0·시스템폰트를 기본값으로 두지만, 특정 성능 점수를 보장하지 않으며 현장·콘텐츠 조건에 따라 결과는 달라집니다. 이미지·포트폴리오는 PLOT이 역량 시연을 위해 자체 제작한 데모·리디자인 컨셉이며, 실제 의뢰·감수·승인을 받은 것이 아닙니다. 검증되지 않은 외부 통계·후기는 사용하지 않았습니다. 최종 업데이트 .