Google의 다가오는 페이지 경험 업데이트는 CWV(Core Web Vitals)에서 파생된 신호를 공식 순위 알고리즘에 소개합니다. Core Web Vitals는 페이지가 로드되고 대화형이 되며 상호 작용하는 실제 사용자를 위해 시각적으로 안정화되는 속도를 측정하는 지표 집합입니다. Core Web Vitals 테스트에 실패한 웹 사이트는 현재 2021 년 초에 나온 것보다 낮은 순위를 차지할 것입니다.
CWV는 사용자가 인지하는 경험에 상당한 영향을 미치는 것으로 확인된 3단 속도 지표로 구성됩니다. 여기에는 로드 시간을 측정하는 최대 LCP(Contentful Paint), 상호 작용 및 응답성을 측정하는 첫 번째 입력 지연(FID), 시각적 안정성을 측정하는 CLS(Cumulative Layout Shift)가 포함됩니다. 웹 사이트 속도는 많은 이커머스 회사에서 최전선에 있었지만 온라인 환경에서 가장 중요한 요소 중 하나가 될 것입니다. 다음은 중점을 두어야 하는 지표와 각 지표의 속도를 개선하는 방법입니다.
핵심 웹 바이탈이란?
온라인에서 좋은 첫인상을 남기는 것은 매우 중요합니다. 쇼핑객은 중단 없이 제품을 즉시 확인하고, 빠르게 탐색하고, 간편하게 체크아웃하기를 원합니다. 그들의 기대가 충족되지 않으면, 그들은 튀어 오르고 결코 돌아 오지 않을 것입니다. Core Web Vitals는 모바일 쇼핑객이 사이트를 실시간으로 탐색할 때 경험치 페이지를 측정하여 이러한 문제를 해결합니다.
대부분의 Google 도구는 시뮬레이션된 환경(실험실 데이터)에서 합성 테스트를 사용하지만, Crux(Crux)에서 수집한 현장 데이터를 사용하여 측정됩니다. 실제 Chrome 사용자 데이터 데이터베이스입니다. 필드 데이터는 장치, 네트워크 상태 및/또는 설정과 같은 실제 사용자 변수의 극적인 효과를 캡처합니다. 사용자의 조건에 따라 사이트의 성능이 크게 달라질 수 있으며 핵심 웹 바이탈 스코어에 영향을 줄 수 있습니다.
각 CWV 메트릭은 양호, 보통 또는 불량으로 간주되는 서로 다른 임계값을 가집니다. 그러나 Google은 이러한 그룹으로 페이지를 분류할 때 75번째 백분위수를 사용한다는 공통점이 있습니다. 페이지 로딩의 75% 이상에서 빠른 속도로 간주되는 페이지가 좋은 경험입니다.
모르는 것을 최적화할 수는 없으므로 핵심 웹 바이탈을 구성하는 세 가지 메트릭을 각각 알아보겠습니다.
LCP(Largest Contentful Paint)
사용자는 일반적으로 가장 큰 콘텐츠 요소가 화면에 완전히 표시될 때, 즉 가장 큰 콘텐츠 페인트 또는 LCP의 속도로 페이지가 로드되었다고 느낍니다. 콘텐츠 요소에는 블록 수준 요소, 이미지(SVG 파일 내 이미지 포함) 및 비디오가 포함될 수 있습니다. 전자 상거래의 경우 LCP는 일반적으로 제품 이미지/대표 이미지가 로드되는 속도를 측정합니다. 이 속도가 느리면 사용자는 전체 환경이 비슷하다고 가정하여 경쟁업체의 사이트로 이동하게 됩니다.
2.5초 이하의 LCP는 빠르다고 간주되고, 2.6초에서 4.0초 사이의 LCP는 개선이 필요하며, 4.0초 이상의 LCP는 느립니다.
TheTieBar.com Layer0에서 800ms 내에 LCP 로드(Edgio)
위의 예에서 타이 바의 LCP는 기본 이미지가 완전히 색칠되면 900ms로 표시됩니다. Tie Bar는 Edgio에서 수천 페이지에 걸쳐 사용자 지정, 실시간 재고 조회 및 동적 가격 책정을 제공하는 동시에 모바일 쇼핑객에게 1초 미만의 페이지 로드를 지속적으로 제공합니다.
일반적으로 LCP는 다음 중 하나의 영향을 받습니다.
- 느린 서브 응답 시간
- 렌더링을 차단하는 JavaScript 및 CSS
- 긴 리소스 로드 시간
- 클라이언트 측 렌더링 문제
LCP를 최적화하려면 다음 사항을 고려하십시오.
- 사용 가능한 가장 가까운 CDN POP로 트래픽을 라우팅하고, 자산을 캐싱하고, 서비스 작업자를 사용하고, “rel=”Preconnect”를 통해 서드파티 연결을 조기에 설정하여 서버 응답 시간을 최적화합니다.
- 코드를 줄이고(예: 공백 제거), Broti 또는 Gzip 같은 툴로 데이터를 압축하고, 번들을 분할하고 처음에 필요한 것만 보내고, Babel 과 같은 툴로 새로운 문법으로 코드를 제공함으로써 JavaScript 차단 시간을 줄입니다. 사용하지 않는 CSS나 간격, 들여쓰기 또는 주석과 같은 불필요한 문자를 제거하고 중요한 CSS를 페이지 머리글에 직접 포함시켜 CSS를 줄입니다.
- 리소스 로드 시간을 줄이고, 이미지 및 텍스트 파일을 최적화 및 압축하고, 필수 리소스를 미리 로드하고, 서비스 작업자를 사용하여 네트워크 연결 및 캐시 자산을 기반으로 다양한 자산을 제공합니다.
- SSR(Server-side rendering) 및 사전 렌더링을 사용하여 JavaScript 차단 시간을 줄여 클라이언트측 렌더링을 최적화합니다(최적화하려면 #2 참조).
FID(First Input Delay)
사용자의 첫인상은 가장 큰 이미지가 렌더링되는 속도에 영향을 받지만, 사용자가 상호 작용을 시도한 후에는 사이트의 반응성을 유지하는 것이 중요합니다. FID(First Input Delay)는 사용자가 처음으로 페이지와 상호 작용(클릭, 탭 또는 키 누름)한 시간부터 브라우저가 해당 상호 작용에 응답할 수 있는 시간까지의 시간을 측정합니다.
일반적으로 입력 지연은 JavaScript가 메인 스레드에서 실행되기 때문에 발생합니다. 모든 JavaScript는 기본적으로 렌더링 차단입니다. 즉, 브라우저가 JavaScript 파일을 발견하면 JavaScript를 다운로드, 구문 분석, 컴파일 및 실행하기 위해 수행하는 작업을 일시 중지해야 합니다. 시간이 오래 걸릴수록 사용자 경험의 지연이 증가하고 Google이 페이지를 사용 가능한 것으로 보는 횟수가 줄어듭니다.
Google은 FID가 100밀리초 이하인 경우, 1.1초에서 3.0초 사이인 경우 개선이 필요하며 3.0초 이상인 경우 느린 것으로 간주합니다. 모든 핵심 웹 바이탈에 대해 75번째 백분위수를 찾는 것이 중요하지만, Google은 모바일 및 데스크톱에서 FID의 95번째–99번째 백분위수를 검토할 것을 권장합니다. 이는 최악의 사용자 경험을 나타내고 가장 개선이 필요한 영역을 검증할 것입니다(페이지 로드의 95% 이상에 대한 FID에 초점을 맞출 것입니다).
LCP 및 CLS와 달리 FID는 실제 사용자 상호 작용이 필요하므로 현장에서만 측정할 수 있으며 실험실 데이터에서는 찾을 수 없습니다.
FID가 느린 일반적인 이유는 다음과 같습니다.
- 50밀리초 이상 메인 스레드를 차단하는 긴 작업
- 상호작용 준비를 지연시키는 자사 스크립트 실행
- JavaScript 실행 시간이 많이 걸림
How FID를 위한 optime에:
- 장기 실행 코드를 더 작은 비동기 작업으로 나누고 코드 분할을 활용합니다.
- 중요하지 않은 구성 요소에 대한 과도한 스크립트 로딩(및 실행)을 중요 경로 밖으로 이동하고 계단식 데이터 페치와 클라이언트 측에서 사후 처리해야 하는 데이터의 양을 최소화합니다.
- Comlink, Workway 또는 Workerize와 같은 웹 작업자를 사용하면 백그라운드 스레드에서 JavaScript를 실행하고 JavaScript 번들을 여러 청크로 코드 분할(lazy-loading이라고도 함)하고 모든 타사 스크립트를 defer 또는 async로 로드할 수 있습니다.
CLS(Cumulative Layout Shift)
페이지의 시각적 안정성은 사용자 경험에 영향을 미치는 또 다른 요인이며, 쇼핑객이 구매 경로를 계속 진행하지 못하게 할 수 있습니다. Core Web Vitals의 세 번째이자 마지막 지표는 사용자가 예상치 못한 레이아웃 이동을 경험하는 빈도를 측정하는 CLS(Cumulative Layout Shift)입니다.
링크나 제품 이미지를 누르려고 하지만 화면을 터치하기 직전에 페이지가 이동하고 BAM을 클릭하는 경우 실수로 다른 항목을 클릭하는 경우가 있습니다. 최상의 시나리오에서 이러한 상황은 약간의 성가심이지만 최악의 경우 웹에서 부드럽고 덜 잔인한 경험을 검색하는 쇼핑객을 보냅니다.
Google은 충격 비율 또는 뷰포트에서 이동한 가시적 콘텐츠의 양을 거리 비율 또는 불안정한 요소가 프레임에서 이동한 거리를 화면의 최대 크기(높이 또는 너비)로 나눈 값으로 곱하여 페이지 이동을 계산합니다. 쇼핑객이 브라우징하는 동안 발생하는 각 예기치 않은 레이아웃 변경에 대한 모든 개별 점수(충격 분수 x 거리 분수)의 합계는 페이지의 CLS를 초래합니다.
Google은 0.1보다 낮은 CLS를 양호한 것으로 간주하고, 0.1에서 0.25 사이의 CLS를 보통으로 간주하며, 0.25보다 큰 CLS를 빈약한 것으로 간주합니다.
불량한 CLS를 발견하면 다음 중 한 가지 원인이 있을 수 있습니다.
- 저절로 크기가 바뀌는 이미지나 동영상
- 광고 크기 조정
- 늦게 로드되어 의도한 것보다 크거나 작게 표시되는 글꼴
이 메트릭을 개선하려면 다음을 고려하십시오.
- 이미지와 비디오 요소의 정확한 크기를 포함합니다.
- 팝업 광고나 배너를 피하십시오. 대신 광고 슬롯에 대한 큰 공간을 정적으로 예약하십시오.
- 글꼴 표시 및 글꼴 로딩 API 와 같은 도구를 사용하여 스타일이 지정되지 않았거나 보이지 않는 텍스트(FOIT/FOUT)가 깜박이지 않도록 합니다.
Layer0이 각 Core Web Vitals 메트릭의 속도를 최적화하는 방법
수백만 페이지, 수천 개의 SKU, A/B 테스트 및 개인화, 동적 가격 책정, 실시간 재고 조회를 갖춘 크고 복잡한 이커머스 웹사이트는 Layer0을 통해 몇 초 안에 속도를 낼 수 있습니다. 실제로 Layer0은 500ms 미만의 LCP를 보장하는 유일한 플랫폼입니다.
Layer0에서 콘텐츠는 페이지에 즉시 렌더링되거나 페인트되며, 애플리케이션 인식, JavaScript 구성 가능 CDN(CDN-as-JavaScript)으로 인해 즉시 태핑 가능해집니다. 고급 예측 프리페치와 에지 컴퓨팅을 활용하여 동적 콘텐츠(JSON/SSR/HTML)를 요청하기도 전에 엣지에서 사용자의 브라우저로 스트리밍합니다. 이를 통해 사이트를 항상 쇼핑객의 도청 시간보다 5초 앞당길 수 있습니다.
Layer0의 웹사이트는 엣지의 HTML 및 JSON 데이터에 대해 95% 이상의 캐시 적중률을 보이고, 기존 CDN에 대한 사이트는 평균 6%를 보이고 있습니다. 이는 일반적으로 웹사이트를 느리게 만드는 콘텐츠를 전송하는 데 있어 큰 차이를 보입니다.
결론
빠른 페이지 로딩은 쇼핑객을 즐겁게 하는 것과 경쟁사 사이트를 위협하는 것을 구분합니다. Core Web Vitals 가장 큰 Contentful Paint, First Input Delay 및 Cumulative Layout Shift를 측정하여 속도, 상호 작용 및 시각적 안정성에 대한 사용자의 첫인상을 고려합니다. 속도가 LCP의 경우 2.5초, FID의 경우 100ms, CLS의 경우 .1보다 길 경우 사용자와 Google 모두 귀하의 사이트를 느리게 인식한다고 가정할 수 있습니다. 구글은 당신의 순위를 낮출 것이고, 소비자는 반송하고 결코 돌아 오지 않을 것입니다.
불과 몇 달 안에, 가난한 페이지 경험은 브랜드의 명성을 손상시키고 SEO 순위에 영향을 미칠 것입니다. 위에서 제공하는 최적화 전술을 사용하여 힘들게 얻은 SEO를 보호하거나 Layer0 (현재 Edgio)으로 즉시 이동하십시오.
Layer0은 프론트엔드를 개발, 배포, 미리보기, 실험, 모니터링 및 실행할 수 있는 올인원 솔루션입니다. 신발 카니발, 회전 및 1-800-flowers는 1 초 미만의 속도를 제공하고 그 이점을 누리고 있는 전자 상거래 웹 사이트의 몇 가지 예에 불과합니다. Page Experience 업데이트나 사이트 속도를 높이는 방법에 대해 궁금한 점이 있으시면 지금 바로 사이트 속도 전문가와 연락해 주시기 바랍니다.
Google의 다가오는 페이지 경험 업데이트는 CWV(Core Web Vitals)에서 파생된 신호를 공식 순위 알고리즘에 소개합니다. Core Web Vitals는 페이지가 로드되고 대화형이 되며 상호 작용하는 실제 사용자를 위해 시각적으로 안정화되는 속도를 측정하는 지표 집합입니다. Core Web Vitals 테스트에 실패한 웹 사이트는 현재 2021 년 초에 나온 것보다 낮은 순위를 차지할 것입니다.