Core Web Vitals(Adsense)에 맞게 웹사이트를 최적화하는 방법

핵심 성능 향상을 위한 경쟁은 쉽지 않습니다. 웹사이트에서 수익을 창출하기 위해 Google 애드센스와 같은 광고 프로그램에 의존하면 더 어려워집니다.

Google 애드센스를 실행하는 웹사이트는 Google 애드센스가 없는 동일한 웹사이트보다 핵심 성능 평가에 실패할 가능성이 10배 더 높습니다. 이는 주로 Google 애드센스가 웹사이트에 추가하는 제3자 요청 및 자산의 수 때문입니다. 이러한 자산의 대부분은 최적화되지 않고 규모가 크며 사용자에게 친숙하지 않습니다.

애드센스 및 광고 플랫폼 외부에서 특히 스크롤 없이 볼 수 있는 부분에 최적화되지 않은 이미지, 자바스크립트 및 CSS가 많은 경우 핵심 성능 향상 테스트에 실패할 가능성이 매우 높습니다.

Core Web Vitals 테스트를 통과하고 검색 엔진 순위 잠재력을 향상시키는 데 어려움을 겪고 있다면 이 기사에서 실용적인 솔루션을 찾을 수 있습니다.

핵심 웹 바이탈이란 무엇입니까?

핵심 성능 평가는 사이트가 좋은 페이지 경험을 제공하는 방법을 결정하는 Google Lighthouse에서 제공하는 측정항목입니다. 테스트를 실행할 때 많은 메트릭이 있지만 가장 중요한 메트릭은 LCP(Large Contentful Paint), FID(First Input Delay) 및 CLS(Cumulative Layout Shift)입니다.

Google은 2021년 5월부터 이러한 측정항목이 검색결과에서 웹페이지 위치를 결정하는 데 사용되는 순위 신호의 일부가 될 것이라고 발표했습니다.

요약하면 Core Web Vitals는 웹마스터에게 공포를 주기 위한 것이 아니라 웹사이트의 페이지 경험을 개선하기 위한 수단이라고 말할 수 있습니다.

LCP(Large Contentful Paint) : LCP는 웹 페이지에서 가장 큰 가시적 이미지 또는 텍스트 블록이 로드되는 데 걸리는 시간을 측정합니다. 가장 큰 보이는 텍스트나 이미지가 빠르게 로드되면 나머지 이미지와 텍스트가 빠르게 로드되는 것으로 인식됩니다. 통과하는 데 필요한 로드 시간은 2.5초 입니다.

FID(First Input Delay) : FID는 웹 페이지 상호 작용을 측정합니다. 이는 사용자가 사이트를 클릭한 후 브라우저가 이벤트 핸들러 처리를 시작하는 데 걸리는 시간에 따라 결정됩니다. 이것은 널리 웹사이트의 첫인상이라고 합니다. 통과하는 데 필요한 시간은 100밀리초 입니다.

CLS(누적 레이아웃 이동) : CLS는 웹 페이지에서 발생하는 레이아웃 이동을 측정합니다. 웹 페이지가 로드되고 갑자기 무언가가 나타나거나 사라지고 페이지가 더 크거나 작게 조정되어야 할 때 그 이동이 측정됩니다. 사용자 경험에 끔찍하며 동의합니다. 통과해야 하는 점수는 0.1 입니다.

Core Web Vitals에 맞게 웹사이트를 최적화하는 방법

웹사이트를 최적화하려면 다음 단계를 따르세요.

1. 빠른 웹 호스트로 시작

응답 시간이 형편없는 웹 호스트가 있는 경우 여기에 나열할 다른 모든 항목이 원하는 결과를 제공하지 않을 수 있습니다. 서버가 요청에 응답하는 속도가 빠를수록 좋습니다.

TTFB(Time to First byte)가 빠른 웹 호스트가 중요한 이유는 무엇입니까? 일부는 TTFB가 중요하지 않다고 주장하지만 중요합니다. 그것이 다른 모든 것의 기초입니다. 인터넷 속도가 느린 도시에 사용자가 있는 경우 웹 호스트가 응답하는 속도가 모든 것을 의미합니다. 초고속 인터넷을 사용하는 도시에서 주로 사용자가 있는 경우 모든 웹 호스트가 잘 작동할 수 있습니다.

웹 호스트가 4G 대신 3G 또는 2G에 어떻게 응답하는지 테스트해 보십시오. 3G 또는 2G를 통해 연결하는 사용자가 많으면 핵심 성능 평가 점수에 합산되기 때문입니다. 따라서 모든 밀리초가 중요합니다. FID에서 100ms를 얻는 것과 101ms를 얻는 것의 차이점은 100ms에서는 통과하지만 101ms에서는 실패한다는 것입니다. 따라서 누군가 1ms가 중요하지 않다고 말하면 그 사람은 틀릴 수 있습니다.

웹 호스트를 선택할 때는 항상 대다수의 웹사이트 사용자에게 데이터 센터를 더 가깝게 만드십시오. 당신은 당신의 분석을 보면 그들의 위치를 ​​찾을 수 있습니다. 대부분의 사용자는 어디에서 왔습니까? 그들에게 더 가까운 데이터 센터를 선택하십시오. 가까울수록 좋습니다.

저는 개인적으로 웹 호스트를 변경한 후 웹 사이트의 핵심 Web Vitals 필드 데이터에 상당한 변화가 있음을 확인했습니다. 나는 아무것도 하지 않았다.

당신이 빠른 웹 호스트를 찾고 있다면, 진정성 없이 순전히 계열사에 의해 추진되는 추천이 많이 있습니다. WordPress를 실행하고 있고 여유가 있다면 Kinsta를 적극 권장합니다. 그들은 WordPress에 가장 적합합니다. 더 저렴한 것이 필요하거나 WordPress를 사용하지 않는 경우 Cloudways도 매우 효과적입니다.

2. 가볍고 속도에 최적화된 테마 사용

이 팁은 코딩을 하지 않는 사람과 시간이 부족한 코더에게 특히 유용합니다. 특히 옵션이 너무 많은 WordPress를 사용하는 경우 가볍고 속도에 최적화된 테마를 사용해야 합니다.

테마는 웹사이트의 골격과 같기 때문에 골격이 부서지면 본문도 부서집니다. 그게 다야.

테마에서 찾아야 할 모범 사례의 긴 목록이 있습니다. 가장 일반적인 나쁜 습관 중 일부는 JQuery에 과도하게 의존하는 것, 필요하지 않을 때 너무 많은 CSS/JS를 로드하는 것, 큰 테마 크기 등입니다. 항상 Yellow labs와 같은 도구를 사용하여 데모를 테스트할 수 있습니다.

WordPress를 사용하는 경우 가장 빠른 WordPress 테마 목록을 확인할 수 있습니다.

3. 이미지 최적화

이미지가 멋지다. 그들은 콘텐츠를 매우 매력적으로 만듭니다. 그러나 최적화되지 않은 경우 부담이 될 수 있습니다. 3MB와 같은 큰 이미지는 속도에 확실히 영향을 미칩니다. 스크롤하기 전에 사이트를 방문할 때 이러한 이미지가 표시되면 LCP 측정항목에 확실히 영향을 미칩니다.

사실 최적화되지 않은 이미지는 페이지 크기를 증가시킵니다. 페이지 크기가 클수록 로드하는 데 더 오래 걸립니다.

저는 개인적으로 모든 이미지를 업로드하기 전에 최적화하는 것을 선호합니다. 이미지 최적화를 위해 외부 서비스를 사용하지 않습니다. 그러나 WordPress 또는 유사한 CMS를 사용하는 경우 이미지를 자동으로 최적화하는 플러그인 및 솔루션이 있습니다. 사용하는 것과 관계없이 클라우드 솔루션도 있습니다.

4. 배경 이미지 제거 또는 크기 줄이기

배경 이미지는 일반적으로 매우 큽니다. 의미 있는 콘텐츠가 표시되기 전에 먼저 로드해야 하므로 로드 시간이 느려질 수 있습니다.

배경 이미지를 완전히 제거하여 더 빠른 웹사이트를 만들 수 있습니다. 중요하다면 가능한 가장 작은 크기로 최적화하거나 이미지 대신 패턴을 사용하는 것이 좋습니다.

5. 브라우저 캐싱 사용

충성도가 높은 독자가 많다면 브라우저 캐싱을 고려해야 합니다. 사용자가 웹사이트를 처음 방문하면 브라우저가 해당 웹사이트를 캐시합니다. 다른 모든 방문에 대해 즉시 로드됩니다. 이것은 두 번째 방문부터 FID와 LCP를 크게 향상시킬 수 있습니다.

WordPress 사용자의 경우 대부분의 캐싱 플러그인이 이를 달성하는 데 도움이 될 수 있습니다.

6. JavaScript 축소 및 사용하지 않는 JavaScript 연기

JavaScript는 훌륭하지만 종종 렌더링 차단입니다. 이는 로드 시간과 궁극적으로 FID에 영향을 줄 수 있음을 의미합니다.

파일 크기를 줄이기 위해 공백과 주석을 제거하여 JavaScript를 축소하십시오. 또한 중요하지 않은 JavaScript를 연기해야 ​​합니다. 이렇게 하면 FID가 향상됩니다.

WordPress 사용자의 경우 이 작업을 수행할 수 있는 Autooptimize, WP Rocket 및 기타 플러그인이 있습니다.

7. 애드센스 크기 속성 설정

웹사이트에서 애드센스를 실행 중이고 CLS로 어려움을 겪고 있다면 모든 문제를 해결할 수 있습니다. 그것은 나를 위해했고 당신을 위해해야합니다.

사용자가 방문할 때 표시되는 헤더 가까이에 광고 단위가 있는 경우 한 가지 문제는 광고가 즉시 로드되지 않을 수 있다는 것입니다. 페이지가 이미 로드된 후에 로드될 수 있으며 로드되면 레이아웃이 변경됩니다. 이는 반응형 광고 단위에서 매우 일반적입니다. 그렇게 되면 CLS 메트릭을 통과하는 것이 불가능합니다.

이를 처리하는 가장 좋은 방법은 애드센스 코드를 약간 수정하는 것입니다. 걱정하지 마세요. 매우 합법적입니다. 광고의 크기 속성, 특히 높이를 지정하기만 하면 됩니다. 그렇게 하면 광고가 로드될 때마다 레이아웃이 변경되는 것을 더 이상 알 수 없습니다.

다음은 내 블로그에서 헤더 바로 아래에 사용한 반응형 광고 단위의 예입니다. 게시자 ID와 광고 슬롯을 XXXXXX로 교체했습니다. 높이 속성(min-height: 300px)을 추가했습니다. 내가 그렇게하는 순간 모든 CLS 문제가 영원히 사라졌습니다.

 <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script> <!-- Header ad --> <ins class="adsbygoogle" data-ad-client="ca-pub-xxxxxxxxxxxxxx" data-ad-slot="xxxxxxxxxx" data-ad-format="auto" data-full-width-responsive="true"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>

이것이 하는 일은 페이지에서 해당 크기를 예약하는 것입니다. 따라서 광고가 표시될 때마다 이미 크기를 설정했기 때문에 레이아웃 이동이 없습니다.

8. 이미지 및 기타 미디어의 크기 속성 설정

광고와 마찬가지로 이미지 및 기타 미디어는 웹사이트에 로드될 때 레이아웃 이동을 유발할 수 있습니다. 그냥 뭔가를 읽고 있을 수 있습니다. 그런 다음 이미지가 로드되고 갑자기 레이아웃이 바뀌고, 읽고 있던 내용이 시야에서 사라지고 보이는 것이 다른 것뿐이거나 실수로 다른 것을 클릭하기도 합니다.

미디어 파일에 크기 속성을 설정하면 이 모든 것을 피할 수 있습니다. CLS 메트릭은 만족할 것입니다.

9. 이미지를 지연 로드합니다.

PageSpeed ​​Insight에서 오프스크린 이미지를 연기하라는 조언을 본 적이 있을 것입니다. 단순히 이미지를 지연 로드하는 것을 의미합니다.

지연 로딩은 페이지 크기를 줄이고 사용자가 방문할 때 페이지 로딩 시간을 줄이는 것입니다. 이는 CWV 메트릭에 좋습니다.

이것은 특히 LCP를 개선하는 데 도움이 될 것입니다.

10. 중요한 CSS를 최소화하고 생성하여 CSS 최적화

CSS는 웹사이트를 멋지게 보이게 하는 요소이지만, 큰 CSS 파일은 사용자에게 페이지 렌더링을 지연시키므로 큰 문제가 될 수 있습니다.

사용자가 웹사이트를 방문하면 브라우저는 정상적인 동작에 따라 웹 페이지 헤더에서 참조하는 모든 CSS를 로드, 구문 분석 및 실행할 때까지 사용자에게 웹 페이지 렌더링을 지연시킵니다. 큰 CSS 파일이 있는 경우 이는 큰 문제가 될 수 있습니다. 사이트 속도가 느려집니다.

중요한 CSS는 페이지를 로드하는 데 필요한 CSS만 로드하여 도움을 줄 수 있습니다. 나머지 CSS는 비동기식으로 로드할 수 있습니다.

파일 크기를 줄이기 위해 공백과 주석을 제거하여 CSS를 축소하는 것도 도움이 될 수 있습니다.

사용하지 않는 CSS를 제거할 수도 있습니다. 사용하는 서비스가 사용하지 않는 CSS를 푸시하는 경우 제거하는 것이 안전합니다.

WordPress를 사용하는 경우 WP Rocket, LiteSpeed ​​Cache, FlyingPress 및 이를 달성하는 데 도움이 되는 기타 플러그인이 있습니다.

11. 애드센스 스마트 로딩 구현

이 방법은 애드센스가 웹사이트 속도를 늦추는 책임이 있는 경우 모든 문제를 거의 완전히 제거할 수 있습니다.

이것은 현명한 방법으로 애드센스를 로드하는 것입니다. 사용자가 스크롤 또는 클릭과 같은 작업을 수행할 때까지 애드센스가 로드되지 않습니다. 이렇게 하면 로드 시간과 애드센스의 영향을 받는 모든 핵심 웹 바이탈이 크게 개선됩니다.

이 작업을 수행하는 데 도움이 될 수 있는 WordPress 플러그인이 많이 있습니다. WP Rocket 및 Flying Scripts가 그 예입니다. 내가 아는 한 이 방법은 Google 애드센스 정책을 위반하지 않습니다.

참고: 이 방법은 인지된 속도와 페이지 점수를 높이는 데 도움이 될 수 있지만 애드센스 수익에 영향을 미칠 수 있습니다. 가치가 있는지 확인하기 위해 실험을 실행하는 것이 좋습니다.

12. 가능하면 시스템 스택 글꼴을 사용하십시오.

글꼴은 모든 웹사이트에서 추가 로드 시간을 추가합니다. 이미지가 없는 웹 페이지의 경우 텍스트 블록이 LCP 등급을 결정합니다. 이 경우 LCP 점수는 글꼴의 직접적인 영향을 받습니다.

Google Font 및 Font Awesome은 계속 개선되고 있지만 시스템 스택 글꼴을 사용하면 상당한 개선이 이루어집니다. 장치에 따라 공상적이지는 않지만.

13. CDN 사용

전 세계 다른 지역의 사용자가 있는 경우 CDN을 사용하면 속도를 개선하고 간접적으로 핵심 성능 평가 지표를 개선하는 데 도움이 될 수 있습니다.

간단한 설명의 CDN은 웹 사이트의 많은 복사본을 만들어 세계 여러 지역의 다양한 POP(Point of Presence)에 저장합니다. 누군가 귀하의 웹사이트를 요청하면 가장 가까운 위치에서 귀하의 웹사이트를 제공합니다.

예를 들어 사이트가 미국에서 호스팅되고 영국에서 방문자가 있는 경우 미국에서 사이트를 가져오는 대신 CDN이 영국에서 사이트를 제공합니다. 그 효과는 빠른 배송이 될 것입니다. 속도.

최고의 CDN을 확인할 수 있습니다.

14. DNS 프리페칭 설정

웹사이트 제공을 위해 CDN과 같은 외부 서비스에 의존하는 경우 DNS 조회로 인한 지연을 최소화하기 위해 DNS 프리페칭을 설정해야 할 수 있습니다.

DNS 프리페치는 호출되기 전에 DNS를 프리페치합니다. 마지막으로 호출될 때 즉시 로드되도록 합니다.

15. 타사 스크립트 최적화

사이트에서 사용하는 서비스 중 일부가 사이트 속도를 저하시킬 수 있는 타사 스크립트를 추가하고 있지 않은지 확인하십시오.

더 나은 솔루션으로 사이트 속도를 늦추는 타사 요청으로 솔루션을 대체할 수 있습니다.

다른 타사 스크립트인 Google 애드센스와 관련하여 할 수 있는 일은 거의 없습니다. 가장 좋은 방법은 페이지에 통합된 최대 3개의 광고를 사용하는 것입니다. 일치하는 콘텐츠는 낮은 수입을 가져오지만 로드 시간이 추가되므로 피하십시오.

16. 스크롤 없이 볼 수 있는 부분에서 애드센스 제거

이 조언은 실험을 기반으로 합니다. 검색 콘솔 보고서에서 LCP를 제외한 모든 측정항목이 양호한 경우 먼저 이미지와 글꼴이 최적화되어 있는지 확인하세요. 최적화되었지만 여전히 LCP에 실패하면 애드센스가 책임이 있을 수 있습니다.

여유가 있다면 한 달 동안 스크롤 없이 볼 수 있는 부분에서 애드센스를 제거하고 문제가 해결되는지 확인하십시오.

제거하지 않으려면 수동으로 지연하거나 Flying Scripts와 같은 플러그인을 사용하여 지연할 수 있습니다.

17. AMP로 전환

AMP는 Accelerated Mobile Pages를 의미합니다. AMP의 아이디어는 모바일에서 더 빨리 로드되도록 웹 페이지를 최적화하는 것입니다. 그리고 물론 AMP 오픈 소스 프로젝트는 Google에서 시작했습니다.

AMP는 원래 모바일 페이지의 속도를 높이기 위한 것이지만 데스크톱 페이지의 속도도 높일 수 있습니다.

AMP 페이지는 모바일 또는 데스크톱 페이지보다 일관되게 더 빠르며 때로는 100% 이상 빠릅니다.

웹사이트의 유일한 수익 창출 전략이 Google 애드센스인 경우 모든 웹사이트를 AMP로 전환하는 것을 고려할 수 있습니다. 저는 개인적으로 제가 소유한 블로그에서 AMP 페이지의 애드센스가 모바일과 데스크톱보다 전환율이 더 높다는 사실을 알게 되었습니다.

결론

Core Web vitals는 Google뿐만 아니라 사용자를 위해 웹사이트를 개선하는 데 도움이 될 수 있습니다. 실험실 데이터 테스트 점수는 양호하지만 현장 데이터 점수가 나쁜 것은 매우 일반적입니다.

이것은 사용자의 구성 때문입니다. 대부분의 사용자가 인터넷 속도가 느린 곳에서 온 경우 최적화 작업을 잘 수행했지만 여전히 필드 데이터에서 실패했을 수 있습니다.