[구글 SEO 20] 페이지 속도와 순위, Core Web Vitals

지금까지 크롤, 색인, 콘텐츠, 권위, 채널을 다뤘다. 이제 색인이 잘된 뒤의 순위 싸움에서 작동하는 요소, 페이지 속도를 이야기할 차례다. 구글은 사용자 경험 지표를 순위에 반영하는데, 그 핵심이 Core Web Vitals다. 다만 이걸 언제 신경 써야 하는지 순서를 아는 게 중요하다. 이번 편은 그 이야기다.

미리 결론을 말하면, 페이지 속도는 중요하지만 신생 사이트의 첫 번째 과제는 아니다. 색인조차 안 되는 상황에서 속도부터 최적화하는 건 순서가 틀렸다. 이 우선순위 감각을 갖고 읽어주길 바란다.

1. Core Web Vitals란 무엇인가

Core Web Vitals는 구글이 정한 사용자 경험의 핵심 지표 세 가지다. 로딩 속도, 상호작용 반응성, 시각적 안정성을 각각 측정한다. 사용자가 페이지를 열었을 때 얼마나 빨리 보이고, 얼마나 빨리 반응하고, 얼마나 안정적으로 보이는지를 수치화한 것이다.

구글은 이 지표들을 순위 신호로 쓴다고 공식적으로 밝혔다. 다만 이건 결정적 신호가 아니라 동점자를 가르는 요소에 가깝다. 콘텐츠 품질이나 관련성이 먼저고, 그게 비슷한 페이지들 사이에서 속도가 나은 쪽이 조금 유리해지는 방식이다. 속도가 콘텐츠를 이기지는 못한다.

그래서 Core Web Vitals는 콘텐츠와 색인이 먼저 갖춰진 다음의 마무리 작업이다. 순위 경쟁에 들어간 페이지들 사이에서 마지막 한 끗을 다투는 단계에서 의미가 커진다. 신생 사이트가 아직 색인 단계에서 씨름하고 있다면, 여기에 힘을 쏟는 건 이르다.

한 가지 배경을 더 주면, 구글이 속도를 순위에 넣은 건 사용자가 느린 페이지를 싫어하기 때문이다. 결국 사용자 경험을 대신 재는 지표라, 이걸 개선하는 건 검색을 위해서만이 아니라 실제 방문자를 위해서이기도 하다. 순위는 부수 효과고 진짜 목적은 쾌적한 경험이다.

조금 더 덧붙이면, Core Web Vitals는 페이지 단위가 아니라 사이트 전반의 경향으로도 평가된다. 몇몇 페이지만 빠르고 대부분 느리면 좋은 인상을 못 준다. 그래서 개별 페이지를 하나씩 고치기보다, 공통 템플릿이나 전역 자원처럼 여러 페이지에 걸친 요소를 개선하는 게 효율적이다. 한 번 고쳐 여러 페이지가 함께 빨라지는 지점을 노린다.

2. LCP, 로딩 속도

첫 번째 지표 LCP는 가장 큰 콘텐츠 요소가 화면에 그려지는 시점을 잰다. 보통 대표 이미지나 큰 텍스트 블록이 그 대상이다. 사용자가 체감하는 이 페이지 다 떴다의 순간을 측정하는 것이다. 이 시간이 짧을수록 빠르게 느껴진다.

LCP를 개선하려면 대표 이미지의 용량을 줄이고, 서버 응답을 빠르게 하고, 중요한 자원을 먼저 불러오는 식으로 접근한다. 앞서 미디어 편에서 이미지를 압축하고 최적화하라고 한 게 여기서 효과를 본다. 무거운 대표 이미지 하나가 LCP를 통째로 망칠 수 있다.

서버 응답 속도도 LCP의 큰 축이다. 봇에게 SSR로 완성된 HTML을 빨리 내려주는 구조는 사람에게도 빠른 첫 화면을 준다. 앞 편들에서 SSR을 강조한 게 색인만이 아니라 속도에도 이롭다는 걸 여기서 확인하게 된다.

LCP를 이야기할 때 하나 더, 폰트도 로딩 속도에 영향을 준다. 웹폰트가 늦게 뜨면 텍스트가 지연되거나 폰트가 바뀌며 화면이 출렁인다. 그래서 폰트 로딩 전략을 잘 잡는 것도 LCP와 뒤에 나올 CLS에 도움이 된다. 시스템 폰트를 활용하거나 폰트 로딩을 최적화하는 식이다.

3. INP, 반응성

두 번째 지표 INP는 사용자가 무언가를 클릭하거나 입력했을 때 화면이 반응하기까지의 지연을 잰다. 버튼을 눌렀는데 한참 뒤에 반응하면 답답하다. 그 답답함을 수치로 만든 것이다. 이건 예전에 쓰던 다른 반응성 지표를 대체해 최근 표준이 됐다.

INP가 나쁜 주된 원인은 무거운 자바스크립트다. 클릭에 반응해야 할 순간에 브라우저가 무거운 스크립트를 실행하느라 바빠서 반응이 밀리는 것이다. 그래서 불필요한 자바스크립트를 줄이고, 무거운 작업을 잘게 쪼개거나 나중으로 미루는 최적화가 INP를 개선한다.

커뮤니티 사이트는 상호작용이 많아 INP가 특히 중요할 수 있다. 글 목록을 넘기고, 댓글을 달고, 추천을 누르는 동작이 즉각 반응해야 쾌적하다. 다만 이것도 색인과 기본 콘텐츠가 갖춰진 다음의 개선 과제로 두는 게 순서상 맞다.

INP와 관련해 커뮤니티 사이트가 특히 신경 쓸 지점은 무한 스크롤이나 실시간 갱신 같은 무거운 기능이다. 편리하지만 그만큼 자바스크립트 부담이 커서 반응성을 해칠 수 있다. 기능의 편의와 반응성 사이에서 균형을 잡아야 한다. 화려한 기능이 답답한 반응으로 이어지면 안 된다.

INP를 개선하는 실전 접근으로, 당장 필요 없는 스크립트는 나중에 불러오는 지연 로딩이 효과적이다. 첫 화면에 꼭 필요한 것만 먼저 실행하고, 나머지는 사용자가 상호작용할 때나 여유가 생길 때 불러오는 것이다. 그러면 초기 반응성이 좋아진다. 모든 걸 처음부터 다 불러오려는 욕심이 반응성을 해친다.

4. CLS, 시각적 안정성

세 번째 지표 CLS는 페이지가 로딩되는 동안 요소들이 얼마나 갑자기 움직이는지를 잰다. 글을 읽으려는데 이미지가 뒤늦게 떠서 텍스트가 아래로 밀리거나, 버튼을 누르려는데 광고가 끼어들어 위치가 바뀌는 그 짜증나는 경험을 수치화한 것이다. 움직임이 적을수록 좋다.

CLS의 가장 흔한 원인은 크기를 지정하지 않은 이미지다. 이미지가 로딩되기 전엔 자리를 차지하지 않다가, 로딩되는 순간 갑자기 자리를 밀고 들어와 아래 내용을 밀어낸다. 그래서 이미지에 width와 height를 미리 지정해 자리를 잡아두면 이 밀림이 사라진다. 간단하지만 효과가 크다.

특히 요즘 사이트들이 콘텐츠를 클라이언트에서 나중에 그려 넣는 방식을 많이 쓰는데, 이게 CLS를 악화시키는 주범이 되기도 한다. 처음엔 빈 화면이었다가 내용이 뒤늦게 채워지며 레이아웃이 출렁이는 것이다. 중요한 콘텐츠는 처음부터 자리를 잡고 렌더되게 하는 게 CLS 안정에 좋다.

CLS를 실제로 잡을 때 광고도 큰 변수다. 광고가 뒤늦게 로딩되며 자리를 밀어내면 CLS가 크게 나빠진다. 그래서 광고 영역도 미리 자리를 잡아두는 게 좋다. 커뮤니티가 광고로 수익을 낸다면, 광고 배치와 CLS의 균형을 초기 설계에 반영하는 게 나중에 고치는 것보다 낫다.

5. 측정과 우선순위

Core Web Vitals는 여러 도구로 측정한다. 구글 서치 콘솔에도 관련 리포트가 있고, 페이지 속도 측정 도구로 개별 페이지를 진단할 수 있다. 여기서 중요한 건 실험실 데이터와 실제 사용자 데이터를 구분하는 것이다. 실제 사용자 환경의 수치가 순위에 쓰이는 진짜 지표다.

다시 강조하지만 우선순위가 핵심이다. 색인이 안 되고 있다면 Core Web Vitals는 나중 일이다. 크롤과 색인, 콘텐츠, 내부 링크가 먼저고, 그것들이 자리 잡아 순위 경쟁에 들어간 뒤에 속도로 마지막 우위를 다투는 것이다. 순서를 지키면 힘을 낭비하지 않는다.

그래도 CLS만은 예외적으로 초기에 챙길 만하다. 이미지에 크기를 지정하는 정도의 작업은 비용이 적으면서 사용자 경험을 확실히 개선하기 때문이다. 큰 속도 최적화는 나중으로 미루더라도, 이미지 크기 지정 같은 저비용 고효율 개선은 초기에 해둬도 좋다. 다음 편에서는 신생 사이트의 가장 큰 약점, 백링크 0을 어떻게 벗어나는지를 다룬다.

측정과 우선순위에서 마지막으로 강조하면, Core Web Vitals는 완벽을 목표로 삼을 필요가 없다. 구글이 정한 양호 기준을 넘기면 충분하고, 그 이상의 소수점 개선에 매달리는 건 비효율이다. 기준을 넘겼으면 다시 콘텐츠로 돌아가는 게, 한정된 시간을 쓰는 현명한 방법이다.

우선순위를 다시 정리하면, 신생 사이트의 순서는 명확하다. 크롤과 색인이 먼저, 콘텐츠와 내부 링크가 다음, 그리고 순위 경쟁에 들어간 뒤 속도로 마무리다. 다만 이미지 크기 지정 같은 저비용 CLS 개선은 예외적으로 초기에 해둔다. 이 순서를 지키면 아직 색인도 안 됐는데 속도만 붙잡는 낭비를 피한다.

끝으로 정리하면, 페이지 속도는 순위의 마지막 한 끗이지 첫 단추가 아니다. Core Web Vitals의 양호 기준을 넘기는 걸 목표로 하되, 색인과 콘텐츠라는 앞선 과제를 제쳐두고 여기에 매달리진 말자. 순서를 지키는 게 이 편의 진짜 결론이다. 빠른 빈 사이트보다 느려도 색인된 좋은 사이트가 먼저다.