콘텐츠를 열심히 썼는데 RPM이 오르지 않는다면, 글의 문제가 아닐 수 있습니다. 저도 한참 그 함정에 빠져 있었습니다. 글을 더 잘 쓰면 될 거라고 믿었는데, 진짜 문제는 페이지가 너무 느렸다는 것이었습니다. PageSpeed Insights 점수를 처음 확인한 날, 머리가 멍해졌던 기억이 지금도 생생합니다.
콘텐츠보다 먼저 봐야 할 것이 있었습니다
애드센스를 시작하고 몇 달 동안 월 평균 RPM이 600~700원 수준에서 꼼짝을 하지 않았습니다. 여기서 RPM이란 페이지 1,000회 노출당 발생하는 수익을 의미하는 지표로, 블로그 광고 수익의 효율을 가장 직관적으로 보여주는 숫자입니다. 저는 이 숫자가 낮은 이유가 글의 품질 때문이라고만 생각했습니다. 그래서 글을 더 길게, 더 자세하게 썼습니다. 그런데도 수익은 제자리였습니다.
답답한 마음에 PageSpeed Insights를 처음으로 제대로 들여다봤습니다. 결과를 보고 적잖이 당황했습니다. 모바일 LCP가 6.2초였습니다. LCP(Largest Contentful Paint)란 페이지에서 가장 큰 콘텐츠 요소가 화면에 완전히 표시되는 데 걸리는 시간을 말합니다. 쉽게 말해 독자가 페이지에 들어왔을 때 "아, 뭔가 뜨긴 했구나" 하고 느끼기까지의 시간입니다. 구글이 권장하는 기준은 2.5초 이내인데, 저는 그 두 배 이상이었던 겁니다.
문제의 원인은 생각보다 명확했습니다. 블로그 테마에 기본 탑재된 슬라이더 플러그인 JS와, 실제로는 한 번도 쓰지 않던 아이콘 폰트 CSS가 렌더 블로킹 리소스로 작동하고 있었습니다. 렌더 블로킹 리소스란 브라우저가 페이지를 화면에 그리기 전에 반드시 내려받아야 하는 스크립트나 스타일시트를 뜻합니다. 이 파일들이 로딩을 가로막고 있으니, 광고는커녕 페이지 자체가 늦게 뜨고 있던 것입니다. 구글 연구에 따르면 LCP가 1초 빨라질 때마다 전환율이 최대 8% 향상된다고 합니다(출처: Think with Google).
AI 리팩토링으로 LCP 6.2초를 2.8초로 줄인 과정
사실 저는 개발자가 아닙니다. HTML은 어느 정도 읽을 수 있지만, JS 파일을 직접 수정하거나 CSS를 정리하는 것은 엄두가 나지 않았습니다. 그래서 AI에게 블로그 전체 HTML 소스를 붙여넣고 "Core Web Vitals 개선을 위해 렌더 블로킹 리소스를 제거하고 리팩토링해줘"라고 요청했습니다.
AI가 제시한 개선안은 생각보다 구체적이었습니다. 핵심 조치를 정리하면 다음과 같습니다.
- 슬라이더 JS에
defer속성을 추가해 렌더 블로킹 제거 - 아이콘 폰트 CSS를 인라인 SVG로 교체해 불필요한 외부 요청 차단
- 광고 스크립트 앞에
<link rel="preconnect" href="https://pagead2.googlesyndication.com">삽입 - 이미지 태그 전체에
loading="lazy"속성 자동 추가 - 광고 코드 삽입 위치를 콘텐츠 하단에서 뷰포트 내 위치로 조정
여기서 preconnect란 브라우저가 외부 서버에 미리 연결을 준비해두는 힌트를 의미합니다. 광고 서버와의 초기 연결 지연을 줄여 광고가 더 빠르게 로딩되는 효과가 있습니다. 제가 직접 써봤는데, 이 한 줄이 생각보다 체감 차이를 만들어냈습니다.
변경 사항을 적용한 뒤 모바일 LCP는 6.2초에서 2.8초로 줄었습니다. 그리고 2주 후 RPM이 600원대에서 1,100원대로 약 80% 올랐습니다. 솔직히 이건 예상 밖이었습니다. 글 하나 더 쓰는 것보다 코드 몇 줄 고치는 게 수익에 더 직접적인 영향을 줄 거라고는 상상도 못 했거든요.
AI가 특히 잘 잡아낸 부분은 사람이 놓치기 쉬운 세부 사항들이었습니다. 이미지 태그에 width와 height 속성이 빠진 경우 CLS가 발생할 수 있는데, CLS(Cumulative Layout Shift)란 페이지가 로딩되는 동안 콘텐츠가 예상치 못하게 이동하는 현상을 수치화한 지표입니다. 광고 영역이 뒤늦게 나타나며 글이 아래로 밀려나는 경험을 한 번쯤 해보셨을 텐데, 그게 바로 CLS가 높은 페이지입니다. 구글은 이 CLS, LCP, INP를 묶어 Core Web Vitals로 정의하고 검색 랭킹 신호로 공식 반영하고 있습니다(출처: Google Search Central).
속도 최적화가 RPM을 올린다, 단 조건이 있습니다
이 경험을 정리하면서 한 가지 반드시 짚고 싶은 게 있습니다. 페이지 속도를 올리면 RPM이 오른다는 말은 맞지만, 항상 그런 건 아닙니다. 제 경험상 이건 좀 다릅니다.
RPM은 트래픽의 질, 독자가 위치한 국가, 콘텐츠 주제의 광고 단가, 그리고 계절성까지 수십 가지 변수가 얽힌 결과입니다. 트래픽 자체가 낮거나 광고 단가가 낮은 주제를 다루는 블로그라면, 속도를 아무리 올려도 RPM이 오를 수 있는 폭에 한계가 있습니다. 뷰어블 노출률(Viewability)을 70% 이상 유지하고 Fill Rate를 높인다 해도, 경매에 참여하는 광고주 수 자체가 적으면 단가가 오르지 않습니다. 여기서 Fill Rate란 광고 요청에 대해 실제로 광고가 채워진 비율을 의미합니다. 이 수치가 낮으면 광고가 뜰 자리에 아무것도 나타나지 않아 수익 기회 자체를 잃게 됩니다.
또 한 가지, AI 리팩토링은 기술적 장벽을 낮춰주는 도구이지 광고 배치 전략까지 설계해주지는 않습니다. 어느 위치에 광고를 넣을지, 몇 개를 넣을지, 어떤 형식을 선택할지는 UX 설계의 영역이고 결국 사람이 직접 실험해야 하는 부분입니다. 이 점은 AI를 쓰면서도 계속 의식하고 있습니다.
그럼에도 불구하고, 이후 새 글을 발행할 때마다 AI에게 HTML을 검토시키는 것은 지금도 제 루틴입니다. 사람이 반복해서 놓치는 패턴을 AI는 매번 일관되게 잡아내거든요.
페이지 속도와 RPM의 관계를 직접 수치로 확인하고 나면, 블로그 운영의 우선순위가 달라집니다. 글을 쓰기 전에 현재 페이지가 빠르게 뜨는지부터 확인해보시길 권합니다. PageSpeed Insights에서 모바일 LCP 수치를 먼저 확인해보는 것, 그게 시작입니다. 렌더 블로킹 리소스가 몇 개나 있는지 확인하고, 그 목록을 AI에게 넘기는 것만으로도 의외의 변화가 생길 수 있습니다.
이 글은 개인적인 경험과 의견을 공유한 것이며, 전문적인 웹 개발 또는 광고 수익화 조언이 아닙니다. 블로그 환경과 트래픽 구조에 따라 결과는 달라질 수 있습니다.
참고: Google — "Core Web Vitals" (web.dev/vitals)
Google Ads Help — "Improve ad viewability" (support.google.com/adsense)
web.dev — "Optimize Largest Contentful Paint" (2024)
Think with Google — "The Need for Mobile Speed" (thinkwithgoogle.com)
PageSpeed Insights — pagespeed.web.dev