PageSpeed Insights로 블로그 LCP 원인 찾아 직접 고친 순서
구글 서치콘솔에서 "코어 웹 바이탈 문제" 알림이 왔을 때, PSI(pagespeed.web.dev)를 열면 권고 목록이 쭉 나열돼요. "이미지를 WebP로 바꾸세요", "렌더 블로킹을 제거하세요"처럼요. 근데 그 목록을 보면서 "그래서 내 블로그 LCP는 정확히 어디서 막힌 거야?"라는 질문에 답이 안 나오면, 권고 전부를 닥치는 대로 해도 LCP가 안 줄어드는 상황이 생깁니다.
이 글은 그 질문에 답하는 순서를 따라가는 거예요. 기준 환경은 대표이미지를 JPG 원본으로 올리고 방문자 카운터·소셜 공유 위젯·무료 채팅 플러그인이 켜진 티스토리 블로그입니다. 보고서를 처음 열 때부터 수정 후 서치콘솔 확인까지, 그 흐름 그대로요.
LCP 구간을 이해해야 권고 목록이 보여요
먼저 개념 하나를 잡고 가야 해요. LCP(Largest Contentful Paint)는 단순히 "느리다/빠르다"가 아니라, 구글이 네 구간으로 쪼개서 보여줍니다.
TTFB → 리소스 로드 지연 → 리소스 로드 시간 → 요소 렌더 지연, 이 순서예요.
이 네 구간을 모르면 PSI 권고 목록이 그냥 할 일 목록처럼 보여요. 알고 나면 각 경고가 어느 구간의 문제인지 매핑이 되고, 어디를 먼저 고쳐야 LCP에 실제 영향이 생기는지 판단이 됩니다.
LCP 기준값도 이 흐름에서 봐야 해요. 구글 기준으로 2.5초 이하면 "Good(양호)", 2.5~4초는 "Needs Improvement(개선 필요)", 4초 초과는 "Poor(나쁨)"이에요. 이 기준은 방문자 100명 중 75번째 방문자 기준으로 적용돼요. 방문자의 75%가 2.5초 이내 LCP를 경험해야 비로소 "Good" 판정이 나온다는 뜻이죠.
2024년 3월 FID가 INP로 교체되면서 현재 코어 웹 바이탈은 LCP·INP·CLS 세 항목이에요. LCP의 2.5초 기준은 그대로 유지 중입니다.
보고서를 열면 두 개만 먼저 확인해요
pagespeed.web.dev에서 블로그 글 URL을 입력하면 모바일/데스크톱 두 결과가 나와요. 블로그는 모바일 방문자가 많고 구글이 모바일 우선 색인을 적용하니, 모바일 탭을 먼저 봐야 합니다.
보고서 위쪽에 필드 데이터(Field Data) 와 실험실 데이터(Lab Data) 두 영역이 있어요. 필드 데이터는 실제 크롬 사용자 28일치 데이터고, 구글 검색 순위에 직접 반영되는 값이에요. 실험실 데이터는 Lighthouse가 시뮬레이션한 값이라, 수정 전후를 즉시 비교할 때 쓰기 좋습니다.
여기서 확인할 건 두 가지예요.
첫 번째는 LCP 요소(Largest Contentful Paint element) — 보고서 "진단" 섹션에서 찾아요. 대표이미지 <img> 태그인지, 텍스트 블록인지, 플러그인이 삽입한 영역인지에 따라 수정 방향이 달라집니다.
두 번째는 LCP 하위 기여 지표 — 네 구간 중 어디서 시간이 많이 소비됐는지 막대 형태로 보여줘요. 이게 수정 우선순위를 정하는 핵심 단서예요. 권고 목록을 보기 전에 이 구간 데이터를 먼저 확인하세요.
이 환경에서 각 구간이 어떻게 보이나
JPG 원본을 올리고 렌더 블로킹 플러그인이 3개 켜진 티스토리 블로그라면 PSI에서 어떤 패턴이 나타나는지 따라가 볼게요.
TTFB 구간부터 봅니다. PSI에서 "서버 응답 시간 단축" 항목이 빨간색이나 주황색이면 TTFB 문제예요. 기준은 0.8초 이하입니다. 티스토리 무료 플랜이라면 이 구간을 크게 줄이기 어려운 경우가 많아요. 이럴 때는 해당 경고를 인지하고 일단 넘어가세요. 나머지 구간을 먼저 최적화해서 전체 LCP가 2.5초 안으로 들어오는지 확인하는 게 현실적인 접근입니다.
리소스 로드 지연 구간에서는 렌더 블로킹 문제가 드러납니다. "렌더 블로킹 리소스 제거" 경고에 방문자 카운터, 소셜 공유 위젯, 무료 채팅 플러그인 스크립트 파일들이 나열돼 있다면 이 구간이 늘어난 거예요. 이 스크립트들은 <head>에서 HTML 파싱을 막기 때문에 브라우저가 대표이미지를 늦게 발견하게 됩니다. 이미지를 WebP로 바꿔도 발견 자체가 늦으면 LCP 개선 효과가 반감돼요.
리소스 로드 시간 구간에서는 이미지 용량 문제가 보입니다. "차세대 형식으로 이미지 제공" 또는 "이미지 크기 적절히 조정" 경고가 뜨면 여기에 해당해요. 2~3MB짜리 JPG 원본을 그대로 올리면 브라우저가 파일 전체를 내려받아야만 화면에 그릴 수 있거든요. 블로그 본문 최대 너비가 800px인데 2400px 이미지를 올린 경우도 같은 구간 문제입니다.
구간 순서대로 수정해요 🔧
원인 구간이 보이면 수정 순서가 자연스럽게 나와요. 이 환경 기준으로는 이미지 용량 → 이미지 로드 힌트 → 렌더 블로킹 제거 순이 효과 대비 난이도가 낮아요.
이미지 용량과 포맷 먼저. 대표이미지를 WebP 또는 AVIF로 변환하고, 실제 표시 크기에 맞게 리사이즈합니다. squoosh.app 같은 무료 도구를 쓰면 브라우저에서 바로 변환할 수 있어요. 워드프레스라면 ShortPixel이나 Smush 같은 이미지 최적화 플러그인이 업로드 시 자동 변환을 처리해 줍니다.
이미지 용량을 줄인 뒤에 로드 힌트를 추가해요. PSI 진단에서 "이미지 요소가 fetchpriority 없이 지연 로드됨" 경고가 보이면, 대표이미지 <img> 태그에 fetchpriority="high" 속성을 추가하세요. 브라우저가 다른 리소스보다 먼저 이 이미지를 가져옵니다. loading="lazy" 속성이 LCP 이미지에 붙어 있다면 반드시 제거해야 해요. 워드프레스는 6.3 버전부터 대표 이미지에 fetchpriority="high"를 자동 적용해요. 버전이 낮다면 업데이트하거나 functions.php에서 직접 추가하면 됩니다. 티스토리는 HTML 편집 모드로 대표이미지 태그를 직접 수정하거나 스킨 편집에서 처리해야 해요.
마지막으로 렌더 블로킹을 줄여요. "렌더 블로킹 리소스 제거" 항목에 구체적인 파일 목록과 절감 예상 시간이 나와요. 0.5초 이상이면 우선순위를 높여서 처리하세요. <head> 안에 있는 비필수 스크립트에 defer 또는 async 속성을 추가하는 게 기본 처리예요. 티스토리라면 스킨 설정에서 실제로 쓰지 않는 위젯·플러그인을 제거하는 게 빠릅니다. 워드프레스라면 플러그인을 하나씩 비활성화하면서 PSI 실험실 데이터를 재측정하면 원인 플러그인을 특정할 수 있어요.
각 단계를 적용한 뒤 PSI에서 같은 URL을 다시 측정하세요. 실험실 데이터는 수정 즉시 반영되니까 빠르게 확인 가능합니다. 단, 서치콘솔의 "코어 웹 바이탈" 보고서에 뜨는 필드 데이터는 실제 방문이 충분히 쌓여야 갱신돼요. 서치콘솔에서 "수정 확인" 버튼을 누르고 나서 보통 2~4주 후에 상태가 바뀝니다.
PSI 점수가 올라도 LCP 달성과는 별개예요
수정 후에 PSI 점수 숫자를 보고 판단을 잘못 내리는 경우가 있어요.
PSI 점수(0~100)와 코어 웹 바이탈 LCP 달성 여부는 별개예요. 점수가 50점이어도 LCP가 2.5초 이하면 LCP 항목은 "Good"이고, 점수가 90점이어도 LCP가 3초라면 "Needs Improvement"고요. 구글 검색 순위에 반영되는 건 점수 숫자가 아니라 LCP·INP·CLS 각 항목의 달성 여부입니다.
블로그에서 PSI를 쓰는 목적은 점수를 올리는 게 아니라, 세 항목이 각각 기준치를 통과하는지 확인하는 거예요. 이 목표를 기준으로 보고서를 읽으면, 권고 목록 전부를 쫓지 않고도 LCP에 실제로 영향을 주는 지점만 골라낼 수 있습니다.
이 글이 도움이 됐나요?
여러분의 반응이 다음 글의 방향이 돼요
