코어 웹 바이탈 빨간불, 워드프레스 초보가 직접 고칠 수 있는 5가지

글 열 편쯤 올리고 뿌듯한 마음에 PageSpeed Insights를 돌렸는데, 모바일 성능 38점짜리 빨간 원이 뜨는 순간이 있어요. LCP, INP, CLS 같은 낯선 약어가 줄줄이 나오고, 이러다 검색에서 밀려나는 건 아닌지 덜컥 겁이 나죠. 먼저 답부터 드리면, 빨간 성능 점수가 곧바로 순위 폭락을 뜻하지는 않아요. 비전공자는 이미지 최적화, 캐시 플러그인, 크기 지정 같은 5가지만 손봐도 코어 웹 바이탈 빨간불을 벗어나는 경우가 많고, 그 이상은 멈춰도 괜찮아요. 아래에서 세 지표의 뜻부터 Claude Code에게 물어가며 고칠 때 흔히 터지는 실패, 그리고 어디서 손을 떼면 되는지까지 순서대로 정리했어요.

• 빨간 점수의 정체부터 확인하기
• LCP·INP·CLS, 세 글자씩 쉽게 풀기
• 측정 도구별로 뭘 보면 되는지
• 비전공자가 직접 고칠 수 있는 5가지
• Claude Code에게 물어가며 고칠 때 자주 터지는 실패
• 어디까지 손대고 어디서 멈출까
• 자주 하는 오해와 진실
• 참고자료

빨간 점수의 정체부터 확인하기

PageSpeed Insights 결과 화면에는 사실 시험지가 두 장 들어 있어요. 위쪽의 “실제 사용자 경험” 영역과 아래쪽의 0~100점 “성능” 점수예요.

위쪽은 크롬 사용자들이 내 사이트를 실제로 방문한 기록(필드 데이터)이에요. 최근 28일치를 모아, 방문 기록 중 75%가 기준을 넘는지로 합격 여부를 매겨요.

아래쪽 점수는 구글 서버가 느린 모바일 환경을 흉내 내 한 번 돌려본 실험 결과(랩 데이터)예요. 0~49점은 빨강, 50~89점은 주황, 90점 이상이 초록이에요.

여기서 중요한 사실이 하나 있어요. 구글이 검색 순위에 참고하는 건 위쪽 필드 데이터지, 아래쪽 성능 점수가 아니에요. 그래서 38점이라는 숫자만 보고 겁먹을 필요는 없어요.

그런데 막 시작한 블로그는 위쪽에 “데이터가 부족합니다”라고만 나오는 경우가 대부분이에요. 방문자가 충분히 쌓여야 필드 데이터가 생기기 때문이에요.

그럼 성능 점수는 무시해도 될까요? 그건 아니에요. 필드 데이터가 없는 동안에는 랩 점수와 아래 “진단” 목록이 어디가 느린지 알려주는 유일한 지도예요. 점수 자체보다 진단 항목을 읽는 용도로 쓰면 돼요.

LCP·INP·CLS, 세 글자씩 쉽게 풀기

코어 웹 바이탈은 “빨리 보이는가, 눌렀을 때 바로 반응하는가, 화면이 덜컥거리지 않는가” 세 가지를 재는 시험이에요. 기준은 아래 표처럼 정해져 있어요.

LCP가 느린 워드프레스 블로그는 원인이 대개 하나로 모여요. 휴대폰으로 찍은 3~5MB짜리 사진을 그대로 대표 이미지로 올린 경우예요. 첫 화면의 가장 큰 요소가 무거우면 나머지를 아무리 다듬어도 LCP가 잘 안 내려가요.

INP는 2024년 3월부터 예전 지표인 FID(First Input Delay)를 대신하게 됐어요. FID는 첫 클릭 한 번만 쟀는데, INP는 페이지에 머무는 동안의 반응 전체를 봐요. 슬라이더·팝업·채팅 위젯처럼 자바스크립트를 많이 쓰는 플러그인이 쌓이면 나빠지기 쉬워요.

참고로 PageSpeed Insights 랩 결과에는 INP 대신 TBT(Total Blocking Time)가 나와요. 실험실에서는 사람이 버튼을 누르지 않으니, 브라우저가 멈춰 있던 시간으로 대신 짐작하는 거예요.

CLS는 글을 읽으려는데 위에 광고나 이미지가 늦게 끼어들어 본문이 쑥 밀리는 현상이에요. 이미지에 가로·세로 크기가 없거나, 광고 자리를 미리 비워두지 않았을 때 주로 생겨요.

측정 도구별로 뭘 보면 되는지

도구가 많아 보이지만 역할은 “실제 방문자 기록을 보는 도구”와 “실험실에서 원인을 찾는 도구” 두 부류로 나뉘어요.

초보라면 PageSpeed Insights와 Search Console 두 개면 충분해요. GTmetrix와 WebPageTest는 “왜 이 파일이 늦게 뜨지?”처럼 원인을 깊게 파고들 때 꺼내 쓰는 돋보기예요.

모바일 점수가 데스크톱보다 30~40점씩 낮게 나오는 건 흔한 일이에요. 모바일 측정은 중급 휴대폰과 느린 4G 회선을 가정하고 CPU 속도까지 일부러 낮춰서 재기 때문이에요.

또 랩 점수는 같은 페이지도 잴 때마다 5~10점씩 흔들려요. 한 번 재고 일희일비하기보다 3번 재서 가운데 값을 기록해두면 수정 전후 비교가 훨씬 정확해져요.

재측정은 시크릿 창에서 하는 게 좋아요. 관리자로 로그인한 상태에서는 캐시가 적용되지 않는 플러그인이 많아서, 실제 방문자보다 느리게 보이는 착시가 생기거든요.

비전공자가 직접 고칠 수 있는 5가지

코드를 몰라도 관리자 화면과 플러그인만으로 손댈 수 있는 것부터 효과가 큰 순서로 골랐어요. 위에서부터 하나씩 하고, 매번 재측정해서 어떤 게 효과가 있었는지 기록해두세요.

이 5가지를 순서대로 적용하면, 모바일 LCP 5~6초대였던 페이지가 2~3초대까지 내려오는 흐름이 흔해요. 1번과 2번만으로 변화의 대부분이 나오는 경우도 많아요.

“대표 이미지 하나 바꿨는데 점수가 그대로예요”라는 질문도 자주 나와요. 이럴 땐 캐시가 예전 페이지를 계속 내주고 있을 가능성이 커요. 캐시 플러그인에서 “전체 캐시 삭제”를 누른 뒤 다시 재보세요.

Claude Code에게 물어가며 고칠 때 자주 터지는 실패

진단 항목은 “렌더링 차단 리소스 제거”, “사용하지 않는 자바스크립트 줄이기”처럼 외계어로 나와요. 이걸 혼자 해석하기보다 Claude Code에게 통째로 넘겨 번역과 우선순위를 맡기면 훨씬 수월해요.

효과가 좋았던 질문 패턴은 이렇게 “상황 + 결과 + 내 수준”을 같이 주는 형태예요.

• “워드프레스 블로그고 코딩은 몰라. PageSpeed Insights 진단 결과를 붙여 넣을게. 플러그인 설정만으로 고칠 수 있는 것과 코드 수정이 필요한 것으로 나눠서 효과 큰 순서로 알려줘.”
• “LCP 요소가 이 이미지래. 왜 느린지, 내가 관리자 화면에서 바꿀 수 있는 설정이 뭔지 단계별로 알려줘.”
• “이 코드를 차일드 테마에 넣으라는데, 넣었다가 사이트가 깨지면 어떻게 되돌리는지부터 먼저 알려줘.”

마지막 질문처럼 되돌리는 법을 먼저 묻는 습관이 중요해요. 속도 개선에서 흔한 실패는 대부분 “한꺼번에 여러 개를 켰다가 어디서 깨졌는지 모르는” 상황에서 생기거든요.

가장 자주 나오는 실패 사례는 이런 것들이에요.

• 캐시 플러그인 2개 동시 사용: 서로 캐시를 덮어써서 수정한 글이 반영되지 않거나 페이지가 하얗게 뜨기도 해요.
• 자바스크립트 지연 실행: 점수는 오르는데 모바일 햄버거 메뉴가 안 열리거나 광고가 사라져요.
• CSS 결합·압축: 파일을 합치는 과정에서 순서가 꼬여 레이아웃이 깨지는 일이 잦아요.
• functions.php 직접 수정: 따옴표 하나만 빠져도 사이트 전체가 흰 화면이 돼요.

Claude Code가 준 설정값도 내 사이트에 꼭 맞는다는 보장은 없어요. “점수가 5점 올랐는데 메뉴가 안 열린다”면 그 설정은 과감히 끄는 게 맞아요. 방문자에게는 점수보다 작동하는 메뉴가 훨씬 중요하니까요.

어디까지 손대고 어디서 멈출까

속도 작업의 함정은 끝이 없다는 거예요. 60점을 80점으로 올리는 건 설정 몇 개로 되지만, 80점에서 95점으로 가려면 테마를 갈아엎거나 서버를 바꾸는 수준의 일이 필요해져요.

비전공자라면 아래 영역은 포기해도 괜찮아요.

• 애드센스·애널리틱스 스크립트: 진단에 “타사 코드의 영향”으로 계속 떠도 수익과 분석에 필요한 비용이에요. 자리 확보로 CLS만 막으면 충분해요.
• 모바일 100점: 광고가 붙은 블로그에서 모바일 90점 이상은 현실적으로 어려워요.
• 테마 내부 구조: 무거운 페이지 빌더 테마를 뜯어고치기보다, 나중에 가벼운 테마로 바꿀지 결정하는 게 낫어요.
• 서버 응답 속도 근본 개선: 캐시로도 느리면 설정 문제가 아니라 호스팅 선택의 문제라, 요금제·업체 변경을 따로 판단해야 해요.

이 정도가 채워졌다면 속도 작업에 쓰던 시간을 글쓰기로 돌리는 게 훨씬 이득이에요. 코어 웹 바이탈은 비슷한 품질의 글끼리 겨룰 때 작용하는 보조 신호라, 글의 질과 검색 의도 충족이 여전히 먼저예요.

대신 한 달에 한 번, 새 플러그인을 설치한 직후에는 꼭 다시 재보세요. 속도는 한 번 고쳤다고 끝나지 않고, 플러그인 하나가 조용히 점수를 되돌려 놓는 일이 흔하거든요.

자주 하는 오해와 진실

성능 점수가 100점이어야 검색 순위가 오르는 게 맞나요?

아니에요. 순위에 참고되는 건 실제 방문자 기록인 필드 데이터의 합격 여부이고, 랩 점수 100점은 필요 조건이 아니에요. 세 지표가 “좋음” 구간에 들어오면 그 이상의 점수 차이는 순위에 거의 영향이 없어요.

캐시 플러그인은 여러 개 깔면 더 빨라진다던데?

반대예요. 캐시 플러그인끼리 충돌해서 수정 사항이 반영되지 않거나 페이지가 깨지는 원인이 돼요. 이미지 최적화 플러그인 1개와 캐시 플러그인 1개 조합이 가장 안전해요.

애드센스를 달면 코어 웹 바이탈이 망한다던데?

랩 점수는 어느 정도 내려가지만 망가질 정도는 아니에요. 가장 큰 문제는 광고가 늦게 끼어들며 생기는 CLS인데, 광고 자리에 최소 높이를 지정하면 상당 부분 막을 수 있어요.

FID만 기준에 맞추면 된다던데?

예전 정보예요. FID는 2024년 3월에 INP로 교체됐어요. 지금은 첫 클릭뿐 아니라 머무는 동안의 모든 반응 속도를 보기 때문에, 무거운 스크립트를 줄이는 쪽으로 관리해야 해요.

점수를 고치면 Search Console에 바로 반영되는 게 맞나요?

바로는 아니에요. 필드 데이터는 최근 28일치를 모아서 보여주기 때문에 개선 효과가 보고서에 나타나기까지 보통 4주 가까이 걸려요. 보고서의 “수정 결과 확인”을 누르고 기다리면 돼요.

참고자료

• web.dev – Web Vitals: 구글이 정리한 LCP·INP·CLS의 정의와 합격 기준
• Google 검색 센터 – Core Web Vitals 및 Google 검색결과 이해하기: 코어 웹 바이탈이 검색에 반영되는 방식
• Search Console 도움말 – Core Web Vitals 보고서: 보고서 읽는 법과 수정 결과 확인 절차
• PageSpeed Insights: 글 주소를 넣고 필드·랩 데이터를 직접 측정하는 공식 도구

빨간 점수를 처음 보면 사이트 전체가 잘못된 것 같아 막막하지만, 알고 보면 확인할 건 세 가지뿐이에요. 빨리 보이는지(LCP), 바로 반응하는지(INP), 덜컥거리지 않는지(CLS)요. 정리하면, 이미지 줄이기와 캐시 플러그인 1개로 시작해 첫 화면 이미지, 광고 자리, 안 쓰는 플러그인 순서로 하나씩 손보는 흐름을 권해요. 설정은 한 번에 하나만 바꾸고, 메뉴나 광고가 깨지면 점수보다 작동을 먼저 챙기세요. 체크리스트가 채워졌다면 거기서 멈추고 좋은 글을 쌓는 데 시간을 쓰는 게, 결국 검색과 애드센스 모두에 더 도움이 돼요.

함께 보면 좋은 글

• 터미널 기초, 30분이면 달라지는 Claude Code 첫 실행 준비
• 워드프레스 테마 속도, 테마만 바꾸면 정말 빨라질까?
• 워드프레스 테마 추천, 개발자들이 첫 테마로 말리는 유형부터 알아야 해요