비즈니스 의사 결정권자를 위한 코어 웹 바이탈 최적화

비즈니스 의사 결정권자 및 비개발자가 코어 웹 바이탈을 개선하는 방법을 알아보세요.

소개

웹사이트 사용자 경험이 비즈니스 성과에 직접적인 영향을 미친다는 조사 결과가 있습니다. 웹사이트가 더 빠르게 로드되고 사용자에게 더 빠르게 반응하도록 환경을 개선하면 참여도와 전환수가 증가하는 경우가 많습니다. Core Web Vitals는 웹사이트의 사용자 환경을 수치화하여 개선이 필요한 영역을 파악하기 위한 이니셔티브입니다.

하지만 많은 코어 웹 바이탈 문서는 심층적인 기술적 이해와 코드에 대한 완전한 제어력을 갖춘 웹 개발자를 대상으로 합니다. 대부분의 웹사이트는 웹 개발팀 없이도 WordPress, Shopify, Wix 또는 기타 유사한 솔루션을 사용하여 '사이트 작성 도구' 플랫폼을 사용하여 만들 수 있습니다.

전담 팀이나 웹 개발자가 있다고 해도 이들만이 웹 성능을 담당하는 것이 아닙니다. 비즈니스 의사 결정권자는 콘텐츠와 디자인을 결정하는 것부터 웹사이트로 더 많은 트래픽을 유도하기 위한 광고 전략 개발까지 웹사이트 실적에 큰 영향을 미칩니다. 이러한 결정은 종종 웹사이트 실적에 상당한 영향을 미칩니다.

이 가이드는 웹 개발에 대한 심층적인 기술 지식이 없어도 사이트 빌더 및 소유자가 사용자 환경을 최대한 이해하고 개선하는 데 도움이 되는 관련 정보를 제공하는 것을 목표로 합니다.

또한 성능 문제가 발생하면 개발자는 기술적 수정사항을 구현해야 하며, Google의 개발자 중심 가이드가 이러한 작업에 도움을 줄 수 있습니다. 이 가이드는 종합적인 가이드가 아니라 개발 외 환경에서 페이지 성능 저하의 일반적인 근본 원인이 있는 비즈니스 의사 결정권자를 위한 코어 웹 바이탈 이니셔티브에 관한 것입니다. 이 외에도 웹 개발자는 더 발전하기 위해 관여해야 할 수 있습니다.

코어 웹 바이탈이란 무엇인가요?

코어 웹 바이탈은 페이지의 사용자 환경, 특히 페이지가 사용자에게 표시되는 속도를 측정하기 위해 설계된 세 가지 측정항목입니다. 각 형식에는 세 글자 약어가 있습니다.

각 측정항목은 사용자 환경의 다양한 측면을 측정합니다. 또한 Google은 각 측정항목에 권장되는 기준을 제공합니다. 이 기준에서는 사용자 환경이 좋음으로 간주되고 이보다 높으면 나쁨으로 간주됩니다. 이러한 기준점 사이에서 페이지가 개선 필요 범위에 있는 것으로 간주됩니다. 이러한 측정항목에서는 숫자가 낮을수록 좋습니다.

코어 웹 바이탈은 어떻게 측정되나요?

코어 웹 바이탈은 웹사이트의 실제 사용자를 기준으로 측정되며 사용자마다 결과가 다릅니다. 'Google의 생각'이나 '구글봇의 생각'이 아니라 웹사이트의 실제 사용자가 경험한 내용입니다.

일부 사용자는 더 빠른 기기와 더 빠른 네트워크를 사용하게 됩니다. 일부 기기는 속도가 느린 기기나 네트워크를 사용합니다. 어떤 사용자는 사이트에서 더 간단하고 빠른 페이지를, 다른 사용자는 더 복잡하고 느린 페이지를 방문합니다. 이러한 모든 사용자 환경의 결과를 집계하여 전체 웹사이트를 전체적으로 측정합니다.

Google은 데이터 수집에 동의한 Chrome 사용자의 데이터를 Chrome 사용자 환경 보고서 (CrUX)에 표시합니다. 이 보고서는 PageSpeed InsightsGoogle Search Console과 같은 다양한 Google 도구에 제공됩니다.

CrUX는 수백만 개의 인기 웹사이트에서 사용할 수 있지만 모든 웹사이트가 CrUX로 지원되는 것은 아닙니다. 다른 Real User Monitoring (RUM) 도구로 사이트에서 이러한 측정항목을 수집할 수도 있습니다.

내 사이트의 코어 웹 바이탈을 찾으려면 어떻게 해야 하나요?

코어 웹 바이탈 측정항목을 표시하는 다양한 도구는 Google 및 서드 파티에서 제공합니다. 이 게시물에서는 사이트의 코어 웹 바이탈을 빠르게 확인할 수 있는 두 가지 도구를 소개합니다. 코어 웹 바이탈을 해결하기 위한 워크플로를 비롯한 다른 Google 도구에 관한 자세한 내용은 Google 도구를 사용한 코어 웹 바이탈 워크플로 게시물을 참고하세요.

플랫폼에서 통합 RUM 솔루션을 제공하는 경우 사이트의 페이지에 관해 훨씬 더 자세한 정보를 제공하거나, 특정 페이지를 상세히 살펴보거나 사용자를 분류하여 문제를 이해하고 식별하는 데 도움이 될 수 있습니다.

PageSpeed Insights

설정 없이 빠르게 보려면 PageSpeed Insights (PSI)를 사용하세요. URL을 입력하고 분석을 클릭합니다. 사이트가 CrUX에 포함되어 있으면 '실제 사용자의 경험 살펴보기' 섹션이 빠르게 표시됩니다.

PageSpeed Insights에서 URL의 코어 웹 바이탈의 CrUX 데이터를 묘사하는 방식을 보여주는 스크린샷 각 코어 웹 바이탈은 별도로 표시되며, 지난 28일 동안의 각 코어 웹 바이탈은 '좋음', '개선 필요', '나쁨' 기준점으로 그룹화됩니다.
PageSpeed Insights에서는 실제 사용자가 경험한 코어 웹 바이탈을 보여줍니다.

실제 Chrome 사용자가 지난 28일 동안 웹사이트를 얼마나 경험했는지 보여줍니다. 상단에 3개의 코어 웹 바이탈이 표시되며, 그 아래에는 대기 중인 INP 측정항목을 비롯한 기타 지원 측정항목이 표시됩니다. 코어 웹 바이탈만 페이지 상단의 전체 통과/실패 평가에 포함되지만 다른 측정항목은 다음 섹션에서 설명하는 것처럼 코어 웹 바이탈 관련 문제를 해결하는 데 유용할 수 있습니다.

이 섹션 상단의 버튼을 사용하여 모바일 보기와 데스크톱 보기 간에 전환할 수 있습니다. 오른쪽 상단의 전환 버튼을 사용하여 이 URL과 해당 출처의 모든 데이터를 전환할 수도 있습니다. 두 출처의 데이터가 모두 있습니다.

이러한 수치는 사이트의 실적과 개선의 여지가 있는 측정항목, 기기 유형을 개괄적으로 나타내야 합니다.

Google Search Console

Google Search Console (GSC)은 사이트 소유자 전용이므로, 사용하려면 사이트 소유권 등록 및 확인이 필요합니다. Google 검색에서 사이트를 보는 방식에 관한 세부정보를 제공합니다.

PageSpeed Insights와 달리 GSC는 Google 검색이 사이트에서 인식하는 모든 페이지를 나열하고 모든 페이지에 관한 코어 웹 바이탈 세부정보를 제공합니다.

Search Console의 코어 웹 바이탈 보고서 스크린샷 보고서는 데스크톱과 모바일 카테고리로 구분되며, 시간 경과에 따른 '좋음', '개선이 필요함', '나쁨' 카테고리로 코어 웹 바이탈이 있는 페이지의 분포를 자세히 보여주는 선 그래프가 있습니다.
Google Search Console 코어 웹 바이탈 보고서

페이지가 URL 그룹으로 수집되어 특정 카테고리의 페이지 (예: 제품 세부정보 페이지, 블로그 페이지 등)에 코어 웹 바이탈 문제가 있는지 쉽게 확인할 수 있습니다. 이러한 페이지는 일반적으로 유사한 기술이나 템플릿을 기반으로 제작되기 때문에 이러한 페이지에 문제를 일으키는 일반적인 원인이 있을 수 있습니다.

사이트 작성 도구의 일반적인 코어 웹 바이탈 문제

대부분의 성능 문제는 개발자가 기술적 수정사항을 구현해야 하며, 개발자 중심 가이드는 이를 해결하는 데 도움이 될 수 있습니다. 이 섹션에서는 비즈니스 의사 결정권자가 이러한 측정항목을 개선하기 위해 도움을 줄 수 있는 개발자 이외의 일반적인 문제에 대해 설명합니다.

'비개발자'란 사이트의 실제 코딩 방법에 대한 제어 권한이 제한적인 사이트 제작 도구 플랫폼 사용자, 또는 사이트 디자인을 결정하거나 예산의 우선순위를 결정하는 데 도움을 줄 수 있는 비즈니스 의사 결정권자를 말합니다.

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

LCP는 링크가 클릭된 시점부터 브라우저에 가장 큰 콘텐츠 (일반적으로 배너 이미지 또는 광고 제목)가 나타날 때까지의 시간을 측정하여 웹페이지의 로드 속도를 측정합니다.

LCP 이미지가 초록색으로 강조 표시된 사이트 홈페이지의 스크린샷
LCP 요소는 페이지가 로드될 때 가장 큰 요소로, 이 예에서는 녹색으로 강조표시되어 있습니다.

만족스러운 페이지 경험을 위해 웹페이지에서는 링크 클릭 후 2.5초 이내에 이러한 콘텐츠가 표시되는 것을 목표로 해야 합니다. 4초 이상 소요되면 나쁜 경험으로 간주됩니다.

비즈니스 의사 결정권자가 영향을 미칠 수 있는 LCP에 영향을 주는 몇 가지 일반적인 문제는 다음 섹션에서 다룹니다.

페이지 로드 시작 지연

Google에서는 페이지 자체의 로드 시간을 개선하려고 하는 경우가 많지만, 로딩을 시작하기도 전에 지연이 발생하는 경우가 많습니다. 웹사이트가 몇 초 동안 다운로드되지 않으면 2.5초 미만의 LCP를 유지할 수 없습니다.

TTFB (Time to First Byte)란 웹페이지의 첫 부분을 다운로드하는 데 걸리는 시간입니다. PageSpeed Insights에 큰 TTFB 진단 측정항목이 빨간색 또는 황색으로 표시되는 경우, 이 문제를 해결하는 것이 중요하며, LCP에 직접적인 영향을 미칩니다.

시청자 이해하기

TTFB 문제의 경우 시청자층을 이해하는 것이 중요합니다. 웹사이트가 한 국가에서 호스팅되지만 전 세계 잠재고객을 대상으로 한다면 웹사이트 사용자와 웹 서버 간의 지리적 근접성이 페이지 TTFB에 영향을 주는 요인이 됩니다. 콘텐츠 전송 네트워크 (CDN)를 사용하면 전 세계에서 사이트 사본을 캐시하여 사용자와 더 가까운 곳에 저장할 수 있습니다. 많은 호스팅 업체에서 서비스의 일부로 CDN을 포함하므로 이를 자동으로 처리해 드립니다. 사이트가 이러한 경우에 해당하는지 확인하세요. 일부 플랫폼은 더 높은 유료 등급에 더 많은 CDN 위치가 포함된 다양한 등급의 서비스를 제공합니다. 글로벌 기업은 이러한 경우 상위 Tier를 고려해야 합니다.

리디렉션 최소화

TTFB가 느려지는 또 다른 일반적인 원인은 리디렉션입니다. 광고 캠페인을 운영하거나 이메일 커뮤니케이션을 보낼 때 링크 축약기를 여러 개 사용하거나 리디렉션해야 하는 URL을 포함하여 리디렉션 수를 최소화하세요. 예를 들어 www.example.com/blog로 리디렉션해야 하는 캠페인에서 example.com/blog를 사용하다가 https://www.example.com/blog로 리디렉션되면 페이지의 TTFB에 시간이 추가됩니다. 마케팅 캠페인에서 가능한 한 최소한의 리디렉션을 사용해야 합니다.

광고 캠페인이 올바른 잠재고객을 타겟팅하도록 합니다.

또한 광고 캠페인이 잠재고객을 효과적으로 타겟팅하고 있는지 확인합니다. 제품을 배송할 수 없는 전 세계 사용자들로부터 많은 신규 트래픽이 발생하는 것은 광고비 낭비일 뿐 아니라 웹사이트 실적에도 부정적인 영향을 미칩니다.

URL 매개변수가 웹 성능에 영향을 줄 수 있음

UTM 매개변수와 같은 URL 매개변수는 마케팅 캠페인에 자주 사용됩니다. 이렇게 하면 매번 동일한 페이지가 게재되더라도 각 URL이 고유한 페이지처럼 보일 수 있기 때문에 인프라의 캐싱 효과가 떨어질 수 있습니다. UTM 매개변수를 사용하는 경우 CDN 제공업체 또는 인프라팀에 문의하여 이러한 URL 매개변수가 캐싱 인프라에서 무시되도록 해야 캠페인이 이미 캐시된 페이지의 이점을 누릴 수 있습니다.

미디어는 성능에 큰 비용이 들 수 있음

미디어가 페이지에 미치는 영향을 고려하세요. 일반적으로 이미지, 동영상과 같은 미디어는 크기가 훨씬 커서 텍스트보다 다운로드 시간이 더 오래 걸립니다. 이로 인해 나머지 페이지 로드도 느려질 수 있습니다. LCP 요소가 텍스트가 아닌 미디어인 경우 특히 중요합니다. LCP 요소는 웹페이지의 약 80%에 있는 이미지이므로 미디어가 사이트에 미치는 영향을 고려해야 합니다.

미디어 애셋은 풍부한 시각적 경험으로 사용자를 위해 텍스트 형식 사이트보다 훨씬 더 참여를 유도할 수 있습니다. 따라서 미디어를 삭제하는 것은 거의 옵션이지만 미디어 비용 및 이를 줄이는 방법을 알고 있으면 성능 문제를 최소화할 수 있습니다.

캐러셀 피하기

여러 이미지로 구성된 캐러셀은 최적의 방식으로 구현되지 않을 경우 여러 이미지를 동시에 다운로드해야 할 수 있으므로 페이지의 전체 로드 시간에 영향을 줄 수 있습니다. 또한 캐러셀은 보편적임에도 불구하고 우수한 사용자 환경을 제공하지 않는 경우가 많으므로 사이트에서 사용하기 전에 신중하게 생각하세요.

웹에 최적화된 이미지 사용

다음은 미디어 애셋의 크기입니다. 웹에 있는 많은 이미지가 너무 높은 해상도로 제공됩니다. 미디어 파트너 또는 디자인 대행사가 전체 크기 인쇄 품질 이미지가 아닌 웹에 최적화된 이미지를 제공하도록 합니다. TinyJPG와 같은 서비스를 사용하면 이미지를 업로드하기 전에 이미지에서 불필요한 데이터를 신속하게 삭제할 수 있습니다. 많은 웹 플랫폼은 업로드 시 이미지를 자동으로 최적화하려고 시도하지만 사용자의 기기에 이미지가 표시될 크기를 모르기 때문에 더 작은 이미지를 제공하면 상당한 이점을 얻을 수 있습니다.

동영상에 특히 주의하세요

동영상을 사용할 때는 특히 주의하세요. 동영상은 웹사이트에서 다운로드하고 표시하는 데 가장 크고, 따라서 가장 느린 콘텐츠 중 일부이므로 과도하게 사용하지 않는 것이 좋습니다. 웹페이지 상단에서 사용하지 말고 페이지 아래쪽에 위치하도록 저장하세요. 이렇게 하면 비용이 적게 드는 콘텐츠를 빠르게 로드하여 사용자에게 더 나은 로드 경험을 제공하고 LCP에 영향을 주지 않습니다.

A/B 테스트

많은 기업에서 웹사이트 변경을 실험하기 위해 A/B 테스트를 수행합니다. 이러한 기능을 구현하는 방법은 LCP에 큰 영향을 미칠 수 있습니다.

많은 A/B 테스트 솔루션은 웹사이트가 사용자에게 처음 표시되는 시점부터 테스트의 변경사항이 적용될 때까지 지연시킵니다. 이렇게 하면 웹사이트의 원본이 표시되지 않지만 사용자가 웹사이트를 제대로 볼 수 없게 됩니다. 다른 솔루션은 이러한 지연을 방지하기 위해 서버 측에 적용됩니다. 시간을 내어 A/B 테스트가 어떻게 수행되는지, 그리고 이러한 지연이 발생하는지 여부를 파악해야 합니다. 또한 가능하면 서버 측 A/B 테스트 솔루션을 사용하는 것이 좋습니다.

A/B 테스트는 새로운 변경사항을 적용하기 전에 귀중한 피드백을 제공할 수 있지만, 페이지 성능에 대한 비용을 이러한 잠재적 이점과 비교해야 합니다.

인프라에 관계없이 A/B 테스트를 실행하는 모든 사용자는 항상 다음 권장사항을 염두에 두어야 합니다.

  • 대부분의 페이지가 A/B 테스트를 실행하지 않는 경우 A/B 테스트 도구를 모든 페이지를 지연시키지 않고 테스트에 포함된 페이지로만 제한합니다.
  • 대다수 사용자에게 영향을 주지 않도록 일부 사용자로 A/B 테스트를 제한합니다.
  • A/B 테스트는 확실한 결과를 제공하는 데 필요한 최소 시간으로 제한합니다. A/B 테스트를 오래 실행할수록 사용자의 페이지 성능이 저하되는 시간이 길어질 수 있습니다.
  • 무엇보다도 더 이상 필요하지 않은 A/B 테스트 실험을 삭제해야 합니다.

레이아웃 변경 횟수 (CLS) 문제

CLS는 페이지의 시각적 안정성, 즉 콘텐츠가 로드될 때 페이지의 콘텐츠가 이동하는 정도를 측정합니다. 이는 사용자가 웹페이지를 읽기 시작했지만 이후 더 많은 콘텐츠나 광고 슬롯이 배치됨에 따라 놓친 경우 산만해질 수 있습니다. 또한 페이지 레이아웃이 과도하게 변경되는 경우 사용자가 의도치 않게 잘못된 콘텐츠를 클릭할 수 있습니다. 나중에 로드되며 초기 페이지 콘텐츠의 일부를 이동할 수 있는 동적 콘텐츠에 특히 주의하세요.

레이아웃 불안정이 사용자에게 어떤 부정적인 영향을 미칠 수 있는지 보여주는 스크린캐스트

이는 콘텐츠가 얼마나 많이 변경되고 얼마나 이동했는지를 계산하는 수학 공식으로 측정됩니다. 값이 0.1 이하인 경우 좋음으로, 값이 0.25를 초과하는 경우 나쁨으로 표시되는 단위 없는 분수로 표시됩니다.

비즈니스 의사 결정권자가 영향을 줄 수 있는 CLS에 영향을 주는 몇 가지 일반적인 문제는 다음 섹션에서 다룹니다.

페이지를 아래로 스크롤할 때 이미지가 어떻게 로드되는지 확인

많은 템플릿은 초기 페이지 로드 시 화면에 표시되는 이미지에 더 많은 리소스를 제공하기 위해 페이지 아래쪽에서 이미지를 로드하지 않습니다. 그런 다음 사용자가 아래로 스크롤하면 이미지가 로드됩니다. 이러한 이미지 로드 기법을 지연 로드라고 합니다.

페이지 템플릿은 지연 로드 이미지를 위한 공간을 예약하여 사용자가 이미지가 로드되기 전에 매우 빠르게 스크롤하더라도 그 주변의 콘텐츠가 이동하지 않도록 해야 합니다. 사용 중인 템플릿 또는 플랫폼에서 이 기능이 작동하지 않는 경우 이를 지원하는 템플릿으로 전환하는 것이 좋습니다.

콘텐츠 중간에 광고를 게재할 때 주의하기

대부분의 경우 이전 섹션에서 설명한 이미지보다 로드 시간이 조금 더 오래 걸리기 때문에 콘텐츠 중간에 삽입되는 광고는 콘텐츠를 아래로 밀어낼 위험이 있습니다. 기본 페이지 콘텐츠의 측면에 이러한 태그를 배치하는 것이 이러한 위험을 줄이는 일반적인 패턴입니다. 실제로 이를 구현하는 방법은 특정 플랫폼과 사이트를 만드는 데 사용하는 템플릿에 따라 다릅니다.

페이지 상단에 동적 콘텐츠 추가 방지

페이지 로드 후에는 페이지 상단에 쿠키 배너, 특별 이벤트 등의 알림이나 배너를 추가하지 마세요. 대신 기본 콘텐츠 위에 알림 및 배너를 오버레이하면 페이지 콘텐츠가 이동하지 않습니다. 이전 섹션과 마찬가지로 여기서 사용할 수 있는 옵션은 페이지에 사용된 플랫폼과 템플릿에 따라 다릅니다.

다음 페인트와의 상호작용 (INP) 문제

INP는 페이지의 응답성을 측정하여 페이지가 클릭, 탭, 키보드 입력과 같은 상호작용에 빠르게 반응하는지 평가합니다. 사용자 입력에 빠르게 반응하지 않는 페이지는 종종 느려지고 사용자에게 불편을 줄 수 있습니다.

낮은 응답성과 양호한 응답성의 예입니다. 왼쪽에서 장기 작업은 아코디언이 열리지 않도록 차단합니다. 이로 인해 사용자는 사용 환경에 문제가 있는 것으로 생각하고 여러 번 클릭합니다. 기본 스레드가 따라잡을 때 지연된 입력을 처리하여 아코디언이 예기치 않게 열리고 닫힙니다.

INP는 페이지의 수명 동안 자격이 있는 모든 상호작용 전체를 측정하고 최악의 상호작용을 보고합니다. INP의 양호 기준은 200밀리초이고 불량 임계값은 500밀리초입니다. INP는 FID를 개선하여 응답성을 더 잘 측정하므로 응답성을 측정하는 Core Web Vital로 FID를 대체하게 되었습니다.

반응성 측정항목, 특히 INP는 최적화하기가 까다롭습니다. 이러한 측정항목이 나쁨 기준점에 해당하는 경우, 이는 일반적으로 과도한 작업을 시도하는 웹페이지에서 상호작용이 지연되기 때문입니다. 따라서 여기서 주된 해결책은 불필요한 코드를 삭제하여 더 가벼운 페이지를 만드는 것입니다.

비즈니스 의사 결정권자가 영향을 줄 수 있는 INP에 영향을 주는 몇 가지 일반적인 문제는 다음 섹션에서 다룹니다.

봄맞이 청소를 하세요.

사이트에 추가된 플러그인과 위젯을 검토하고 더 이상 사용하지 않는 경우 삭제하세요. 플러그인을 추가하여 사용해 보는 것은 쉽지만, 도움이 되지 않으면 나중에 플러그인을 삭제하는 것을 잊어버리기도 합니다. 이로 인해 상호작용 속도가 느려지지만 다른 여러 상호작용에 비해 상대적으로 간단한 최적화가 가능합니다.

마찬가지로 마케팅 캠페인에 태그 관리자를 사용하고 있다면 이전 캠페인을 삭제해야 합니다. 코드가 더 이상 실행되지 않더라도 만료된 마케팅 캠페인의 코드를 각 페이지에 다운로드하고 컴파일해야 하므로 초기 페이지 로드 시 사용자 상호작용 속도가 느려질 수 있습니다.

비싼 위젯과 플러그인 사용 자제

계산 비용이 많이 드는 위젯과 플러그인은 보기 좋게 보일 수도 있지만, 사용자 환경을 개선하나요, 아니면 오히려 더 악화시킬까요? PageSpeed Insights의 성능 문제 진단/Lighthouse 보고서를 사용하면 웹사이트 성능에 눈에 띄는 영향을 미치는 자바스크립트를 파악하는 데 도움이 될 수 있습니다.

필요한 페이지에만 위젯을 제한하는 것이 이상적입니다. 문의하기 페이지에서 Google 지도 삽입만 사용하는 경우 응답 문제를 일으킬 수 있는 모든 페이지에 위젯을 로드할 필요가 없습니다.

특히 모바일에서 광고 수 고려하기

광고는 많은 비즈니스에서 훌륭한 수익 창출 전략이지만, 복잡하고 리소스가 많이 필요한 경우가 많습니다. 광고가 많을수록 리소스 집약도가 높아 페이지 속도를 저하시킬 수 있습니다. 특히 모바일 기기에서는 처리 능력 메모리가 데스크톱이나 노트북 기기만큼 좋지 않은 경우가 많습니다.

수익 창출과 실적의 균형

수익 창출과 실적의 균형을 평가해 주세요. 사용자가 만족스럽지 못한 경험으로 인해 일찍 이탈하는 경우 추가 광고로 인해 발생하는 수익보다 더 많은 수익이 발생할 수 있습니다.

과도한 페이지 크기 피하기

크고 복잡한 페이지는 표시하는 데 더 많은 처리 시간이 필요합니다. 예를 들어 1,000개의 서로 다른 제품이 있는 제품 갤러리가 있는 경우 사용자의 브라우저 창에 표시되는 데 시간이 오래 걸립니다. 이 시간을 줄이기 위해 페이지를 페이지로 나누는 시점을 고려하세요.

추가 지원을 받으려면 어떻게 해야 하나요?

이 게시물에서는 실적에 영향을 줄 수 있는 비즈니스 소유자가 고려할 수 있는 일반적인 고려사항을 소개합니다. 이 외에도 웹 개발자에게 문의하여 웹사이트 성능을 개선하기 위해 취할 수 있는 조치에 대해 더 많은 정보를 얻어야 할 수 있습니다.

플랫폼별 정보

대부분의 플랫폼은 웹 성능을 매우 중요하게 생각하며, 웹 성능을 개선하는 방법에 관한 플랫폼별 전담 조언을 제공할 수도 있습니다. 또한 이 플랫폼을 사용하는 동안 웹 실적 전담팀에 문의하면 사이트 개선 방법에 대한 조언을 받을 수 있습니다.

또한 Lighthouse는 스택 팩 기능을 사용하여 플랫폼별 정보를 표시하므로 지원되는 플랫폼 사용자에게 적절한 조언을 제공할 수 있습니다.

플랫폼은 시간이 지남에 따라 지속적으로 개선되며 많은 플랫폼이 현재 성능과 코어 웹 바이탈에 집중하고 있습니다. 플랫폼 개발자가 최근에 개선한 개선의 이점을 누릴 수 있도록 플랫폼을 최신 상태로 유지하세요.

이 방법은 플랫폼 제공자가 플랫폼 업데이트를 포함하여 플랫폼을 자동으로 관리하는 호스팅된 플랫폼을 사용하는 경우에 가장 쉽습니다. 플랫폼을 직접 호스팅하는 경우(예: 자체 서버에 로컬 WordPress를 설치하는 경우) 플랫폼을 정기적으로 업데이트하면 사이트 개발자가 플랫폼 개발자가 구현한 개선 사항의 이점을 누릴 수 있습니다. 비즈니스는 이러한 유지에 우선순위를 두거나 이를 관리하는 서비스를 선택해야 합니다.

웹 개발자와 소통하기

웹 성능에 대한 전문 지식을 갖춘 웹 개발자는 비즈니스 소유자보다 더 많은 문제를 해결할 수 있습니다. 이미 웹 개발자를 고용하여 사이트를 처음 구축했거나, 주기적인 변경을 위해, 전담 개발팀이 있거나, 관여할 개발자 (웹 성능 전문성을 갖춘 개발자)를 찾아야 할 수 있습니다.

위의 제안사항이 웹사이트 성능 문제를 해결하는 데 충분하지 않다면 개발자에게 문의하세요. 이전 사례를 통해 개발자와 협력하여 비즈니스 우선순위와 개발 결정 사이의 균형을 맞추는 것이 웹사이트에 적합한 솔루션을 찾는 것이 중요하다는 것을 알 수 있기를 바랍니다.

웹 성능은 일회성 작업이 아닙니다. 우수한 웹사이트 실적을 유지하려면 기능을 개선한 후에도 웹사이트가 저하되지 않도록 정기적으로 모니터링 및 유지보수가 필요합니다.

결론

웹사이트는 보통 고객과의 비즈니스의 첫 시작점이며, 광고주는 웹사이트를 통해 고객에게 만족스러운 경험을 제공하고자 합니다. 이는 비즈니스에 대한 첫인상을 주는 신규 방문자뿐만 아니라 재방문자 및 충성도 높은 고객 모두에 적용됩니다. 단, 재방문자와 충성도가 높은 고객에게는 부정적인 인상을 남길 수 있는 불만이 없는 원활한 경험을 최대한 제공해야 합니다. 코어 웹 바이탈은 사용자 환경을 측정하는 지표 중 하나로, Google에서는 이를 사이트에서 고려하는 것을 권장합니다. 웹에는 많은 기능이 있기 때문에 사용자가 다른 웹사이트를 보고 싫어하는 경우에도 쉽게 다른 웹사이트를 사용해 볼 수 있습니다.

동시에 코어 웹 바이탈은 웹사이트를 측정하는 하나의 지표에 불과합니다. 기업은 웹사이트에 얼마를 투자할지, 그리고 투자를 통해 어떤 수익을 거둘 수 있을지 스스로 결정해야 합니다.

감사의 말

썸네일 이미지: 카를로스 무자, Unsplash