Google의 2021년 5월 업데이트: Core Web Vitals 자세히 살펴보기

게시 됨: 2021-07-19

업데이트: 디지털 마케팅의 세계는 끊임없이 변화하고 있지만 걱정하지 마십시오. 우리가 그 위에 있습니다. Google은 다가오는 알고리즘에 대한 생각을 바꿨습니다.

업데이트에서 최근 변경 사항을 읽으십시오. 그러나 이 블로그도 자유롭게 읽으십시오.

2021년 5월에 Google은 검색 순위 알고리즘의 일부를 구성하기 위해 CWV(Core Web Vitals) 메트릭을 도입할 예정입니다. 다음은 당신이 알아야 할 것과 그 전에 해야 할 일입니다...

우리 모두는 빠른 사이트가 중요하다는 것을 알고 있습니다. 더 나은 사용자 경험을 제공하여 전환율을 높이고 모바일 친화성과 같은 다른 페이지 경험 측정항목과 함께 Google의 모바일 검색 순위를 이미 고려하고 있습니다.

하지만 구글은 여기서 멈추지 않습니다. 2020년 5월에 그들은 Core Web Vitals에 대해 이야기했고 2020년 11월 10일에 2021년 5월에 Core Web Vitals가 전체 순위 알고리즘에 검색 신호로 통합될 것이라고 발표했습니다.

또한 "검색 결과에서 페이지 경험이 우수한 페이지를 강조 표시하는 시각적 표시기를 테스트"할 계획입니다. 따라서 CWV 최적화를 통해 더 높은 순위를 얻을 가능성이 증가할 뿐만 아니라 검색 엔진 결과 페이지에서 클릭률이 증가할 가능성도 있습니다.

이러한 새로운 CWV 측정항목으로 표시된 잠재적인 문제를 감사하고 수정하기 위해 지금 조치를 취하면 2021년에 이 변경 사항이 발효될 때 사이트에서 더 높은 Google 순위를 얻을 수 있는 기회를 얻을 수 있습니다.

그러나 먼저 요약 ...

요약: 핵심 Web Vital이란 무엇입니까?

핵심 성능 평가는 전체 사이트 속도 점수에 적용되는 3가지 새로운 페이지 경험 메트릭 세트입니다. 이러한 측정항목은 이미 Google의 PageSpeed ​​Insights 도구 PSI 및 Lighthouse Performance 모니터링에서 중요한 역할을 하고 있습니다.

새로운 CWV 메트릭은 다음으로 구성됩니다. 핵심 Web Vitals 3x 지표

최대 함량 페인트(LCP)

fold 요소 위의 가장 큰 요소가 사용자에게 렌더링되기까지 걸리는 시간입니다. 전체 속도 점수 메커니즘의 25%를 차지하므로 모바일에서 가장 큰 항목을 2.5초 이하로 전달하는 과정을 간소화하는 것이 매우 중요합니다.

서버 응답성, 렌더링 차단 스크립트 및 스타일, CSS, 글꼴 및 이미지의 복잡성을 비롯한 많은 요인이 높은 LCP에 기여합니다.

첫 번째 입력 지연(FID)

이것은 상호 작용을 측정합니다. 예를 들어 탭이나 클릭을 통한 사용자 입력에 대한 페이지의 반응 정도. 브라우저가 첫 번째 입력에 응답하는 목표 속도는 100ms 이하여야 합니다.

브라우저가 페이지 로드 중에 많은 JavaScript를 구문 분석하거나 실행하는 경우 CPU를 묶거나 '메인 스레드'를 차단하여 장치가 입력에 덜 응답하게 됩니다. 높은 FID는 일반적으로 복잡한 JavaScript의 지표입니다. 이것은 단일 스크립트나 함수 또는 수많은 스크립트일 수 있습니다.

상호 작용 시간 및 총 차단 시간에 대한 기존 PSI 메트릭은 FID와 관련이 있으며 전체 속도 점수의 무려 35%를 차지합니다.

누적 레이아웃 시프트(CLS)

스크롤 없이 볼 수 있는 콘텐츠의 시각적 안정성을 측정한 것입니다. 전체 속도 점수의 5%에 불과하지만 전체 그림에서 여전히 고려할 가치가 있습니다. 높은 CLS는 페이지 로드 중 하나 이상의 시각적 레이아웃 변경을 나타낼 수 있습니다(예: 배너가 로드되어 페이지 콘텐츠가 아래로 이동하는 경우).

속도 점수 분석

아래 다이어그램은 전체 속도 점수의 분석과 이러한 새로운 CWV 메트릭이 GPSI 점수에서 얼마나 큰 역할을 하는지 보여줍니다.

Lighthouse 점수 업데이트의 소스 데이터

비 CWV 지표도 FCP(First Content Paint), TTI(Time to Interactive) 및 TBT(총 차단 시간)를 포함한 전체 점수를 형성하지만 세 가지 CWV 지표에 집중하면 다른 지표에 직접적인 영향을 미칩니다. 예를 들어 빠른 FCP 없이 빠른 LCP는 불가능하며 높은 FID 점수는 TBT 및 TTI의 직접적인 영향을 받습니다.

가장 큰 콘텐츠가 포함된 페인트 최적화를 위한 팁

LCP 메트릭은 수많은 개별 요소로 구성되며 높은 FCP의 직접적인 영향을 받습니다. FCP가 불량으로 표시되는 경우 여기에서 시작하는 것이 좋습니다. 네트워크 연결, 서버 응답성, 첫 번째 바이트까지의 시간 TTFB 및 렌더링 차단 파일의 모든 것이 FCP 값에 영향을 미칩니다. 보다 일반적인 페이지 속도 권장 사항에 대해 자세히 알아보려면 아래의 LCP 관련 팁과 함께 해당 주제에 대한 페이지 속도 eBook을 확인하십시오.

LCP 값이 FCP보다 훨씬 높으면 이 가장 큰 요소의 표시를 더 잘 간소화할 수 있는 방법을 살펴봐야 합니다.

가장 큰 요소 결정

가장 먼저 해야 할 일은 가장 큰 요소가 무엇인지 확인하는 것입니다. 가장 큰 요소는 다른 중단점에서 변경될 수 있는 픽셀 영역을 기반으로 하므로 시각적 스캔이 반드시 올바른 요소를 식별하지 못할 수도 있습니다.

PSI에는 진단 섹션에 '컨텐츠가 포함된 가장 큰 페인트 요소' 패널이 있어야 합니다. 또는 아래와 같이 Chrome의 성능 모니터링 도구에서 표시기에 마우스를 가져가면 LCP를 볼 수 있습니다. LCP 최대 요소 진단

위 예의 Hallam 사이트에서 성능 모니터는 LCP를 기본 'Thrive Online' 제목으로 표시합니다. 이상적으로는 이 예에서와 같이 LCP가 즉시 FCP를 따라야 하며 둘 사이에 간격이 있는 경우 이유를 이해하려고 시도해야 합니다.

글꼴이 최적화되어 있습니까?

접기 요소 위의 가장 큰 요소가 타이포그래피인 경우 글꼴 전달이 최대한 간소화되도록 해야 합니다. 여기에는 다음이 포함됩니다.

  1. CSS font-display 사용: swap; 글꼴 파일이 로드되는 동안 즉각적인 글꼴 표시를 보장합니다. Google Fonts와 Adobe의 Typekit에는 모두 글꼴 '디스플레이' 매개변수를 설정할 수 있는 기능이 있습니다.
  2. 타사 글꼴에 대해 도메인 간 요청을 하는 대신 서버에서 .woff 및 .woff2 글꼴 파일을 로컬로 호스팅해 보십시오. Google 글꼴은 매우 빠르며 Typekit 글꼴은 더 ​​느리고 일부 타사 글꼴 파운드리는 덜 안정적일 수 있습니다.
  3. 글꼴 파일을 미리 로드하면 도움이 됩니다. 로컬에서 호스팅되는 글꼴은 종종 웹사이트 기본 스타일시트에 포함되지만 이 스타일시트는 해당 글꼴에 대한 추가 요청이 이루어지기 전에 다운로드하고 구문 분석해야 합니다. 사전 로드는 CSS가 구문 분석될 때까지 기다리지 않고 글꼴 다운로드를 더 빨리 시작하도록 브라우저에 지시합니다.
  4. 타사 글꼴 파운드리에는 사전 연결 및 dns-prefetch를 사용합니다. 이러한 지시문은 글꼴에 대한 요청이 이루어지기 전에 타사 도메인 간에 DNS, TLS 및 TCP 연결을 설정하는 데 도움이 됩니다.
  5. 접는 디스플레이 상단에 필요한 타이포그래피용 글꼴 파일만 포함합니다. Font Awesome과 같은 아이콘 라이브러리의 글꼴 자산은 무겁기로 악명이 높지만 이러한 자산(및 해당 아이콘 라이브러리 CSS)에 대한 요청은 일반적으로 <head> 요소 뒤에 지연되고 로드될 수 있습니다.
  6. 기본 사이트의 스타일시트에 있는 글꼴 파일에 대해 도메인 간 요청을 하지 마십시오. 이 요청은 타사 도메인의 연결 및 추가 조회에 의존하기 때문입니다.
  7. 웹에 적합한 글꼴을 고려하십시오. 미학적 측면에서 매우 제한적일 수 있지만 글꼴 파일에 대한 요청이 필요하지 않습니다.

이미지가 최적화되어 있습니까?

종종 접기 요소 위의 가장 큰 요소는 이미지를 최적화하는 데 매우 중요한 이미지입니다. 다음은 일반적으로 모범 사례이지만 LCP 요소에 특히 중요합니다.

  1. 올바른 이미지 파일 형식을 사용하십시오. JPG 이미지는 사진에, SVG는 벡터 그래픽 및 아이콘에, PNG는 더 복잡하고 사진이 아닌 이미지에 투명도가 필요한 경우 사용해야 합니다.
  2. JPG 이미지가 저장되거나 약 50-60% 품질로 출력되는지 확인하십시오. 이 수준에서는 품질에 눈에 띄는 손실이 없어야 합니다. 또한 이미지에서 메타데이터가 제거되었는지 확인하십시오.
  3. tinypng.com과 같은 압축 플러그인 또는 서비스는 이미지를 자동으로 대량 최적화하고 불필요한 메타 데이터를 제거할 수 있습니다.
  4. 이미지는 표시되는 영역에 맞게 크기가 적절해야 합니다. 모바일에서 고화질 데스크탑 이미지를 출력하지 마십시오.
  5. 반응형 이미지의 경우 'rcset' 속성과 함께 표준 <img> 태그를 사용하여 이미지를 출력해야 합니다.
  6. 스크롤 없이 볼 수 있는 이미지 또는 오프스크린 이미지는 loading=”lazy” 속성을 사용해야 합니다.
  7. 더 나은 압축률을 위해 차세대 .web 이미지 파일 형식을 사용하십시오. 이렇게 하면 30%를 쉽게 절약할 수 있으며 많은 경우 훨씬 더 많이 절약할 수 있습니다.
  8. 덜 중요한 다른 콘텐츠보다 더 빨리 다운로드를 시작하려면 스크롤 없이 볼 수 있는 이미지 위에 가장 큰 이미지를 미리 로드하는 것이 좋습니다.

렌더링 차단 파일 줄이기

<head></head> 요소에 로드된 모든 JavaScript 또는 CSS 파일은 페이지 렌더링을 시작하기 전에 이러한 파일을 다운로드해야 하므로 렌더링 차단으로 간주됩니다. 이는 FCP 및 LCP 메트릭 모두에 큰 영향을 미칠 수 있습니다. 헤드에 있는 렌더링 차단 파일은 페이지의 접을 수 있는 위의 초기 표시에 중요한 경우에만 사용해야 합니다.

<head>에서 사용하지 않는 파일을 제거하거나 바닥글에서 중요하지 않은 파일을 로드하거나 여러 파일을 더 적은 수의 파일로 결합하면 렌더링 차단 자산의 양이 줄어듭니다.

JavaScript를 사용하여 LCP를 표시하지 마십시오.

CWV 이전에는 이것이 큰 문제가 아니었습니다. 속도 점수에 거의 또는 전혀 영향을 미치지 않는 페이딩 텍스트 또는 영웅 캐러셀과 같이 접힌 요소 위에 애니메이션을 적용하거나 표시하는 데 JavaScript를 사용하는 것이 일반적입니다.

가장 큰 요소의 표시가 JavaScript에 의존하는 경우 요소가 표시되기 전에 JavaScript를 다운로드, 구문 분석 및 실행해야 하므로 종종 긴 지연이 발생할 수 있습니다. JavaScript 파일은 일반적으로 <head> 요소 다음에 로드되므로 '렌더링 차단'되지 않지만 이는 LCP의 렌더링을 여전히 효과적으로 차단할 수 있음을 의미합니다.

아래 예를 살펴보십시오(로고가 흐릿하고 제목이 변경됨). 이것은 PSI의 다른 높은 점수를 받은 사이트에서 가져온 것입니다. LCP(주 제목 텍스트)는 텍스트가 페이드 인되기 전에 다운로드, 구문 분석 및 실행해야 하는 JavaScript(노란색 띠로 표시)의 요구 사항으로 인해 FCP에서 몇 초 더 떨어져 있습니다.

텍스트 페이딩 자체도 문제가 될 수 있어 가장 큰 요소의 표시가 지연됩니다.

이와 같은 JavaScript 기술은 전체 속도 점수를 즉시 25%까지 감소시킬 수 있으며 어떤 식으로든 가장 큰 요소의 로드를 방해하거나 방지하는 데 사용해서는 안 됩니다.

창 로드 시 스크립트 실행

JavaScript는 스크롤 없이 볼 수 있는 콘텐츠 위에 중요한 내용을 표시하는 데 거의 필요하지 않습니다(필요하지 않아야 함). 그러나 DOM이 준비되는 즉시 함수가 트리거될 수 있다는 일반적인 문제가 있습니다. 인기 있는 jQuery 프레임워크에서 이는 'ready' 이벤트를 통해 수행됩니다. Google 태그 관리자는 준비 시 기능 또는 '태그'를 트리거할 수도 있습니다.

기본 페이지 콘텐츠가 로드된 후 스크롤 없이 볼 수 있는 콘텐츠 및 LCP 요소의 렌더링과 잠재적인 간섭을 방지하기 위해 창 로드 이벤트에서 콘텐츠의 중요한 표시에 필요하지 않은 모든 JavaScript를 트리거하는 것을 고려하십시오.

LCP 전환

이미지가 아무리 최적화되고 능률적이라도 인쇄상의 요소에 비해 다운로드 및 표시하는 데 시간이 더 오래 걸립니다. 이미지에 대한 빠른 LCP 점수를 달성하는 것이 전적으로 가능하지만 때로는 가장 큰 이미지 요소를 축소하여 가장 큰 텍스트 요소보다 작게 조정하면 텍스트가 대신 LCP에 사용될 수 있음을 의미합니다.

LCP가 텍스트 요소로 전환된 아래 예와 같이 디자인이 허용하는 경우 점수에 큰 차이를 만들 수 있습니다. LCP 스위치 요소

첫 번째 입력 지연 최적화를 위한 팁

이전에 언급했듯이 FID는 페이지가 사용자 입력에 얼마나 반응하는지 측정합니다. 전체 속도 점수의 최대 35%를 설명할 수 있는 대화형 TTI까지의 시간과 총 차단 시간 TBT를 결합합니다.

이러한 메트릭은 주로 페이지가 로드될 때 구문 분석 및 실행되는 스크립트의 영향을 받습니다. CPU의 메인 스레드를 차단하고 특히 저가형 스마트폰 기기의 경우 기기 응답성에 잠재적으로 영향을 미칠 수 있습니다.

PSI에 표시된 '실험실 데이터'는 FID를 직접 측정하지 않는다는 점에 유의해야 합니다. 이는 시뮬레이션하기 어려운 사용자의 탭 또는 클릭 측정의 상호 작용 특성 때문입니다. 대신 '필드 데이터'로 수집됩니다. Chrome 사용자 경험 보고서 CrUX를 기반으로 28일 동안 실제 사용자로부터 수집한 측정값입니다.

따라서 FID를 직접 최적화하는 것은 조금 더 어렵습니다. 무언가를 변경할 수 없고 더 많은 데이터가 수집될 때까지 28일을 기다릴 수 없기 때문입니다. 따라서 이러한 메트릭의 낮은 시간은 낮은 FID와 상관 관계가 있으므로 대신 이를 위해 랩 데이터의 TTI 및 TBT 메트릭을 사용해야 합니다.

그렇다면 이러한 측정항목을 최적화하려면 어떻게 해야 할까요?

JavaScript 감사

JavaScript는 모든 모양과 크기로 제공될 수 있으며 단일 비디오 임베드, 채팅 위젯, ReCaptcha 스크립트 또는 HubSpot 통합이 높은 FID, TTI 및 TBT 지표의 유일한 원인인 경우는 드문 일이 아닙니다.

Page Speed ​​Insights의 진단 패널을 시작하는 것이 좋습니다. '메인 스레드 작업 최소화' 섹션은 자바스크립트가 얼마나 많은 실행 시간을 차지하는지 알려주고, '자바스크립트 실행 시간 줄이기' 섹션은 파싱 및 실행 시간이 높은 파일을 표시하고, '타사의 영향을 줄입니다. code'는 영향력이 큰 타사 스크립트를 강조 표시하고 그룹화합니다.

아래 스크린샷은 15초의 대화형 시간 측정항목과 함께 여러 개의 무거운 스크립트가 있는 사이트를 보여줍니다. 많은 스크립트는 HubSpot 및 Vimeo를 비롯한 타사에서 가져온 것입니다.

Google PageSpeed ​​Insights에서 타사 스크립트의 영향

이러한 스크립트가 페이지 로드에 미치는 영향에 대한 심층 분석 및 시각화를 위해 Chrome의 성능 모니터 도구는 실행되는 스크립트 및 기능, 이러한 스크립트의 상대적 영향, 페이지 로드 시점을 드릴다운하는 좋은 방법이 될 수 있습니다. 긴 스크립트가 실행되고 있습니다.

아래 예제는 동일한 사이트에서 가져온 것이며 노란색, 분홍색 및 주황색 막대로 표시되는 JavaScript를 보여주고 더 긴 막대는 더 오래 실행되는 작업을 보여줍니다. 이러한 긴 작업을 클릭하면 강조 표시된 스크립트가 위의 PSI에서 강조 표시된 큰 스크립트와 상관 관계가 있음을 알 수 있습니다.

성능 모니터 예
성능 모니터에서 많은 양의 JavaScript를 보여주는 스크린샷

어떤 스크립트가 성능에 영향을 미치는지 더 잘 파악하면 아래에 설명된 대로 영향을 최소화하기 위해 사용할 수 있는 몇 가지 기술이 있습니다.

비동기식으로 스크립트 로드

JavaScript는 기본적으로 순서대로 실행됩니다. 다른 스크립트의 로드에 의존하지 않는 스크립트가 있는 경우 이러한 스크립트는 다른 스크립트의 구문 분석 및 실행을 차단하지 않도록 'async' 속성으로 로드되어야 합니다.

JavaScript를 조건부로 로드

많은 사이트에서 흔히 볼 수 있는 문제는 무거운 스크립트가 필요하지 않을 때 전역으로 로드되거나 페이지에 로드된다는 것입니다. 예를 들어 양식 제출 시 스팸을 방지하기 위해 ReCaptcha를 사용해야 하는 경우 양식이 있는 페이지에서만 스크립트를 로드해야 합니다.

JavaScript 번들 간소화

jQuery UI 또는 Bootstrap과 같은 JavaScript 라이브러리는 추가 JavaScript 기능을 제공하는 데 자주 사용됩니다. 번들을 사용하는 경우 불필요한 JavaScript가 다운로드 및 구문 분석되지 않도록 번들 내에 관련 기능만 포함해야 합니다.

필요할 때 지연 로드 스크립트

JavaScript가 필요한 페이지에만 로드되는 경우에도 스크립트 자체는 페이지 로드 또는 창 로드 이벤트 동안 구문 분석 및 실행할 필요가 없습니다. 실제로 필요할 때만 JavaScript를 로드하면 TTI, TBT 및 FID 메트릭에 큰 차이를 만들 수 있습니다. 여기 예시들이 있습니다 :

  1. YouTube 및 Vimeo와 같은 비디오 삽입은 일반적으로 큰 영향을 미칩니다. 대신 비디오 축소판을 클릭할 때 이러한 스크립트를 로드하는 것이 좋습니다.
  2. HubSpot과 같은 타사 양식 통합은 집중적일 수 있습니다. 양식이 모달로 표시되거나 페이지 하단에 표시되는 경우 페이지 로드 대신 스크롤 또는 모달 활성화 시 필요한 스크립트를 로드하거나 삽입하는 것을 고려하십시오.
  3. 실시간 채팅 위젯은 전체 속도 점수에 최대 35%까지 영향을 줄 수 있습니다. 라이브 채팅 위젯을 글로벌 '라이브 채팅' CTA를 지원하는 전용 연락처 페이지로 옮기거나 '채팅하기' 버튼을 클릭할 때만 라이브 채팅 스크립트를 삽입하는 것을 고려하십시오.
  4. 내장된 iFrame 기반 콘텐츠에 'loading="lazy" 속성을 추가하면 도움이 될 수 있지만 이는 새로운 브라우저 기능이며 사용된 iFrame 내장에 따라 테스트가 필요합니다.

비즈니스 인텔리전스 도구 평가

Hotjar 또는 VWO와 같은 A/B 테스팅 소프트웨어와 같은 도구를 사용하여 사용자 행동을 분석하는 것은 비즈니스 인텔리전스에 정말 중요하며 많은 경우 그 이점이 사이트 속도에 미치는 영향보다 큽니다.

하지만 데이터 분석 빈도에 따라 이러한 도구를 연중무휴 24시간 실행하는 것의 중요성을 평가할 가치가 있습니다. 예를 들어 실행 중인 활성 테스트가 없고 충분한 데이터가 수집 및 처리된 후에 Hotjar와 같은 행동 분석 도구가 비활성화될 수 있는 경우 A/B 테스트를 꺼야 합니다.

누적 레이아웃 이동 최적화를 위한 팁

CLS(Cumulative Layout Shift)는 전체 속도 점수의 5%만 차지할 수 있지만, 여전히 전체 그림의 중요한 부분입니다. 특히 페이지 로드 시 많은 양의 이동 요소가 사용자에게 불편한 경험이 될 수 있기 때문입니다.

CLS 요소 결정

때로는 어떤 요소가 콘텐츠의 이동을 일으키는지 명확하게 보일 수 있지만 아래와 같이 PSI의 레이아웃 이동 패널을 통해 항상 확인할 가치가 있습니다.

레이아웃 이동 진단

CLS 메트릭은 0.1 미만이어야 하지만 위의 예에서 이 값은 400% 이상 초과되며 점수가 5% 감소합니다. 이것이 글로벌 문제라면 모든 페이지에 5%입니다.

이동 요소는 영향을 받는 순서대로 식별 및 처리되어야 하며 접는 부분 위와 아래의 요소를 포함할 수 있습니다. 아래에서 레이아웃 이동의 가장 일반적인 원인과 해결 방법을 강조했습니다.

애니메이션을 조심하세요

특정 애니메이션 기술은 사용자가 페이지를 아래로 스크롤할 때 이미지, 텍스트 또는 콘텐츠 패널에서 페이드 또는 슬라이딩과 같이 콘텐츠가 사용자에게 표시되는 방식을 변경하는 데 사용되는 것이 일반적입니다. 이러한 기술은 미학적으로 만족스러울 수 있지만(요청자에 따라 다름) 이러한 기술은 페이지 로드 중에 콘텐츠를 이동하지 않는 것이 중요합니다.

콘텐츠를 숨긴 다음 사용자에게 페이드 처리해야 하는 경우 콘텐츠가 로드될 때 컨테이너 크기 또는 총 페이지 높이가 변경되지 않는지 확인합니다. 필요한 경우 display: none; 대신 CSS 가시성 규칙을 사용하여 콘텐츠를 숨길 수 있습니다. 필요한 기본 공간을 보존합니다.

이미지 크기 지정

<img> 태그에 너비 및 높이 속성이 설정되어 있지 않거나 CSS가 이미지의 크기 또는 비율을 설정하는 데 사용되지 않는 경우 브라우저는 필요한 픽셀 영역을 결정하기 전에 먼저 이미지를 다운로드해야 합니다. 이미지가 로드될 때 이미지 아래에 렌더링된 콘텐츠가 이동할 수 있습니다.

이미지의 너비와 높이를 지정하거나 이미지를 다운로드하기 전에 CSS 내에서 이미지(또는 상위 컨테이너)의 크기 또는 비율을 설정하면 브라우저가 이미지를 표시해야 하는 영역을 인식하고 잠재적인 레이아웃을 피할 수 있습니다. 시프트.

배너

배너에 중요한 정보를 표시하는 데 사용되는 광고, 쿠키 법칙 막대 또는 기타 정보는 아마도 높은 CLS의 가장 일반적인 원인 중 하나일 것입니다.

배너 콘텐츠는 외부 데이터 소스에서 로드되거나 동일한 사이트의 JavaScript를 통해 로드되는 것이 일반적입니다. 즉, 배너 컨테이너의 크기는 콘텐츠가 로드될 때까지 계산되지 않을 수 있습니다. 이 경우 배너 콘텐츠가 로드되어 사용자에게 표시되면 배너 아래의 콘텐츠가 아래로 이동합니다.

이에 대한 여러 가지 해결 방법이 있습니다.

  1. 브라우저가 자리 표시자를 효과적으로 렌더링할 수 있도록 CSS에서 배너 또는 배너 컨테이너의 최소 높이를 설정합니다. 콘텐츠의 양이 동적이고 알려지지 않은 경우 문제가 될 수 있습니다.
  2. 배너의 위치를 ​​화면 상단 또는 하단에 절대 또는 고정합니다. 닫거나 닫을 수 있는 배너의 경우 고정 요소가 다른 요소의 위치에 영향을 미치지 않으므로 이는 좋은 고려 사항입니다.
  3. 가능한 경우 배너 콘텐츠의 서버 측 렌더링을 살펴보십시오. 이는 콘텐츠 및 배너 크기가 사용자에게 도달하기 전에 미리 로드될 수 있음을 의미합니다.

요약

위에 강조된 기술 중 일부가 Google의 새로운 핵심 성능 문제와 관련된 성능 문제를 진단하고 해결하는 데 유용하다는 것을 알게 되기를 바랍니다. Hallam에서 지난 몇 개월 동안 우리는 속도 감사 및 개발 팀의 직접적인 개선 측면에서 많은 고객이 웹 사이트 성능을 개선하도록 도왔습니다.

이 기사가 도움이 되었다면 웹 사이트를 구축하거나 관리하는 모든 사람이 혜택을 받을 수 있는 페이지 속도에 대한 보다 일반적인 권장 사항에 대해 자세히 설명하는 웹 사이트 성능 eBook을 확인하는 것이 좋습니다.