검색 결과에서 사이트 순위가 갑자기 떨어지거나, Google Search Console에서 "페이지 경험" 점수가 빨간 경고로 표시되는 경험을 해봤을까. 다만 대부분의 개발자들은 Core Web Vitals가 정확히 뭔지, 어떤 지표를 봐야 하는지, 실제로 코드에서 뭘 고쳐야 하는지 전혀 모른 채 검색 결과에서 가져온 추상적인 최적화 팁만 따라 한다. 이번엔 Google Search Console의 페이지 경험 신호가 뭔지, 왜 SEO에 영향을 미치는지, 그리고 실제로 어떻게 측정하고 개선하는지 완벽하게 정리해서 소개하겠다.
페이지 경험은 2021년 6월 Google이 검색 알고리즘에 공식 반영한 순위 인자다. 간단히 말해 사용자가 당신 사이트를 방문했을 때 얼마나 쾌적하게 느끼는지를 측정하는 신호라는 뜻이다. 단순히 콘텐츠 품질만 좋아서는 안 되고, 그 콘텐츠가 빠르게 로드되고, 화면이 안정적이고, 상호작용이 부드러워야 한다는 의미다.
Google Search Console에서 말하는 페이지 경험은 크게 4개 영역으로 나뉜다. 첫째는 Core Web Vitals(핵심 웹 지표)로, LCP(Largest Contentful Paint), FID(First Input Delay), CLS(Cumulative Layout Shift) 세 가지다. 둘째는 모바일 친화성, 셋째는 HTTPS 보안, 넷째는 침입적 팝업 여부다. 이 중에서 가장 직접적으로 순위에 영향을 주는 건 Core Web Vitals인데, 여기서 하나라도 "필요" 상태면 페이지 경험 점수가 급락한다.
LCP(Largest Contentful Paint)는 페이지 로딩 속도다. 사용자가 URL을 입력하고 화면에 주요 콘텐츠(이미지, 텍스트, 비디오)가 보이는 데 걸리는 시간이다. Google이 정한 기준은 2.5초 이하가 "좋음"이고, 4초까지는 "개선 필요", 그 이상이면 "나쁨"이다. 대부분의 블로그나 뉴스 사이트에서 이 지표가 먼저 터진다.
FID(First Input Delay)는 상호작용 반응성이다. 사용자가 버튼을 클릭했거나 링크를 눌렀을 때 브라우저가 반응하는 데 걸리는 시간이다. 100ms 이하면 "좋음", 300ms까지는 "개선 필요", 그 이상이면 "나쁨"이다. 다만 2024년 3월부터는 FID가 INP(Interaction to Next Paint)로 대체되고 있는데, INP는 모든 상호작용의 반응성을 종합적으로 평가한다.
CLS(Cumulative Layout Shift)는 시각적 안정성이다. 페이지를 보고 있는데 갑자기 레이아웃이 밀려나거나 버튼 위치가 바뀌는 현상을 측정한다. 0.1 이하면 "좋음", 0.25까지는 "개선 필요", 그 이상이면 "나쁨"이다. 광고가 로드되면서 콘텐츠가 밀려나는 상황이 대표적이다.
Google Search Console 좌측 메뉴에서 "경험" > "페이지 경험" 항목을 클릭하면, 모바일 vs 데스크톱별로 "좋음", "개선 필요", "나쁨" 비율을 보여준다. 여기서 "나쁨" 수가 많으면 해당 그룹을 클릭해서 구체적으로 어느 페이지가 문제인지 확인할 수 있다.
각 페이지별 상세 데이터를 보려면 같은 메뉴에서 "Core Web Vitals" 탭을 선택하고, 문제가 있는 URL을 클릭하면 된다. 그러면 실제 사용자 데이터(RUM, Real User Monitoring)인 "필드 데이터"와 Google이 실험실 환경에서 측정한 "랩 데이터"를 모두 볼 수 있다. 필드 데이터가 더 중요한데, 이건 지난 28일간 실제 방문자들이 겪은 경험을 반영하기 때문이다.
Google에서 제공하는 도구는 여러 개가 있다. 먼저 PageSpeed Insights는 URL 하나씩 분석할 수 있고, 각 지표별 점수와 "기회" 섹션에서 고칠 항목을 나열해준다. Lighthouse는 Chrome 개발자도구에 내장되어 있어서 로컬 환경에서 바로 테스트할 수 있다. 웹 바이탈즈 라이브러리는 실제 방문자 데이터를 수집할 수 있게 해준다.
LCP 개선 방법부터 보자. 가장 큰 원인은 서버 응답 시간과 이미지 최적화다. PHP 코드라면 데이터베이스 쿼리 성능을 점검하고, 필요하면 캐싱(Redis, Memcached)을 도입한다. 이미지는 WebP 포맷으로 변환하거나, 필요한 크기로 리사이징한 후 CDN에서 제공하는 게 효과적이다.
<?php
// ✗ 잘못된 방법: 원본 이미지를 그대로 로드
echo '<img src="/images/hero.jpg" alt="Hero">';
// ✓ 올바른 방법: 여러 해상도와 WebP 포매팅 제공
echo '<picture>';
echo ' <source srcset="/images/hero-480.webp 480w, /images/hero-1024.webp 1024w" type="image/webp">';
echo ' <source srcset="/images/hero-480.jpg 480w, /images/hero-1024.jpg 1024w" type="image/jpeg">';
echo ' <img src="/images/hero-1024.jpg" alt="Hero" loading="lazy" width="1024" height="768">';
echo '</picture>';
?>FID/INP 개선는 JavaScript 실행 시간 줄이기가 핵심이다. 장시간 실행되는 JavaScript 작업을 작은 청크로 나누거나, 웹 워커에서 처리하는 것도 방법이다.
// ✗ 잘못된 방법: 메인 스레드 블로킹
function processLargeData(data) {
const result = data.map(item => {
// 무거운 계산
let sum = 0;
for (let i = 0; i < 100000; i++) sum += i;
return sum + item.value;
});
return result;
}
// ✓ 올바른 방법: 청크 단위로 분리
async function processLargeDataAsync(data) {
const chunk = 50;
const results = [];
for (let i = 0; i < data.length; i += chunk) {
results.push(...data.slice(i, i + chunk).map(item => {
let sum = 0;
for (let i = 0; i < 100000; i++) sum += i;
return sum + item.value;
}));
// 다른 작업이 끼어들 수 있도록 양보
await new Promise(resolve => setTimeout(resolve, 0));
}
return results;
}CLS 개선는 레이아웃 고정이 기본이다. 이미지나 광고 영역에 미리 width/height를 명시하고, 동적 콘텐츠는 로딩 상태를 미리 표시해야 한다.
<!-- ✗ 잘못된 방법: 크기 미지정 -->
<img src="/image.jpg" alt="Example">
<!-- ✓ 올바른 방법: aspect-ratio로 공간 확보 -->
<img src="/image.jpg" alt="Example" width="1024" height="768" style="aspect-ratio: 1024/768;">
<!-- 동적 콘텐츠의 경우 -->
<div style="width: 100%; aspect-ratio: 16/9; background: #eee;">
<iframe id="video" style="width: 100%; height: 100%;"></iframe>
</div>
✗ PageSpeed Insights 점수만 믿고 필드 데이터를 무시하는 실수가 많다. 랩 데이터(실험실 환경)는 구글의 인프라에서 측정한 것이고, 필드 데이터(실제 사용자)는 느린 연결, 구형 기기에서의 성능을 반영한다. Google Search Console에서 실제 순위에 영향을 주는 건 필드 데이터다.
✓ 필드 데이터에 충분한 샘플이 없으면(보통 28일간 최소 100명 이상) Search Console에 표시되지 않는다. 신규 사이트나 트래픽이 적은 사이트라면 먼저 PageSpeed Insights와 Lighthouse로 최적화한 후, 충분한 데이터가 모일 때까지 기다려야 한다.
✗ 모바일과 데스크톱 점수를 같은 기준으로 보는 실수다. 모바일 기기는 네트워크도 느리고 CPU도 약하므로, 데스크톱에서는 "좋음"이지만 모바일에서는 "나쁨"일 수 있다.
✓ 모바일 우선 최적화를 기본으로 해야 한다. Lighthouse 테스트할 때도 "Throttling"을 "Slow 4G"로 설정해서 느린 환경을 시뮬레이션한다.
✗ 캐싱을 제대로 설정하지 않은 채 모든 요청이 데이터베이스를 거치는 경우다. LCP 개선의 가장 빠른 방법은 서버 응답 시간(TTFB, Time to First Byte)을 줄이는 것인데, 캐싱이 없으면 그럴 수 없다.
✓ 최소한 PHP에서는 Redis나 APCu로 자주 조회하는 데이터(설정값, 게시물 목록 등)를 캐싱하고, 정적 자산은 CDN 또는 브라우저 캐시를 활용한다.
페이지 경험 지표를 개선했다고 해서 즉시 검색 순위가 올라가지는 않는다. Google의 크롤러가 페이지를 다시 방문해야 하고, 새로운 필드 데이터가 충분히 모여야 하기 때문이다. 보통 2~4주가 걸린다. 그 동안에는 Google Search Console의 "요청" > "URL 검사"에서 "Google에 등록" 버튼을 눌러서 빠르게 재크롤링을 유도할 수 있다.
대규모 개선라면 사이트맵을 최신 상태로 유지하고, 중요 페이지부터 우선 최적화한다. Search Console의 "성능" 탭에서 클릭 많은 페이지 순서로 정렬하면, 가장 영향력 있는 페이지가 뭔지 알 수 있다.
페이지 경험은 단순한 기술 점수가 아니라 실제 사용자 만족도를 반영하는 신호다. 이미지 최적화, 서버 응답 시간 단축, 레이아웃 안정화 같은 작은 개선들이 모여서 검색 순위 회복이라는 큰 효과를 만든다는 점을 잊지 말자. 이 글의 Core Web Vitals 세 지표와 최적화 코드를 참고해서, 먼저 자신의 사이트를 Google Search Console에서 분석하고, 실제 문제가 있는 페이지부터 개선해나가면, 한두 달 안에 눈에 띄는 순위 상승을 경험할 수 있을 것이다.