WordPress의 공통 핵심 웹 바이탈 문제 및 해결 방법

게시 됨: 2023-09-06

핵심 웹 바이탈을 통과하는 데 어려움을 겪고 계십니까?

구글에 따르면:

CrUX 데이터가 있는 모든 웹사이트 중 55.4%는 LCP, FID, CLS 등 세 가지 지표 모두에 대한 적절한 기준점을 충족하지 못합니다.

그러나 CWV 평가를 통과하는 것이 결코 불가능한 임무는 아닙니다.

실제로 이는 3단계 프로세스입니다.

  • 성능 테스트 실행
  • 핵심 웹 바이탈 문제 식별
  • 최적화

그리고 이 글을 다 읽으면 각 단계를 성공적으로 수행하는 데 필요한 모든 지식을 갖추게 될 것입니다.

계속 읽어보세요!

핵심 웹 바이탈에 대한 빠른 요약

다음 Google 성명을 우연히 발견하셨을 것입니다.

"사용자 경험의 품질을 최적화하는 것은 웹 사이트의 장기적인 성공을 위한 열쇠입니다."


그러나 유명한 속담처럼 측정하지 않는 것은 개선할 수 없습니다.

아니면 적어도 CWV 이전에는 사용자 경험을 측정하는 상황이었습니다.

2020년에 Google은 웹사이트 소유자에게 사용자 경험에 직접적인 영향을 미치고 의미하는 확실한 벤치마크 세트를 제공하기 위해 Core Web Vitals를 도입했습니다. 이는 전반적인 웹 상태를 평가할 때 사용자 중심 측정항목을 강조하려는 Google의 광범위한 계획의 일환으로 발표되었습니다.

핵심적으로(말장난 의도) CWV는 웹페이지의 사용자 경험 품질을 조명하는 일련의 성능 측정항목입니다. 여기에는 세 가지 주요 요소가 포함됩니다.

  • 로딩 성능(LCP)
  • 상호작용성(FID)
  • 시각적 안정성(CLS)

LCP(Largest Contentful Paint)는 페이지의 로딩 성능을 측정합니다. 페이지의 기본 콘텐츠를 로드하는 데 걸리는 시간을 측정합니다. 최적의 LCP는 2.5초 미만으로 간주됩니다.

FID(첫 번째 입력 지연)는 사이트의 상호 작용성과 응답성을 평가합니다. 사용자가 페이지와 처음 상호작용(예: 버튼 클릭)한 시점부터 브라우저가 해당 상호작용 처리를 시작하는 순간까지의 시간을 측정합니다. 좋은 FID 점수는 100밀리초 미만입니다.

CLS(Cumulative Layout Shift)는 페이지의 시각적 안정성을 평가합니다. 사용자 입력 없이 발생하는 예상치 못한 레이아웃 변경을 살펴봅니다. 칭찬할만한 CLS 점수는 0.1 미만입니다.

코어 웹 바이탈 임계값

2024년 3월 FID를 대체할 네 번째 지표인 INP(Interaction to Next Paint)도 있습니다.

INP는 전체 페이지 수명 주기 동안 모든 상호 작용의 대기 시간을 기록합니다. 그런 다음 모든 상호 작용에서 가장 긴 지연 시간이 페이지의 INP로 기록됩니다.

INP가 FID를 대체하는 이유는전자가 모든 상호 작용을 측정하여 페이지 응답성을 평가하는 보다 포괄적인 방법을 도입하기 때문입니다.반면 FID는 첫 번째 항목만 설명합니다. 좋은 INP 점수는 200밀리초 미만입니다.

INP는 현재 핵심 웹 바이탈 평가에 직접적인 영향을 미치지 않지만 Google은 이미 Search Console을 통해 INP 문제를 신고하기 시작했습니다.

Google 검색 콘솔 INP 문제

Google에서 직접 INP 점수를 최적화하는 최고의 기술을 알아보세요. 독점 웹 세미나 등록 →

핵심 웹 바이탈 통과: 75번째 백분위수

핵심 웹 바이탈 지표를 논의할 때 Google은 종종 75번째 백분위수를 언급합니다.

이는 사이트가 페이지 방문의 최소 75%에 대해 권장 기준을 충족하거나 초과하는 성능 지표를 목표로 해야 함을 의미합니다.

이는 단지 평균이나 중앙값에만 초점을 맞추는 것이 아니라 사이트와 사용자 상호 작용의 대부분이 만족스럽도록 하는 방법입니다.

75번째 백분위수

핵심 웹 바이탈 문제를 식별하는 도구

핵심 웹 바이탈 최적화 여정의 처음 두 단계에서는 몇 가지 테스트를 실행하고 가능한 원인을 식별해야 합니다.

그 과정에서 활용할 수 있는 몇 가지 인기 있는 도구가 있습니다.

1. PageSpeed ​​인사이트

Google의 PageSpeed ​​Insights는 지난 28일 동안의 페이지별 및 원본 전체 CWV 데이터를 모두 제공합니다. 또한 성과 향상을 위한 실행 가능한 조언도 제공합니다.

친숙한 UX/UI로 인해 가장 널리 사용되는 성능 도구 중 하나입니다. 보고서 페이지에는 필드 데이터를 기반으로 한 핵심 웹 바이탈 평가와 실험실 데이터를 기반으로 한 성능 점수가 포함되어 있습니다.

하단에는 문제 목록과 문제가 영향을 미치는 해당 측정항목을 제공하는 기회 및 진단 위젯이 있습니다.

PSI 보고서 개요


2. 구글 서치 콘솔

Search Console의 핵심 웹 바이탈 보고서에는 개별 URL에 대한 성능 데이터가 포함됩니다. 이는 개선이 필요한 특정 페이지를 식별하는 데 유용한 옵션입니다. PageSpeed ​​Insights와 달리 Search Console 보고에는 이전 성능 데이터가 포함됩니다.

따라서 최적화가 얼마나 영향력이 있는지, 그리고 올바른 방향으로 나아가고 있는지 여부를 추적할 수 있습니다.

Search Console 핵심 웹 바이탈 보고서


Chrome 사용자 경험 보고서(CrUX)

CrUX는 수많은 웹사이트에서 실제 사용자 경험 데이터를 수집하여 실제 사용자 상호 작용을 기반으로 핵심 웹 바이탈에 대한 주요 통찰력을 제공합니다.

두 가지 주요 방법으로 CrUX 데이터 세트를 활용할 수 있습니다.

  • Chrome UX Report API - JavaScript 및 JSON에 익숙한 사용자에게 이상적입니다.
  • BigQuery - Google Cloud 프로젝트가 있고 SQL에 대한 지식이 있는 사용자에게 적합합니다.

이러한 방법은 빠른 PageSpeed ​​Insights 또는 GSC 확인보다 더 많은 노력이 필요하지만 다양한 데이터 분석 및 시각화 옵션을 제공합니다. 예를 들어 BigQuery를 사용하면 데이터 분할 및 다른 데이터 세트와의 통합이 가능합니다.

NitroPack을 사용하여 CWV 전후 결과를 확인하세요. 무료로 웹사이트 테스트 →

WordPress의 가장 일반적인 핵심 웹 바이탈 문제

최대 규모의 콘텐츠가 포함된 페인트(LCP) 문제

이미 알고 있듯이 LCP는 이미지나 텍스트 블록과 같은 기본 콘텐츠 요소가 웹페이지에 표시되는 데 필요한 기간을 측정합니다.

서버에서 초기 HTML 문서를 검색하는 데 지연이 발생하면 LCP 지표가 바람직하지 않은 범위로 밀려날 수 있습니다.

주요 원인은 다음과 같습니다.

1. 예산 호스팅으로 인해 서버 응답 시간이 느림

공유 호스팅이나 과밀한 서버 환경에서 흔히 볼 수 있는 느린 서버 응답 시간은 LCP 점수에 특히 영향을 미칠 수 있습니다.

서버 응답 시간이 지연되면 LCP 요소의 로드도 이에 따라 진행되어 콘텐츠 렌더링이 지연되는 계단식 효과가 발생합니다.

또한 WordPress의 주요 특징은 동적 특성으로, 데이터베이스에서 콘텐츠를 가져와야 하는 경우가 많습니다. 이 데이터베이스가 느린 서버에서 호스팅되는 시나리오에서는 콘텐츠 검색 및 표시가 영향을 받을 수 있으며, 페이지에서 가장 큰 요소의 로드 시간에 더욱 영향을 미칠 수 있습니다.

마지막으로, 예산 호스팅에 의존하면 첫 번째 바이트까지의 시간에 부정적인 영향을 미칠 수 있습니다. TTFB는 서버에서 사용자의 브라우저로 전달되는 정보의 첫 번째 바이트 간격을 측정합니다. 연장된 TTFB는 종종 지연된 LCP의 전조입니다.

첫 번째 바이트까지의 시간

그리고 CPU 및 RAM과 같은 리소스는 공유 호스팅의 여러 웹사이트에 분산되어 있으므로 WordPress 사이트가 효율적인 로딩에 필요한 리소스를 항상 얻지 못할 수도 있습니다.


2. 특정 테마 및 플러그인에 도입된 렌더링 차단 JavaScript 및 CSS

렌더링 차단 리소스는 로드블록 역할을 하는 스크립트와 스타일시트로, 완전히 처리될 때까지 웹페이지 렌더링을 중단합니다.

렌더링 차단 리소스 효과

WordPress 테마 또는 플러그인에 렌더링을 방해하는 요소가 도입되면 본질적으로 핵심 콘텐츠의 가시성이 지연되어 웹사이트가 LCP 평가에 실패하게 됩니다.

따라서 WordPress 사이트에서는 적을수록 좋습니다.

즉, 사이트의 기능과 속도 사이의 적절한 균형을 맞추는 것이 친환경 핵심 웹 바이탈을 달성하는 데 매우 중요합니다.


3. 최적화되지 않은 이미지

웹 연감에 따르면:

“모바일 페이지의 72%와 데스크톱 페이지의 82%가 LCP로 이미지를 가지고 있습니다.”

상위 LCP 요소

고해상도 이미지는 상당한 파일 크기를 가지고 있습니다. 최적화하지 않으면 이러한 대용량 파일은 더 많은 대역폭을 요구하므로 다운로드 및 렌더링 시간이 길어집니다.

또한 최적화되지 않은 이미지로 인해 렌더링 문제가 발생할 수 있습니다. 브라우저가 기본적으로 지원되지 않거나 추가 처리가 필요한 이미지 형식을 발견하는 경우 후속 디코딩으로 인해 전체 렌더링 시간이 추가될 수 있습니다.

CLS(누적 레이아웃 변경) 문제

CLS 점수가 낮으면 페이지의 요소가 페이지 수명 동안 예기치 않게 이동하여 사용자 경험이 저하되고 분노한 클릭이 발생하며 이탈률이 높아질 수 있음을 나타냅니다.

페이지 콘텐츠가 위아래로 점프하는 원인은 다음과 같습니다.

1. 크기를 설정하지 않고 삽입한 이미지

웹 개발에서 종종 간과되는 세부 사항 중 하나는 이미지 크기의 사양입니다.

이미지의너비 및 높이속성을 정의하는 것은 단지 미적인 정확성에 관한 것이 아닙니다. 이는 레이아웃 안정성을 유지하기 위한 실용적인 조치입니다.

이러한 속성이 없으면 브라우저는 초기 렌더링 중에 이미지에 필요한 공간을 할당할 수 있는 통찰력이 부족합니다. 이미지가 완전히 로드될 때까지 이는 중요하지 않은 것처럼 보일 수 있습니다.

이 시점에서 실제 크기가 기본 또는 가정된 공간보다 크면 이미지가 근처 콘텐츠를 옆으로 밀거나 대체하여 갑작스럽고 파괴적인 레이아웃 변화로 이어집니다.

2. 예약된 공간이 없는 광고 게재

광고, 비디오 또는 기타 삽입된 콘텐츠와 같은 동적 요소를 통합합니까?

이 통합에는 일련의 과제가 따른다는 점을 알아야 합니다.

중요한 점은 콘텐츠 크기를 예측할 수 없다는 것입니다. 이러한 요소를 위한 공간을 사전에 예약하지 않으면 요소가 차지할 공간을 고려하지 않고 페이지가 렌더링됩니다.

이러한 요소, 특히 동적 광고가 로드되면 문제가 발생합니다. 실제 크기가 할당되지 않은 공간이나 기본 공간을 초과하면 다른 콘텐츠를 침해하여 이동하게 됩니다.

CLS 예시

3. 최적화되지 않은 글꼴 전달

브랜딩 일관성과 매력적인 디자인을 추구하면서 맞춤형 글꼴은 웹 디자인의 필수 요소가 되었습니다.

그러나 FOIT(Flash of Invisible Text) 및 FOUT(Flash of Unstyled Text)라는 문제가 발생합니다.

사용자 정의 글꼴, 특히 무거운 글꼴이나 외부 소스에서 가져온 글꼴의 경우 완전히 로드되어 표시되기까지 시간적 차이가 있습니다. 이 간격 동안 페이지에 텍스트가 표시되지 않는 FOIT 또는 대체 시스템 글꼴이 채워지는 FOUT이 표시될 수 있습니다.

로드된 사용자 정의 글꼴이 대체 글꼴과 크게 다를 경우 텍스트 레이아웃을 다시 섞습니다. 이러한 갑작스러운 변화는 텍스트 요소를 읽거나 상호 작용하는 데 열중하는 사용자에게 혼란스럽고 좌절감을 줄 수 있습니다.

FOUT 예

첫 번째 입력 지연(FID) 문제

차단된 메인 스레드는 낮은 FID 점수의 주요 원인입니다. 메인 스레드에 대기 중인 광범위한 작업이 있는 경우 사용자 상호 작용은 줄을 서서 기다려야 하므로 감지할 수 있는 지연이 발생합니다.

메인 스레드를 가장 일반적으로 차단하는 리소스는 다음과 같습니다.

1. 과도한 JavaScript 실행

과도한 JavaScript 실행은 주로 JavaScript의 단일 스레드 특성으로 인해 웹 사이트의 FID에 상당한 영향을 미칠 수 있습니다.

브라우저가 광범위한 JavaScript를 처리할 때 사용자 입력 처리를 포함하여 다양한 중요한 작업을 담당하는 기본 스레드를 독점합니다. 결과적으로, 이러한 과도한 실행 중에 사용자가 페이지와 상호 작용하면 응답이 지연됩니다.

2. 리소스 우선순위가 낮음

웹 사이트에 로드된 모든 리소스가 초기 렌더링이나 사용자 상호 작용에 대해 동일한 중요성을 갖는 것은 아닙니다.

중요하지 않은 리소스가 중요한 리소스보다 우선순위가 높거나 적절한 우선순위가 지정되지 않은 경우 페이지의 응답 속도를 늦추는 작업으로 인해 기본 스레드가 바빠질 수 있습니다.

즉, 효과적인 리소스 우선순위 지정은 필수적인 것에 먼저 초점을 맞추고 사용자 경험을 최적화하며 FID 점수를 낮게 유지함으로써 브라우저가 사용자에 대한 응답성을 유지하도록 보장합니다.

3. 과도한 양의 타사 스크립트 실행

타사 플러그인은 웹페이지의 응답성에 큰 영향을 미칠 수 있습니다. 스크립트, 분석 도구, 광고 네트워크 또는 다양한 위젯의 형태로 제공되는 이러한 플러그인은 추가 처리 작업을 도입할 수 있습니다.

게다가 분석, 광고 관리, 양식과 같은 많은 타사 플러그인은 성능에 최적화되어 있지 않습니다. 즉, 비차단 스크립트 실행이나 효율적인 리소스 로딩에 대한 모범 사례를 준수하지 않을 수 있습니다. 일부는 광범위한 JavaScript 실행을 유발하거나 대용량 페이로드를 제공할 수도 있습니다.

또한 타사 스크립트는 외부 서버에 의존하는 경우가 많다는 점을 명심하세요. 서버 응답 시간이 지연되면 대기 시간이 발생할 수도 있습니다.

다음 페인트(INP) 문제에 대한 상호 작용

내년에 INP가 FID를 대체할 것이라는 점을 고려하면 현재 응답성 지표에 부정적인 영향을 미치는 요소가 향후 응답성 지표에도 영향을 미칠 것이라는 점은 놀라운 일이 아닙니다.

즉, 최적화되지 않은 JavaScript 파일 실행으로 인해 긴 작업으로 메인 스레드를 차단하면 INP 점수가 낮아질 수도 있습니다.

하지만 한 가지가 더 있습니다.

1. DOM 크기가 크다

DOM(문서 개체 모델)은 HTML 문서를 구조화된 트리로 표시하는 모든 웹 페이지의 백본입니다. 이 트리의 각 가지는 다양한 객체를 수용하는 노드에서 정점에 이릅니다. 이러한 노드는 요소, 텍스트 콘텐츠 또는 설명과 같은 문서의 다양한 세그먼트를 묘사할 수 있습니다.

DOM 트리

DOM은 웹페이지 기능의 기본이지만 크기로 인해 다음과 같은 이유로 응답성 문제가 발생할 수 있습니다.

DOM이 클수록 브라우저가 페이지를 신속하고 효과적으로 렌더링해야 한다는 요구도 커집니다.

더 간단하게 말하면:

사용자 작업에 대한 신속한 응답을 위해서는 DOM을 필수 요소로만 간소화하는 것이 중요합니다.

"필수"의 정의에 대해 생각해 볼 수도 있습니다. Lighthouse의 기준에 따르면 DOM 크기는노드가 1,400개를 초과하면 부담스러운 것으로 간주됩니다.

핵심 웹 바이탈을 통과한 웹사이트의 45%에 합류하세요. 지금 NitroPack을 설치하세요 →

WordPress에서 핵심 웹 바이탈 문제를 해결하는 방법(체크리스트)

LCP 최적화

LCP는 웹사이트 소유자가 가장 어려움을 겪는 지표입니다. 그렇기 때문에 적용해야 할 여러 가지 최적화가 있습니다.

  • 호스팅 업그레이드 : 공유 호스팅에서 벗어나는 것을 고려해보세요.비용 효율적이지만 전용 또는 클라우드 호스팅 솔루션과 같은 더 비싼 옵션보다 속도가 느릴 수 있습니다. 프리미엄 호스팅 옵션은 더 빠른 응답 시간을 제공하는 경향이 있습니다.
  • CDN(콘텐츠 전송 네트워크)사용: CDN은 전 세계에 위치한 여러 서버에 사이트의 캐시된 버전을 저장합니다. 이를 통해 사용자는 가장 가까운 서버에서 데이터를 수신하여 데이터를 가져오는 데 걸리는 시간을 줄일 수 있습니다.
  • 데이터베이스 최적화 : 여기에는 오래된 데이터 제거, 쿼리 최적화, 효율적인 인덱스 사용이 포함됩니다. WordPress를 사용하는 웹사이트의 경우 WP-Optimize와 같은 플러그인이 데이터베이스 유지 관리에 도움을 줄 수 있습니다.
  • 올바른 이미지 형식 선택 : 이미지에 가장 효율적인 형식을 선택합니다. JPEG는 사진에 이상적이지만 PNG는 투명도가 있는 이미지에 더 좋습니다. WebP와 같은 최신 형식은 더 작은 파일 크기로 고품질의 시각적 요소를 제공할 수 있습니다.
  • 압축 적용 : 눈에 띄는 시각적 저하 없이 파일 크기를 줄이려면 손실 압축을 사용합니다. 품질이 가장 중요한 이미지의 모든 디테일을 보존하려면 무손실 압축을 사용하세요.
  • 이미지 크기 조정: 장치 및 뷰포트에 맞게 조정된 이미지를 제공합니다. CSS나 브라우저 내에서 크기가 조정되는 큰 이미지는 사용하지 마세요. 다양한 화면 해상도에 맞게 다양한 이미지 크기를 생성하고 "srcset" 속성을 사용하여 제공합니다. 또는 이미지 크기를 자동으로 조정하는 NitroPack과 같은 플러그인을 사용해 보세요.
  • JS 및 CSS 파일 축소 : 불필요한 문자, 공백 및 코드를 제거하여 스크립트와 스타일시트의 크기를 줄입니다. Terser(JS용) 및 CSSNano(CSS용)와 같은 도구가 이를 도와줄 수 있습니다.
  • defer 또는 async 사용: 초기 페이지 렌더링에 필요하지 않은 스크립트에는 defer 속성을 사용합니다. 이렇게 하면 HTML이 구문 분석된 후 JS 파일이 순서대로 실행됩니다. 다른 스크립트에 의존하지 않고 초기 렌더링에 중요하지 않은 스크립트에는 async 속성을 사용하세요. 이를 통해 스크립트가 다운로드되는 동안 브라우저가 페이지 구문 분석을 계속할 수 있습니다.
  • 인라인중요 CSS: 초기 페이지 렌더링에 필요한 최소한의 CSS를 식별하고 HTML 내에서 직접 인라인합니다. 이렇게 하면 스크롤 없이 볼 수 있는 콘텐츠에 필수적인 스타일을 즉시 사용할 수 있습니다.

FID 개선

부드럽고 빠른 페이지 응답성을 보장하려면 다음 최적화를 구현하십시오.

  • 웹 작업자 사용 : 복잡한 계산을 웹 작업자로 오프로드합니다. 별도의 스레드에서 백그라운드로 JavaScript를 실행하여 기본 스레드의 응답성을 유지합니다.
  • 중요한 JS 우선순위 지정 : 가장 필수적인 JS 코드를 먼저 로드하고 실행하는 우선순위를 지정합니다. 우선순위가 높은 스크립트에 대해 브라우저에 알리려면 rel="preload"를 사용하세요.
  • 사용하지 않는 CSS 줄이기 : 일반적으로 JavaScript가 주요 악당이지만 CSS는 기본 스레드도 차단합니다. 사용하지 않는 CSS를 줄이면 다운로드해야 하는 총 바이트 수가 줄어듭니다. 더 중요한 것은 브라우저에서 수행할 작업이 적기 때문에 페이지 렌더링을 더 빠르게 시작할 수 있다는 것입니다.
  • 긴 작업 분할: requestIdleCallback()과 같은 기술을 사용하여 긴 작업을 더 작은 비동기 청크로 분할합니다. 이렇게 하면 메인 스레드가 사용자 입력을 더 자주 사용할 수 있게 됩니다.
  • 이벤트 리스너 최적화: 여러 요소에 많은 이벤트 리스너가 있는 경우 이벤트 위임을 고려하세요. 이 방법은 단일 이벤트 리스너를 공통 상위 항목에 연결하여 리스너 수를 줄이고 성능을 향상시킵니다.

CLS 줄이기

사용자가 예상치 못한 변화를 겪을 가능성을 없애려면 다음을 확인하세요.

  • 이미지, 광고 및 삽입의 크기 정의: 항상 이미지의 너비 및 높이 속성을 포함합니다. 이는 이미지가 로드되기 전에 브라우저가 이미지에 정확한 공간을 할당하는 데 도움이 됩니다.
  • 글꼴 표시: 선택 사항 사용: 가장 중요한 글꼴에 대해 link rel=preload와 함께 글꼴 표시: 선택 사항을 사용하는 것은 좋은 CLS를 위한 최상의 전체 글꼴 전략으로 간주됩니다. 선택적 값은 웹 글꼴이 준비되면 레이아웃을 다시 지정하지 않습니다. 동시에 미리 로드된 글꼴은 첫 번째 페인트와 만날 가능성이 높으므로 레이아웃 변경이 발생하지 않습니다.
  • 동적 콘텐츠를 위한 공간 예약 : 광고, iframe 등 동적으로 로드되는 콘텐츠를 위해 항상 적절한 공간을 미리 할당하세요. 이렇게 하면 콘텐츠가 로드될 때 다른 요소가 밀려나는 것을 방지할 수 있습니다.

INP 통과

FID 섹션에 언급된 모든 최적화 기술은 필연적으로 INP 점수를 향상시킵니다. 또한 다음을 구현해야 합니다.

  • DOM 크기 줄이기: 사이트의 DOM 깊이를 줄이려면 잘못 코딩된 플러그인과 테마를 피하고, display:none을 사용하여 원치 않는 요소를 숨기지 말고, 코드를 부풀리는 페이지 빌더에서 벗어나고, JavaScript 기반 DOM 노드를 최소화하세요.
  • 반복 타이머 방지: setTimeout 및 setInterval은 입력 지연에 기여할 수 있는 일반적으로 사용되는 JavaScript 타이머 함수입니다. 코드에서 타이머를 제어할 수 있는 경우 타이머의 필요성을 평가하고 작업량을 최대한 줄이세요.

마무리

긴 최적화 목록을 검토하는 것은 너무 부담스러워서 다음과 같은 생각이 들 수도 있습니다.

핵심 웹 바이탈 평가를 꼭 통과해야 합니까? 그렇게 영향력이 있나요?

그리고 사실은 측정항목 자체에 관한 것이 아닙니다.

예, PSI 테스트를 실행하고 모든 것이 녹색으로 표시되는 것은 언제나 좋은 일입니다. 그리고 그렇습니다. 이는 Google 순위 요소의 일부이므로 SERP 순위가 높아질 수 있습니다.

그러나 실제 가치는 CWV를 전달하면 최고의 사용자 경험을 제공한다는 사실에서 비롯됩니다.

그리고 이는 다음과 같은 실제 결과로 이어집니다.

  • 전환율 증가
  • 반송률 감소
  • 사용자가 즐겨 방문하는 웹사이트 보유

따라서 질문으로 돌아가서 Core Web Vitals를 전달하는 것이 중요하다고 말할 수 있습니다.

그러나 우리는 모든 최적화를 처리하는 것이 쉽지 않다는 점에도 동의합니다.

이것이 바로 우리가 NitroPack을 만든 이유입니다.

NitroPack은전 세계적으로 180,000개 이상의 웹 사이트를 지원하여 뛰어난 핵심 웹 바이탈, 성능 점수 및 사용자 경험을 달성할 수 있도록 하는 경량 웹 성능 솔루션입니다.

35개 이상의 내장 페이지 속도 최적화 기능 덕분에 NitroPack은 핵심 웹 바이탈 최적화 분야의 선두주자입니다.

코어 웹 바이탈 기술 보고서

그리고 가장 좋은 점은 NitroPack을 3분 안에 설정할 수 있다는 것입니다. 기술이나 코딩이 필요하지 않습니다. 플러그인을 설치하고 웹사이트에 연결하면 성능 문제가 해결되는 것을 확인할 수 있습니다.

무료로 NitroPack 테스트 →