핵심 성능 보고서 101 및 개발 지침
게시 됨: 2021-04-01
무엇이 일어나고 변화하고 있습니까?
2021년 5월 Google 은 페이지 속도 및 사용자 경험과 관련하여 페이지 순위 신호에 추가 요소를 추가하는 핵심 알고리즘 업데이트 의 출시를 시작했습니다. 핵심 업데이트 롤아웃은 2021년 6월까지 연장되었으며 이는 역사상 가장 큰 핵심 변경 사항 중 하나가 되었습니다. Core Web Vitals는 HTTPS 보안 사이트, 모바일 친화성 및 방해가 되지 않는 전면 광고와 같은 이전 순위 신호를 전체 페이지 경험 순위 요소의 검색 신호로 결합합니다.
Core Web Vitals의 세 가지 구성 요소는 다음과 같습니다.
- LCP(Largest Contentful Paint) : 인지된 로드 속도를 측정하고 페이지의 기본 콘텐츠가 로드되었을 가능성이 있는 시점을 페이지 로드 타임라인에 표시합니다. 좋은 사용자 경험을 제공하기 위해 사이트는 페이지 로드가 시작된 후 처음 2.5초 이내에 LCP가 발생 하도록 노력해야 합니다 .
- FID(First Input Delay) : 반응성을 측정하고 사용자가 페이지와 처음으로 상호 작용하려고 할 때 느끼는 경험을 정량화합니다. 우수한 사용자 환경을 제공하려면 사이트에서 FID가 100밀리초 미만이 되도록 노력해야 합니다 .
- CLS(Cumulative Layout Shift) : 시각적 안정성을 측정하고 표시되는 페이지 콘텐츠의 예기치 않은 레이아웃 이동량을 정량화합니다. 좋은 사용자 경험을 제공하기 위해 사이트는 CLS 점수가 0.1 미만이 되도록 노력해야 합니다 .
이 알고리즘 업데이트에 대한 Google의 공식 출시 성명: https://developers.google.com/search/blog/2020/11/timing-for-page-experience
또한 Google은 롤아웃 중에 성능을 계속 모니터링하면서 CLS 변경 사항에 대한 자세한 정보를 공개했습니다. 그 결과 많은 사이트가 최근 변경 사항으로 인해 더 좋은 점수를 받았으며 사이트 레이아웃을 조정하기 위한 많은 개발 작업을 피했습니다. 항상 그렇듯이 이러한 변경 사항은 변경될 수 있으므로 주간 또는 월간 체크리스트의 일부로 CWV를 모니터링하는 것이 좋습니다.
순위 업데이트에 대해 무엇을 알고 있습니까?
대부분의 Google 알고리즘 업데이트와 마찬가지로 현재 검색 환경에 어떤 영향을 미칠지 알 수 없는 부분이 많습니다. 이것이 페이지 순위의 요인이 될 것임을 알고 있습니다. 그러나 우리는 요인의 몇 퍼센트나 알고리즘 내에서 얼마나 영향을 미칠지 모릅니다. 또 다른 알려지지 않은 요인은 직접적인 경쟁자가 새로운 요인을 준수하기 위해 사이트를 업데이트하는 데 적응하거나 조치를 취하는지 여부입니다. 경쟁사 행동에 따라 이는 해당 동료와 비교하여 사이트 순위에 긍정적이거나 부정적인 영향을 미칠 수 있습니다. 우리가 아는 것은 Google은 콘텐츠가 약한 빠른 웹사이트보다 사용자에게 가치가 있거나 관련성이 있다고 판단되는 콘텐츠의 순위를 계속해서 우선 순위로 지정할 것입니다.
실제로 Google은 업데이트에 대한 더 많은 정보를 제공하면서 관련 콘텐츠가 검색 순위에서 가장 중요한 요소 중 하나로 남아 있음을 확인했습니다.
“우리 시스템은 페이지 경험의 일부 측면이 수준 이하인 경우에도 전반적으로 최고의 정보가 있는 페이지의 우선 순위를 계속 지정할 것입니다. 좋은 페이지 경험은 훌륭하고 관련성 높은 콘텐츠보다 우선하지 않습니다.”
Google 페이지 경험 순위 업데이트를 준비하는 방법은 무엇입니까?
이번 업데이트와 관련된 미지의 요인과 구글의 6개월 공지 기간으로 인해 이번 변경이 순위 요인이 될 것이라는 신호로 보인다. 따라서 SEO 및 개발 팀 모두 사이트의 현재 Core Web Vitals 성능을 검토하고 순위 신호 업데이트와 관련된 문제를 검토 및 업데이트할 때 신속하게 조치를 취하는 것이 좋습니다. 순위가 하락하면 회복하는 데 상당한 시간이 걸릴 수 있으므로 사후 대응이 아닌 능동적인 태도를 취하는 것이 중요합니다. 우리 모두는 SEO가 장기전이라는 것을 알고 있습니다!
사이트 문제를 식별하는 방법, 문제에 따른 다음 단계 및 추가 팁?
핵심 성능 보고서는 사이트의 Google Search Console 계정에서 '향상' 아래에 설명되어 있습니다. 또한 계정의 '개요' 섹션에는 아래 예와 유사한 전체적인 모양이 있습니다(계정은 사이트와 관련된 잠재적인 문제에 따라 달라지므로 약간의 차이가 발생할 수 있음). 데스크톱과 모바일 모두에 대해 설명된 섹션도 있습니다. 이 예에서는 모바일 관련 문제를 살펴봅니다.
2020년 9월 부터 모든 사이트가 모바일 우선으로 색인 이 생성 되므로 모바일 문제에 먼저 개발 시간을 할애하는 것이 좋습니다. 즉, 귀하의 사이트가 반응형이라면 모바일에서 수행하는 업데이트가 데스크탑에도 긍정적인 영향을 미칠 것입니다. 또한 사이트의 크기에 따라 "불량" 및 "개선 필요" 문제가 많이 있을 수 있습니다. "개선이 필요한" 항목은 노력 대비 영향 또는 80/20 규칙(나중에 자세히 설명)의 가치가 없을 수 있으므로 "불량" URL에 집중하는 것이 좋습니다!
Google Search Console에 표시된 최적의 성능보다 낮은 URL을 검토할 때 Google의 John Mueller 가 경우에 따라 Google이 여러 페이지의 평균으로 핵심 웹 바이탈 점수를 계산하는 방법에 대해 밝힌 내용 을 염두에 두는 것이 중요 합니다.
이것은 질문입니다.
"이것이 순위 신호가 되면… 페이지 수준이 될까요, 도메인 수준이 될까요?"
뮬러는 이렇게 대답했다.
“…필드 데이터에서 일어나는 일은 모든 페이지에 대한 데이터 포인트가 없다는 것입니다.
따라서 대부분의 경우 개별 페이지를 그룹화해야 합니다.
그리고 보유하고 있는 데이터의 양에 따라 전체 웹사이트(도메인 종류)를 그룹화할 수 있습니다.
…Chrome 사용자 경험 보고서에서 그들은 하위 도메인이 될 원본과 거기에 있는 프로토콜을 사용한다고 생각합니다.
그래서 그것은 일종의 포괄적 인 그룹화 일 것입니다.
웹사이트의 개별 부분에 대한 더 많은 데이터가 있으면 이를 사용하려고 합니다.
그리고 저는 이것이 하나의 URL처럼 표시되는 검색 콘솔에서도 볼 수 있다고 생각합니다. 그리고… 그와 연결된 다른 페이지가 너무 많습니다. 그리고 그것은 우리가 거기에서 사용할 그룹화의 일종입니다.”
Core Web Vitals에 대한 대화를 시작할 때 이 문제를 언급하는 이유는 무엇입니까? Mueller는 URL 문제를 요약한 Google Search Console 보고서가 동일한 문제가 있는 페이지를 그룹으로 분류하고 보고하려고 한다고 설명합니다. 불행하게도 실제로 이러한 URL 그룹화는 경험상 일부 웹사이트에 그다지 도움이 되지 않았습니다.
경우에 따라 Google Search Console 보고서에서 "저조한" 성능을 보이는 것으로 표시된 URL을 검토하지만 Lighthouse 및 Page Speed Insights로 테스트했을 때 동일한 페이지의 상태가 깨끗한 것으로 나타납니다.
요약하면 Google Search Console 보고서에 요약된 URL 문제를 검토할 때 "소금 한 알과 함께 받아들이는" 것이 좋습니다. 가장 좋은 추측은 Google이 실제 실제 브라우징 데이터(Google 용어로 '필드 데이터')의 28일 기록을 기반으로 페이지의 '웹 바이탈' 점수 순위를 매기려고 한다는 것입니다. 그러나 실제 데이터는 페이지 트래픽이 많지 않은 경우 전체 도메인(또는 Google 용어로 '출처')에서 집계될 가능성이 높습니다. Search Console은 웹 바이탈에 약간의 TLC가 필요하다는 사실을 식별하는 데 유용하지만 감사를 위해 그것에 의존하지 마십시오. 또한 수정 사항을 수행하고 감사하거나 유효성을 검사할 때 필드 데이터(여러 페이지에 대한 데이터일 수 있고 항상 28일 전환 확인 기간 이상임)가 아닌 실험실 데이터(실시간으로 테스트한 페이지의 개별 결과)를 검토하는 데 주의하십시오.
문제가 있음을 알게 된 후 소스 페이지를 확인할 수 없는 경우 각 핵심 템플릿에 대한 랩 테스트 예제 페이지부터 시작합니다. 예를 들어 홈 페이지, 제품 페이지, 카테고리 페이지, 블로그 기사 등이 있습니다. 종종 구조적 문제는 특정 페이지 유형의 모든 인스턴스에서 발견될 수 있으며 기본 템플릿에 대한 업데이트를 통해 웹 개발자가 한 번 수정합니다. 암호. 이것이 트릭을 수행하지 않으면 가장 많이 방문한 페이지부터 시작하여 개별 페이지의 하위 집합에 대한 유사한 분석을 고려하십시오. 이 프로세스에서 유용한 도구는 Screaming Frog를 통해 Core Web Vitals를 감사 하는 것 입니다.
CLS(누적 레이아웃 이동) 개선 지침
CLS(Cumulative Layout Shift) 는 페이지의 전체 수명 동안 발생하는 모든 예기치 않은 레이아웃 변경에 대한 모든 개별 레이아웃 변경 점수의 합계를 측정합니다. 레이아웃 이동은 보이는 요소가 하나의 렌더링된 프레임에서 다음 프레임으로 위치를 변경할 때마다 발생합니다.
Google은 몇 가지 기본 원칙을 고수하여 대부분의 웹사이트에서 CLS를 개선하는 방법에 대해 다음 지침을 권장합니다.
- 항상 이미지 및 비디오 요소에 크기 속성을 포함하거나 CSS 종횡비 상자 와 같은 것으로 필요한 공간을 예약하십시오 . 이 방법을 사용하면 이미지가 로드되는 동안 브라우저가 문서에 올바른 양의 공간을 할당할 수 있습니다. 크기 조정되지 않은 미디어 기능 정책 을 사용하여 기능 정책 을 지원하는 브라우저에서 이 동작을 강제 할 수도 있습니다 .
- 사용자 상호 작용에 대한 응답을 제외하고 기존 콘텐츠 위에 콘텐츠를 삽입하지 마십시오. 이렇게 하면 발생하는 모든 레이아웃 변경이 예상됩니다.
- 레이아웃 변경을 트리거하는 속성 애니메이션보다 변환 애니메이션을 선호합니다. 상태 간 컨텍스트 및 연속성을 제공하는 방식으로 전환을 애니메이션화합니다.
Google은 사이트 전체에서 업데이트를 분석, 테스트 및 배포하기 위해 다음 작업 과정을 활용할 것을 권장합니다.
- 작업이 필요한 페이지(위에 설명됨)를 식별했으면 PageSpeed Insights 를 사용 하여 페이지의 연구실 및 현장 문제를 진단하세요.
- 실험실에서 로컬로 사이트를 최적화할 준비가 되셨습니까? Lighthouse 및 Chrome DevTools 를 사용 하여 Core Web Vitals를 측정하고 정확히 무엇을 수정해야 하는지에 대한 실행 가능한 지침을 얻으십시오. Web Vitals Chrome 확장 프로그램 을 사용하면 데스크톱에서 측정항목을 실시간으로 볼 수 있습니다.
- 지침을 찾고 계십니까? web.dev/measure 는 페이지를 측정하고 PSI 데이터를 사용하여 최적화를 위해 우선 순위가 지정된 가이드 및 코드랩 세트를 표시할 수 있습니다.
- 마지막으로 풀 요청에 Lighthouse CI 를 사용 하여 프로덕션에 변경 사항을 배포하기 전에 Core Web Vitals에 회귀가 없는지 확인하십시오.
CLS를 개선하는 방법에 대한 자세한 내용은 CLS 최적화 를 참조하십시오 .
최대 콘텐츠 페인트(LCP) 개선 지침
LCP(Largest Contentful Paint) 메트릭은 뷰포트 내에서 볼 수 있는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 보고합니다.
현재 Largest Contentful Paint API 에 지정된 대로 Largest Contentful Paint에 대해 고려되는 요소 유형은 다음과 같습니다.
- <img> 요소
- < svg> 요소 내부의 <image> 요소
- <동영상> 요소(포스터 이미지 사용)
- url() 함수 를 통해 로드된 배경 이미지가 있는 요소 ( CSS 그래디언트 와 반대 )
- 텍스트 노드 또는 기타 인라인 수준 텍스트 요소 하위를 포함하는 블록 수준 요소
Google은 주로 네 가지 요인의 영향을 받는 LCP를 개선하는 방법에 대해 다음 지침을 권장합니다.
- 느린 서버 응답 시간
- 렌더링 차단 JavaScript 및 CSS
- 리소스 로드 시간
- 클라이언트 측 렌더링
LCP를 개선하는 방법에 대한 자세한 내용은 LCP 최적화 를 참조하십시오 . LCP를 개선할 수 있는 개별 성능 기술에 대한 추가 지침은 다음을 참조하세요.
- PRPL 패턴으로 인스턴트 로딩 적용
- 주요 렌더링 경로 최적화
- CSS 최적화
- 이미지 최적화
- 웹 글꼴 최적화
JavaScript 최적화 (클라이언트 렌더링 사이트용)
현재까지의 개발 핵심 웹 바이탈 결과
우리 개발 팀은 Core Web Vitals 순위 업데이트의 대부분이 업데이트가 Google에서 정한 표준을 충족하는지 확인하기 위해 개발 측면에서 광범위한 테스트가 필요하다는 것을 확인했습니다.
소규모 사이트의 경우 이러한 항목 중 많은 부분이 웹 개발자의 통제 범위를 벗어납니다. 예를 들어, 서버 속도는 주로 호스팅 공급자가 제어하며 공유 호스팅(WP 엔진 또는 Shopify와 같은)의 경우 개발자가 제어할 수 없습니다. 마찬가지로 기본 사이트 테마에는 종종 렌더링 차단 Javascript 및 CSS가 "구현"됩니다. 이러한 경우 보고된 많은 문제를 해결하는 것이 실용적이지 않을 수 있습니다. 이러한 이유로 (1) 가장 큰 영향을 미치는 문제와 (2) 개발 팀이 변경할 수 있고 변경해야 하는 코드로 인해 발생하는 문제의 교차점을 결정하려면 비판적 분석이 필요합니다.
여러 클라이언트에 대해 Core Web Vitals 문제를 검토하는 프로세스를 시작한 후 Google에서 제공하는 관련 도구 중 상당 부분이 문제(예: 콘텐츠 로드 이동)를 식별할 수 있는 한 미성숙한 상태로 남아 있음을 발견했습니다. 특정 원인을 정확히 찾아내는 데 항상 도움이 됩니다. 이 도구(특히 Chrome 개발자 도구)의 향후 반복에서 이것이 성숙해질 것으로 예상하지만 특정 문제를 식별하기 위해 대체 진단 프로세스가 필요할 수 있음을 발견했습니다.
또한 이러한 메트릭을 개선하기 위한 작업은 본질적으로 페이지 속도 성능을 전체적으로 개선하는 것과 비슷합니다. 각각의 경우에 우리는 "만점"을 추구하지 말 것을 조언합니다. 대신 80/20 규칙이 적용됩니다. 낮은 매달린 과일을 해결하면 메트릭이 크게 개선될 것입니다. 그 이후에는 개선에 더 많은 시간과 비용이 소요되고 덜 영향력이 있습니다.
모든 이미지, 비디오 및 컨테이너 요소에 공간 보존 마크업 또는 CSS를 포함하라는 Google의 제안과 같은 기본 지침은 일반적으로 구현하기 쉬운 좋은 조언입니다. 다른 문제는 추적하기가 더 어려우며 지표에 과도한 영향을 미치지 않는 한(일부 제안된 도구에서 보고한 대로) 해당 문제를 제쳐두는 것이 가장 좋습니다.
사이트 아키텍처는 또한 이러한 항목을 처리할 수 있는 상대적 용이성에 중요한 역할을 합니다. Shopify 및 WordPress와 같은 인기 있는 사이트 플랫폼은 WP Bakery 및 Shogun과 같은 그래픽 페이지 빌더와 함께 "뒤에서" HTML 생성 프로세스의 일부를 처리합니다. 페이지 빌더 구성 요소에 의해 가려진 문제(예: 이미지의 특정 지연 로드)는 사이트에 대한 근본적인 변경이나 플랫폼, 테마 또는 플러그인/앱 공급업체의 지원 없이는 쉽게 해결되지 않을 수 있습니다.
위의 개념은 자바스크립트를 사용하여 페이지에 위젯을 느리게 로드하는 제3자(예: Klaviyo와 같은 이메일 플랫폼의 내장된 등록 양식)로 확장됩니다. 경우에 따라 문제가 되는 구성 요소의 포함 코드 주변에 적절하고 명시적으로 크기가 지정된 컨테이너 요소를 배치하는 것이 실행 가능한 솔루션입니다. 다른 경우에는 공급업체가 직접 변경해야 할 수도 있습니다.
쉽게 액세스할 수 있는 핵심 사이트 템플릿(예: 제품 페이지, 제품 컬렉션 페이지 등)을 변경하여 해결할 수 있는 영향력 있는 문제로 수정 프로세스를 시작하는 것이 좋습니다. 이렇게 하면 종종 한 번의 코드 변경으로 수십 또는 수백 개의 사이트 페이지에서 결과를 개선할 수 있습니다. 다음으로, 거의 항상 사이트에서 가장 많이 방문하는 페이지인 홈페이지에 주소를 지정합니다. 마지막으로 문제의 심각도와 페이지의 가시성에 따라 수정이 필요한 다른 개별 페이지의 우선순위를 지정합니다.
페이지 속도 개선의 경우와 마찬가지로 Core Web Vitals 관리가 중요하지만 이는 Google의 순위 알고리즘에서 많은 변수 중 하나일 뿐이며 SEO도 시간과 예산을 두고 경쟁하는 다른 사이트 및 비즈니스 우선 순위와 균형을 이루어야 합니다.