웹페이지가 빨리 열렸는데도 검색 방문자는 버튼을 누르다 지치고, 글을 읽다 화면이 미끄러지듯 움직인다면 무슨 일이 벌어진 걸까요? 범인은 대개 보이지 않는 곳에서 일하는 세 명의 직원입니다.
바로 LCP, INP, CLS입니다. 이름은 시험 문제 같지만 뜻은 간단합니다. 얼마나 빨리 보이는지, 얼마나 빨리 반응하는지, 화면이 얼마나 얌전히 있는지를 재는 점수입니다.
페이지의 첫인상은 2.5초 안에 결정됩니다
LCP는 화면에서 가장 큰 내용이 나타나는 데 걸린 시간입니다. 보통 첫 화면의 큰 사진, 제목 묶음, 대표 영상 영역이 여기에 해당합니다.
구글은 방문자의 75%가 LCP 2.5초 이하를 경험하면 좋은 상태로 봅니다. 4초를 넘으면 나쁜 상태로 분류됩니다. 식당에 들어갔는데 메뉴판을 받기까지 4초가 아니라 40초 걸리는 느낌이라고 생각하면 이해가 쉽습니다.
여기서 의외의 사실이 있습니다. 서버가 빠르다고 LCP가 자동으로 좋아지지는 않습니다. 큰 사진이 늦게 내려오거나, 복잡한 디자인 파일이 화면 표시를 막으면 서버가 제시간에 도착해도 브라우저는 멀뚱히 기다립니다.
LCP가 느려지는 흔한 이유
- 용량이 큰 대표 이미지
- 첫 화면에서 늦게 불러오는 글꼴
- 화면 표시를 막는 디자인 파일
- 필요 이상으로 많은 추적용 스크립트
- 느린 서버 응답과 먼 서버 위치
개선의 첫 단추는 가장 큰 이미지부터 살피는 일입니다. 이미지 크기를 실제 표시 크기에 맞추고, 최신 형식으로 줄이며, 첫 화면에 꼭 필요한 자료만 먼저 불러오세요.
버튼을 눌렀는데 침묵하는 페이지는 신뢰를 잃습니다
INP는 방문자가 클릭하거나 입력한 뒤 화면이 반응할 때까지의 시간입니다. 예전의 첫 입력 지연 점수와 달리, 방문 중 일어난 여러 상호작용을 살펴 전체 반응성을 판단합니다.
구글의 기준에서 INP 200밀리초 이하는 좋고, 500밀리초를 넘으면 나쁩니다. 200밀리초는 눈 깜빡임보다 짧은 순간이라, 버튼을 눌렀을 때 거의 즉시 반응하는 느낌입니다.
반대로 자바스크립트가 너무 많은 일을 한꺼번에 처리하면 버튼은 눌렸지만 페이지는 회의 중인 사람처럼 잠시 말을 잃습니다. 메뉴 열기, 장바구니 갱신, 검색 결과 표시가 모두 늦어질 수 있습니다.
INP를 낮추는 현실적인 방법
- 사용하지 않는 스크립트 제거
- 클릭 직후 실행할 일을 작게 나누기
- 화면 밖 내용은 늦게 그리기
- 무거운 계산은 별도 작업으로 보내기
- 큰 화면 갱신을 한 번에 하지 않기
특히 첫 화면이 뜬 뒤에도 스크립트가 계속 실행되는지 확인해야 합니다. 페이지가 보인다는 것은 일이 끝났다는 뜻이 아니라, 브라우저가 잠깐 숨을 돌렸다는 뜻일 수 있습니다.
화면이 갑자기 움직이면 방문자의 클릭도 빗나갑니다
CLS는 화면에 보이던 내용이 예고 없이 얼마나 움직였는지를 나타냅니다. 글을 읽는데 광고가 끼어들어 문장이 아래로 밀리거나, 결제 버튼이 갑자기 이동하는 장면이 대표적인 사례입니다.
CLS는 시간 단위가 아니라 점수로 표시됩니다. 0.1 이하가 좋고, 0.25를 넘으면 나쁜 상태입니다. 점수가 작아 보여도 사람의 손가락은 생각보다 정확해서, 버튼 몇 픽셀만 움직여도 엉뚱한 것을 누를 수 있습니다.
가장 흔한 원인은 크기를 미리 정하지 않은 이미지와 광고입니다. 브라우저가 빈자리를 먼저 만들지 않으면 이미지가 도착하는 순간 주변 내용이 줄줄이 밀립니다. 온라인 줄다리기에서 갑자기 상대가 한 명 더 들어오는 셈입니다.
CLS를 막는 기본 습관
- 이미지와 영상의 가로세로 공간을 미리 예약하기
- 광고와 삽입 자료의 영역을 고정하기
- 화면 위쪽에 새 내용을 갑자기 넣지 않기
- 글꼴이 바뀌어도 줄바꿈이 크게 달라지지 않게 하기
- 클릭 직전 버튼 주변에 움직이는 요소를 두지 않기
서치콘솔의 점수는 내 컴퓨터의 시험 점수가 아닙니다
서치콘솔의 코어 웹 바이탈 보고서는 실제 방문자의 사용 기록을 바탕으로 합니다. 구글의 크롬 사용자 경험 보고서에서 익명으로 모은 자료를 사용하므로, 내 노트북에서 한 번 빠르게 열린 결과와 다를 수 있습니다.
보고서는 모바일과 데스크톱을 나누어 보여줍니다. 또 비슷한 구조의 페이지를 URL 그룹으로 묶고, 그 그룹에서 가장 낮은 상태를 전체 상태로 표시합니다.
예를 들어 LCP는 좋지만 CLS가 나쁘면 그 페이지 그룹은 나쁜 상태가 됩니다. 세 과목 중 한 과목만 낙제해도 평균 점수가 마음 편하지 않은 것과 같습니다.
보고서에 보이는 숫자는 모든 페이지의 완전한 목록도 아닙니다. 색인된 URL 가운데 충분한 실제 방문 자료가 있는 페이지와 대표 그룹을 보여주는 방식입니다. 자료가 부족하면 페이지 단위가 아니라 사이트 주소 전체에 가까운 범위로 묶일 수도 있습니다.
따라서 보고서에서 나쁜 URL 하나를 발견했다고 곧바로 그 페이지 하나만 고치면 안 됩니다. 같은 틀을 쓰는 상품 페이지, 글 페이지, 게시판 페이지가 함께 영향을 받을 수 있기 때문입니다.
혼자 고칠 때 가장 많이 막히는 지점
직접 해결하려는 사람은 먼저 무엇을 줄여야 할지부터 막힙니다. 사진을 줄이면 화질이 떨어지고, 스크립트를 지우면 문의 창이나 결제 기능이 사라질 수 있습니다. 디자인 파일을 늦게 불러오면 화면이 잠시 맨얼굴로 나타날 수도 있습니다.
또 하나의 어려움은 실험실 측정과 실제 방문자 자료가 서로 다르다는 점입니다. 속도가 느린 휴대전화, 지하철의 불안정한 통신, 특정 지역의 서버 거리까지 실제 환경은 아주 다양합니다.
서치콘솔은 문제가 있다는 사실을 알려주지만, 어떤 코드 한 줄을 지워야 하는지까지 대신 결정하지는 않습니다. 페이지 속도 측정 도구는 원인 후보를 보여주지만, 그 후보가 사업에 필요한 기능인지 판단하는 일은 사람의 몫입니다.
이때 원인 후보를 확인하는 것과 게시물의 검색 관련 설정을 점검하는 일은 나눠 볼 수 있습니다. SOHO SEO의 Page experience는 HTTPS 상태와 선택적으로 등록한 PageSpeed Insights 키를 이용한 모바일 성능 점수를 확인하고, Post SEO checklist는 게시물별 SEO 점수와 항목별 개선 안내를 보여 주며 저장 후 다시 점검합니다.
따라서 LCP·INP·CLS의 원인을 자동으로 고친다고 보기보다, 측정 결과와 게시물 설정을 함께 확인하는 워드프레스 관리 항목으로 이해하는 편이 정확합니다. 코드나 기능을 실제로 바꿀지는 사이트 운영자가 판단해야 합니다.
그래서 해결 순서는 점수가 가장 낮은 그룹을 고르고, 대표 URL을 따로 검사한 뒤, 같은 틀의 여러 페이지에서 문제가 반복되는지 확인하는 방식이 안전합니다.
- 모바일과 데스크톱을 따로 확인합니다.
- LCP, INP, CLS 중 가장 나쁜 항목을 고릅니다.
- 대표 URL을 개별 측정합니다.
- 이미지, 스크립트, 광고, 글꼴을 차례로 살핍니다.
- 수정 뒤 실제 자료가 갱신될 때까지 추이를 봅니다.
수정 직후 서치콘솔 숫자가 바로 바뀌지 않아도 이상한 일이 아닙니다. 실제 방문 자료가 쌓이고 보고서가 갱신되는 데 시간이 필요하기 때문입니다. 웹사이트도 사람처럼 한 번 운동했다고 다음 날 바로 선수가 되지는 않습니다.
SOHO SEO로 워드프레스 점검 항목 이어 보기
측정값을 고치는 동안 검색 노출과 연결되는 워드프레스의 기술·구조 요소도 따로 관리할 수 있습니다. SOHO SEO는 대표 이미지의 너비·전체 픽셀 수·화면 비율을 게시물 편집 화면에서 확인하고, Article 구조화 데이터를 자동으로 출력하며 제목·이미지·작성자·날짜 등의 설정 상태를 확인합니다. Page experience에서는 HTTPS 상태와 선택적으로 등록한 PageSpeed Insights 키를 이용한 모바일 성능 점수를 확인할 수 있습니다.
사이트맵과 공개 범위를 정리해야 한다면 일반 XML 사이트맵과 Google News 사이트맵을 켜거나 끌 수 있고, 날짜·작성자·태그·검색 결과 및 선택한 분류 보관 페이지에는 noindex를 적용할 수 있습니다. 주소가 바뀐 뒤에는 301·302·410 연결과 404 발생을 관리하고, 게시물에서는 내부 링크와 외부 링크 후보를 찾아 선택하거나 적용할 수 있습니다. 이 기능들은 코어 웹 바이탈 수치를 대신 고치는 기능이 아니라, 성능 점검과 함께 살펴볼 워드프레스 기술·구조 관리 항목입니다.
검색 노출을 위해 점수보다 먼저 볼 것
코어 웹 바이탈은 검색 순위를 결정하는 유일한 시험지가 아닙니다. 구글은 좋은 콘텐츠, 검색 의도에 맞는 답, 모바일 사용성 같은 여러 신호를 함께 봅니다.
다만 속도가 느리고 화면이 흔들리면 방문자가 내용을 읽기 전에 떠날 가능성이 커집니다. 그러면 좋은 글을 써도 실제 방문자에게 도착하기 전에 문이 닫히는 셈입니다.
가장 좋은 목표는 점수판을 초록색으로 만드는 데서 끝나지 않습니다. 방문자가 기다리지 않고, 잘못 누르지 않고, 읽던 위치를 잃지 않게 만드는 것입니다.
LCP는 먼저 보여주고, INP는 바로 반응하고, CLS는 가만히 있는 페이지를 만드는 일입니다. 이 세 가지를 차례로 점검하면 검색 노출을 돕는 기술 개선과 방문자의 편안한 경험을 함께 챙길 수 있습니다.
자주 묻는 질문
Q. 코어 웹 바이탈이 나쁘면 구글 검색에서 바로 사라지나요?
A. 코어 웹 바이탈은 여러 검색 신호 중 하나이며, 나쁘다고 페이지가 즉시 사라지는 것은 아닙니다. 다만 비슷한 품질의 페이지가 경쟁할 때 사용자 경험이 좋은 페이지가 유리할 수 있습니다.
Q. 서치콘솔에 자료가 없으면 사이트에 문제가 있는 건가요?
A. 꼭 그렇지는 않습니다.
사이트가 새롭거나 실제 방문 자료가 충분하지 않으면 보고서에 데이터가 나오지 않을 수 있습니다. 개별 URL은 별도의 속도 측정 도구로 확인할 수 있습니다.
Q. 모바일 점수와 데스크톱 점수가 다른 이유는 무엇인가요?
A. 기기의 처리 속도와 통신 환경이 다르기 때문입니다. 특히 모바일은 느린 기기와 불안정한 통신의 영향을 더 크게 받을 수 있으므로 두 환경을 따로 확인해야 합니다.
Q. 내 사이트에서는 무엇부터 고쳐야 하나요?
A. 먼저 모바일과 데스크톱 중 방문이 많은 환경을 확인하고, 가장 나쁜 지표가 무엇인지 찾으세요. 그다음 같은 틀을 쓰는 페이지가 많은 문제부터 고치는 편이 효과적입니다.
Q. 이 문제를 도구로 쉽게 해결할 수 있나요? 어떤 도구를 쓰면 되나요?
A. 서치콘솔은 실제 방문자의 문제 그룹을 찾는 데 쓰고, 개별 페이지의 원인 분석에는 페이지 속도 측정 도구와 브라우저 개발자 도구를 함께 쓰는 것이 좋습니다. 도구가 원인을 알려줘도 기능을 지워도 되는지는 직접 판단해야 합니다.
Q. 코어 웹 바이탈을 점검하면서 워드프레스의 검색 구조도 관리하려면 어떻게 해야 하나요?
A. 워드프레스에서는 성능 수치와 검색 구조를 나눠 확인하는 편이 안전합니다.
SOHO SEO는 대표 이미지의 너비·픽셀 수·화면 비율을 확인하고, Article 구조화 데이터를 출력하며 제목·이미지·작성자·날짜 설정 상태를 보여 줍니다. 사이트맵, noindex, 404와 리디렉션까지 관리해야 한다면 각 기능의 범위에 맞춰 별도로 점검할 수 있습니다.
워드프레스 관련 플러그인
