블로그 속도 점검: LCP·INP·CLS의 뜻과 개선 방법

블로그 속도를 점검할 때는 PageSpeed Insights에서 모바일·데스크톱 결과를 나누어 보고, LCP·INP·CLS로 로딩·반응성·화면 안정성을 확인하면 됩니다. 성능 점수 하나만 보기보다 실제 방문자 데이터와 실험실 진단을 구분하고, 나쁜 지표의 원인부터 하나씩 수정하는 것이 좋습니다.

LCP·INP·CLS는 무엇인가요?

코어 웹 바이탈(Core Web Vitals)은 구글이 웹페이지의 사용자 경험을 살펴보는 핵심 지표 묶음입니다. 현재 핵심 지표는 아래 세 가지입니다. 셋 모두 값이 낮을수록 좋지만, 측정하는 대상과 단위는 다릅니다.

구글의 웹 바이탈 안내는 모바일과 데스크톱을 구분한 75번째 백분위수로 평가하도록 설명합니다. 이는 가장 빠른 한 번의 결과가 아니라, 상당수 방문자가 경험하는 수준을 살펴보는 기준입니다.

예를 들어 글은 빨리 보이는데 메뉴를 누른 뒤 반응이 늦을 수 있고, 버튼은 잘 눌리는데 광고가 나타날 때 본문이 밀릴 수도 있습니다. ‘느리다’는 인상만으로 이미지 압축부터 반복하기보다 어느 경험이 나쁜지 먼저 구분해야 합니다.

PageSpeed Insights에서 검사하기

1. 로그인 없이 열리는 공개 글 주소를 준비합니다. 관리자·미리보기 주소는 제외합니다.
2. PageSpeed Insights에 주소를 입력하고 분석을 실행합니다.
3. 모바일 결과에서 실제 사용자 경험과 성능 문제 진단을 나누어 읽습니다.
4. 데스크톱 결과도 확인하고, 대상 URL·검사 날짜·기기 구분·나쁜 지표·주요 진단을 기록합니다.

처음에는 최근 글 하나만 검사하기보다 대표적인 글 형식별로 주소를 골라 두는 편이 좋습니다. 예를 들어 일반 설명 글, 이미지가 많은 글, 표나 코드가 있는 글을 선택하면 공통 템플릿 문제와 특정 콘텐츠의 문제를 비교하기 쉽습니다. 실제 존재하는 형식만 고르면 됩니다.

결과 화면에 표시된 URL이 원래 입력한 주소와 다른지도 확인하세요. 리디렉션 뒤의 페이지를 검사했다면 이후 비교도 같은 최종 주소로 해야 합니다. 같은 조건을 기록하는 목적은 점수를 좋게 보이게 하는 것이 아니라 변경 효과를 판단하는 데 있습니다.

실제 방문자 데이터와 성능 점수 구분하기

실제 사용자 데이터는 크롬 사용자 경험 보고서(CrUX, Chrome User Experience Report)의 최근 28일 자료를 바탕으로 합니다. 표본이 부족하면 사이트 전체 출처 단위 데이터가 표시되거나 자료가 없을 수 있습니다. 반면 실험실 진단은 Lighthouse가 시뮬레이션 환경에서 해당 주소를 분석한 결과입니다. PageSpeed Insights 공식 설명에서 두 데이터의 차이를 확인할 수 있습니다.

따라서 ‘성능 점수 90점’과 ‘실제 사용자 코어 웹 바이탈 통과’는 같은 판정이 아닙니다. 실제 사용자 영역이 이 URL의 데이터인지, 사이트 전체 출처 데이터인지도 확인하세요. 자료가 없다는 표시 역시 빠르다는 인증이나 느리다는 판정으로 읽으면 안 됩니다.

예를 들어 이미지를 바꾼 직후 실험실 결과가 개선되어도, 최근 28일의 방문 경험에는 변경 전 기록이 함께 들어 있습니다. 즉시 확인할 항목은 수정한 파일과 화면이 정상인지, 동일 조건의 재검사에서 개선 징후가 있는지입니다. 실제 사용자 추세는 이후 기간에 따로 살펴보세요.

LCP가 나쁘면 주요 콘텐츠가 늦는 이유부터

LCP 문제가 보이면 진단 결과에서 가장 큰 콘텐츠로 잡힌 요소가 무엇인지 먼저 확인합니다. 글 위의 대표 이미지가 원인일 수도 있지만 큰 제목이나 다른 콘텐츠일 수도 있습니다. 원인을 확인하지 않고 모든 이미지를 같은 방식으로 처리하지 마세요.

• 주요 이미지라면 실제 표시 크기에 비해 원본이 지나치게 크지 않은지 확인합니다.
• 적절한 크기·압축·형식으로 바꾸되, 글자나 세부 묘사가 필요한 이미지는 선명도를 함께 확인합니다.
• 첫 화면의 LCP 이미지에 지연 로딩이 걸려 로드가 늦어지는지 확인합니다. 화면 아래 이미지를 늦게 읽는 설정을 주요 이미지에 무조건 적용하지 않습니다.
• 서버 응답이나 렌더링을 막는 리소스가 지적됐다면 이미지 외의 원인도 조사합니다.

LCP 최적화 안내는 주요 이미지의 발견·전송·표시가 각각 지연될 수 있다고 설명합니다. 이미지 형식 변경이 필요한 경우에는 이미지를 WebP로 변환하는 방법을 참고할 수 있습니다. 형식 변경 후에도 원래 이미지가 계속 제공된다면 캐시와 실제 요청 파일을 확인해야 합니다.

INP가 나쁘면 클릭 뒤의 작업을 확인하기

INP는 버튼을 누른 뒤 화면이 다음으로 그려질 때까지의 반응성을 살펴봅니다. 긴 자바스크립트 작업이 브라우저의 메인 스레드를 오래 차지하면 입력 처리가 밀릴 수 있습니다. INP 최적화 안내는 입력 지연, 이벤트 처리, 화면 표시 지연을 나누어 원인을 살펴봅니다.

블로그 운영자라면 모바일에서 메뉴 열기, 검색, 목차 이동 같은 실제 동작부터 재현해 보세요. 어떤 동작에서 지연이 보이는지 기록하고, 해당 화면에서 동작하는 플러그인·위젯·외부 스크립트 중 불필요하거나 중복된 기능이 있는지 검토합니다.

플러그인을 무조건 많이 끄는 방법은 피하세요. 백업이나 테스트 환경을 준비하고 하나씩 바꿔야 어떤 변경이 영향을 주었는지 알 수 있습니다. 자바스크립트 지연 실행 설정을 켰다면 점수뿐 아니라 메뉴, 검색창, 동의 배너 등 필요한 기능이 실제로 작동하는지도 확인합니다.

CLS가 나쁘면 움직이는 구역의 공간 확보하기

이미지·광고·임베드가 나중에 들어오면서 본문을 밀면 읽던 위치나 누르려던 링크가 움직일 수 있습니다. CLS 최적화 안내는 이미지 크기 정보와 늦게 나타나는 콘텐츠의 공간 확보를 주요 점검 대상으로 제시합니다.

• 이미지의 실제 비율에 맞는 width·height 정보나 적절한 비율 공간을 제공합니다.
• 광고와 동영상 등 임베드가 들어갈 공간을 기기 크기에 맞게 미리 확보합니다.
• 광고가 반환되지 않을 때 확보한 공간을 갑자기 접어 다른 이동을 만들지 않는지 확인합니다.
• 글꼴이나 배너가 늦게 적용될 때 본문·버튼이 움직이는지도 살펴봅니다.

빈 공간을 줄이는 것과 레이아웃을 안정적으로 유지하는 것 사이에는 조정이 필요할 수 있습니다. 데스크톱에서 맞춘 광고 높이를 모바일에 그대로 적용하지 말고 실제 글을 열어 확인하세요. 본문 중간뿐 아니라 첫 화면과 화면 하단의 움직임도 함께 살펴보는 편이 좋습니다.

수정한 뒤 같은 조건으로 다시 확인하기

1. 변경 전 설정·파일과 검사 결과를 남깁니다.
2. 가장 영향이 큰 원인 하나를 선택해 수정합니다.
3. 필요한 캐시를 갱신하고 공개 페이지에서 변경된 리소스가 제공되는지 확인합니다.
4. 같은 URL과 기기 구분으로 재검사하고, 실제 메뉴·이미지·광고·본문을 확인합니다.
5. 기능이 깨졌거나 다른 지표가 악화되면 변경을 되돌리고 원인을 다시 좁힙니다.

재검사 수치가 조금 달라졌다는 이유만으로 효과를 확정하지 마세요. 전후 기록과 반복해서 나타나는 문제를 함께 보고, 그다음 변경으로 넘어가는 것이 좋습니다. 점수만 높이는 설정 때문에 독자가 필요한 기능을 사용할 수 없다면 좋은 개선이라고 보기 어렵습니다.