애드센스 및 핵심 성능 보고서는 제대로 작동할 수 있습니다. 방법은 다음과 같습니다.
게시 됨: 2022-12-03Adsense와 Core Web Vitals는 무엇을 읽든 상관없이 함께 원활하게 작동할 수 있습니다.
예, 처음에는 특히 모바일에서 Adsense가 있는 페이지의 사이트 속도와 느린 로드로 인해 어려움을 겪었습니다.
그러나 Google이 CWV(Core Web Vitals)를 계산하는 방법을 약간 조정하고 학습한 결과 내 사이트는 이제 Google Search Console(GSC)에서 모든 녹색 신호를 받고 있습니다.
내가 배운 가장 가치 있는 교훈은 PageSpeed Insights를 포함한 속도 테스트 사이트가 그다지 신뢰할 수 없으며 종종 오해의 소지가 있다는 것입니다.
Adsense가 Core Web Vitals를 통과할 수 있다는 증거
Adsense 페이지에 대한 좋은 CWV 점수를 얻는 가장 큰 요인은 Time To First Byte를 개선하는 것입니다. 나중에 수행하는 방법에 대해 자세히 알아보십시오.
두 번째는 페이지 상단에 애드센스 광고가 있는 경우 CSS를 사용하여 광고 공간을 허용해야 한다는 것입니다.
마지막으로 각 페이지의 광고 수를 제한하므로 Adsense 자동 광고는 좋은 조치가 아닙니다.
페이지 길이에 따라 모바일 버전에는 두 개의 광고를, 데스크톱에는 세 개 또는 네 개의 광고를 삽입합니다.
다음은 내 Google Search Console 페이지 경험 보고서에서 알려주는 내용입니다.
보시다시피 모바일과 데스크톱의 모든 지표는 녹색입니다.
그러나 이러한 보고서를 얻으려면 합리적인 양의 월별 트래픽이 필요합니다. Google은 금액을 알려주지 않지만 이 도움말에서는 데이터가 표시되지 않는 이유를 설명합니다.
이 경우 사이트를 테스트할 수 있는 다른 방법이 있습니다.
1. 애드센스 없이 먼저 확인
첫 번째 단계는 Adsense 광고가 없는 사이트의 일부 페이지를 테스트하는 것입니다.
그러나 훨씬 더 정확할 것이므로 모든 테스트에 시크릿 창을 사용해야 합니다.
먼저 Google 모바일 친화성 테스트로 사이트와 페이지를 테스트합니다. 통과하면 계속 진행하십시오. 그렇지 않은 경우 문제를 해결해야 합니다.
PageSpeed Insights 또는 GTMetrix와 같은 도구로 테스트할 수 있습니다. 그러나 한 가지 문제는 대부분의 사이트에 쿠키 동의 배너가 있다는 것입니다. 따라서 모든 테스트에는 항상 배너용 스크립트가 포함됩니다.
확인하는 가장 좋은 방법은 개발자 도구를 사용하는 것입니다.
쿠키 배너로 Lighthouse 보고서(PageSpeed Insights와 동일)를 실행합니다. 그런 다음 배너를 닫은 후 다시 테스트하십시오.
그런 다음 실적 보고서에서도 동일한 작업을 수행합니다.
배너로 결과가 훨씬 나쁘다면 더 나은 플러그인을 찾거나 로딩 시간을 개선할 수 있는 방법을 찾을 수 있습니다.
그러나 귀하의 사이트가 합리적으로 잘 최적화되어 있는지 확인해야 할 사항은 다음과 같습니다.
누적 레이아웃 이동에 대한 빨간색 경고가 표시되면 어디서 발생하는지 확인해야 합니다. 그러나 큰 변화가 아니라면 항상 문제가 되는 것은 아닙니다.
상호 작용 시간은 일반적으로 문제가 되지 않습니다.
특히 범용 스크립트와 GA4 스크립트를 모두 실행하는 경우 Google 애널리틱스로 인해 자주 발생합니다.
바닥글에서 실행 중인 스크립트가 있을 수도 있습니다.
위와 같이 모든 녹색 신호를 받으면 사이트가 잘 최적화된 것입니다.
2. Adsense 페이지로 Core Web Vitals 확인
동일한 테스트를 다시 수행하되 광고를 삽입한 페이지를 사용하십시오.
GSC의 페이지 경험 보고서에 데이터가 표시되지 않는 문제가 있는 경우 이 테스트가 도움이 될 것입니다.
귀하의 사이트와 비교할 수 있도록 제 라이브 사이트에 있는 모바일 및 데스크톱용 성능 및 Lighthouse 보고서입니다.
LCP(Largest Contentful Paint) 및 FID(First Input Delay)에 대한 녹색 점수를 볼 수 있습니다.
그러나 예, CLS(Content Layout Shift)에 대한 빨간색 경고가 있습니다. 페이지 하단에 삽입된 Adsense 광고에서 가져온 것입니다. 그러나 이것이 일반적으로 문제가 되지 않는 이유를 곧 보여드리겠습니다.
이제 Lighthouse 보고서를 살펴보겠습니다.
빨간색 경고는 나빠 보이지만 TTI(Time to Interactive) 및 TBT(Total Blocking Time)와 같은 요소는 CWV에 전혀 포함되지 않습니다. 그래서 그들은 관심이 없습니다.
세 가지 주요 우선 순위는 LCP, FID 및 CLS입니다. 보시다시피 성능 재포스팅의 CLS 경고는 매우 작았으므로 문제가 되지 않습니다.
CLS가 0.1 미만이면 괜찮습니다.
다시 모든 주요 CWV 요소는 녹색이며 모두 Adsense와 함께 Core Web Vitals를 통과합니다.
그것이 증명하는 것은 특히 모바일의 경우 성능 수치에 따라 안내되어서는 안 된다는 것입니다. 45점 또는 95점으로 CWV를 통과할 수 있습니다.
거의 항상 점수가 45-65인 페이지가 있으며 모두 페이지 경험 보고서를 통과합니다.
귀하의 테스트가 위와 유사한 결과를 제공한다면 귀하의 페이지와 사이트는 아마도 합격일 것입니다.
GSC에서 데이터를 확인할 수 없다는 것입니다.
4. 마지막 테스트
하지만 여러분이 할 수 있는 아주 간단한 테스트가 하나 더 있습니다.
휴대전화를 들고 와이파이를 끕니다.
이제 셀룰러 데이터를 사용하여 사이트의 몇 페이지를 확인하십시오.
로드하는 데 1초 이상 걸리면 할 일이 있는 것입니다.
4. 종종 첫 번째 바이트까지의 시간이 전부입니다.
네, 모든 테스트를 시도했지만 귀하의 사이트는 Adsense에서 Core Web Vitals에 실패했습니다.
그러나 내가 발견한 것처럼 사이트 구조, 테마 또는 플러그인이 아닌 경우가 너무 많습니다. TTFB(Time to First Byte)입니다.
실제로 TTFB는 새로운 CWV 신호가 될 것입니다. 그래서 그 어느 때보다 중요합니다.
작동하는 솔루션이 있으므로 당황하지 마십시오. 글쎄, 그것은 나에게 효과가 있으므로 바라건대 당신에게도 효과가 있을 것입니다.
아마도 당신과 마찬가지로 저는 CWV에 문제를 일으키는 Adsense로 몇 달 동안 정말 고생했습니다.
그러나 나는 많은 문제를 해결하는 빠르고 비교적 쉬운 해결책을 발견했습니다. Cloudflare를 사용하고 캐싱 플러그인을 변경하고 있습니다.
이 두 가지 변경으로 TTFB를 약 1초(일부 사이트에서는 그 이상)에서 50ms 미만으로 줄였습니다.
GTMetrix로 사이트를 확인하여 위와 같이 브라우저 타이밍 데이터를 얻을 수 있습니다.
가장 좋은 점은 초고속 호스트 서버가 필요하지 않다는 것입니다. 이 수정 사항은 대부분의 공유 호스팅 서버 계정과 전 세계 어디에서나 호스팅되는 사이트에서 작동합니다.
5. 수정 – Cloudflare 및 Cloudflare용 Super Page Cache
Cloudflare를 사용하고 있지 않다면 사용해야 합니다.
속도 이점뿐만 아니라 Cloudflare 방화벽의 보안 때문입니다.
이 게시물은 사이트를 Cloudflare에 추가하는 방법에 관한 것이 아닙니다. 그러나 여기에서 자습서를 찾을 수 있습니다.
사이트가 Cloudflare에 있으면 Cloudflare용 슈퍼 페이지 캐시를 WordPress 사이트 또는 테스트 사이트에 추가할 수 있습니다.
Cloudflare Cache Everything 페이지 규칙을 사용하며 거의 즉시 사용할 수 있습니다. 따라서 기본 설정을 많이 또는 전혀 변경할 필요가 없습니다.
경고의 유일한 단어는 하나의 캐싱 플러그인만 사용할 수 있다는 것입니다.
따라서 설치하기 전에 예를 들어 W3 Total Cache 또는 Super Cache와 같이 현재 사이트에 있는 모든 캐싱 플러그인을 비활성화해야 합니다.
그러나 자동 최적화를 계속 사용하여 CSS 및 JS를 축소하고 집계할 수 있고 사용해야 합니다.
Autooptimize는 Cloudflare용 Super Page Cache와 원활하게 통합되고 작동합니다.
약간의 작업처럼 들리지만 실제로는 노력할 가치가 있습니다.
확실하지 않은 경우 플러그인에 대한 리뷰와 항상 신속하게 답변되는 지원 요청을 확인하십시오.
내가 말할 수 있는 것은 이 캐싱 플러그인이 내 사이트 속도를 저하시키는 Adsense에서 겪었던 문제의 95%를 해결했다는 것입니다.
단순히 TTFB를 줄이면 LCP, FID, CLS와 같은 다른 문제가 줄어들거나 사라졌습니다.
TTFB에 두 번째 정도 저장하면 Adsense 코드가 훨씬 더 일찍 로드될 수 있기 때문입니다.
저는 Cloudflare용 Super Page Cache와 아무런 관련이 없습니다. 나는 사용자 일 뿐이며 제공되는 혜택을 누리고 있습니다.
6. 기타 빠른 팁
스크롤 없이 볼 수 있는 부분에 광고가 있는 경우 CSS 높이 속성을 사용하여 공간을 예약해야 합니다.
Ad Inserter를 사용하면 쉽습니다. CSS 설정을 수정하기만 하면 됩니다.
하지만 수동으로 코딩하려는 경우 이 줄을 애드센스 코드의 <ins class="adsbygoogle".
실험이 필요할 수 있지만 일반적으로 28o에서 300px 사이가 데스크톱 광고에 적합합니다.
마지막 팁은 Adsense JS 스크립트를 복제하지 않는 것입니다.
페이지의 첫 번째 광고에만 코드의 이 부분을 사용하고 다음 광고에서는 삭제하세요.
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-xxxxxxxxxxxxxxxxxxxxx"
crossorigin="anonymous"></script>
데스크톱과 모바일에 서로 다른 광고가 있는 경우 각 버전의 첫 번째 광고에 위의 스크립트를 사용하세요.
노력할 가치가 있습니까?
언제나 그렇듯이 대답은 상황에 따라 다릅니다.
어떤 사람들은 Core Web Vitals가 큰 순위 요소가 아니라고 말합니다.
그러나 Google의 John Muller는 CWV에 대해 다음과 같이 말했습니다.
이는 순위 요소이며 타이 브레이커 이상이지만 관련성을 대체하지는 않습니다.
내 경험상 CWV를 개선한 것이 Google 검색에서 검색어 순위를 높이는 데 도움이 되었다고 말할 수밖에 없습니다.
PageSpeed Insights가 최선의 확인 방법이 아니라는 실제 증거가 있습니다.
아래 이미지에서 CWV 평가가 원본 평균이 아닌 "이 URL"에 대한 것임을 알 수 있습니다.
실제 사용자 CRUX(Chrome User Experience Report) 데이터는 모두 녹색입니다. 따라서 이 페이지는 빠르며 Adsense 로딩으로 모든 테스트를 통과합니다.
하지만 아래의 PageSpeed Insights 실적 보고서를 살펴보세요. 62는 끔찍함을 의미합니다.
실제 LCP는 1.4초이지만 PageSpeed Insights 실험실 테스트 결과 5.9초로 나타났습니다!
실험실 데이터 속도 테스트를 신뢰할 수 없는 이유를 보여주는 완벽한 예입니다.
내 사이트의 페이지가 빠르다고 확신하기 때문에 더 많은 유기적 트래픽을 얻는 데 도움이 되었고 애드센스 수익이 증가했습니다.
수행할 수 있는 많은 테스트와 수집할 수 있는 데이터가 있습니다. 하지만 저에게는 위의 그래프가 유일하게 중요합니다.
1년 전에 수정 사항을 구현했으므로 결과는 매우 명확합니다.
Adsense가 CWV와 잘 작동하도록 함으로써 유기적 트래픽뿐만 아니라 수입도 증가했습니다.
결론
귀하의 사이트에서 Adsense를 사용하는 경우 때때로 어려울 수 있음을 알고 있습니다.
Adsense를 처음 사용하는 블로거는 소셜 미디어의 트래픽에 의존하면 종종 무효 클릭이 발생한다는 사실을 금방 알게 됩니다.
성공하려면 검색 엔진의 양질의 트래픽이 필요하므로 탁월한 SEO가 필요합니다.
Adsense로 Core Web Vitals를 개선하는 것은 좋은 SEO의 작은 부분 중 하나일 뿐입니다. 그러나 당신이 할 수 있는 모든 개선은 항상 플러스입니다.
예, 약간의 기술적 능력이 필요하며 이 공격적인 캐싱 플러그인으로 습관을 사용하고 적응시키는 방법을 배우려면 시간이 걸립니다.
그러나 저에게는 매우 잘 작동하며 확실히 노력할 가치가 있습니다.
관련 자료: 애드센스 계정에서 무효 트래픽을 확인하는 방법