Core Web Vitals와 실제 데이터를 활용해 웹사이트 속도를 높이는 방법

웹사이트는 흔히 잘못된 순서로 속도를 높입니다. 누군가 최적화 플러그인을 설치하고 모든 설정을 활성화한 다음, 왜 양식이 더 이상 작동하지 않는지 찾기 시작합니다. 올바른 순서는 측정, 가설 수립, 한 가지 변경, 기능 확인, 그리고 재측정입니다.

이전 버전에서는 다른 사람의 스크립트를 로컬에서 프록시하거나 일반적인 AMP 및 PWA를 배포하는 등, 더 이상 권장하지 않는 접근 방식도 설명했습니다. 이런 방식은 실험실 환경에서 부분적인 개선을 가져왔지만, 오래된 코드로 인한 위험과 업데이트 중단, 더 복잡한 유지보수를 추가했습니다. 현대적인 웹사이트는 핵심 버전 자체가 빨라야 합니다.

오늘 측정해야 할 항목

Core Web Vitals에서 Google은 세 가지 안정적인 지표를 사용합니다:

LCP: 주요 콘텐츠 로딩 시간입니다. 양호한 값은 2.5 초 이하입니다.
INP: 상호작용에 대한 응답 시간입니다. 양호한 값은 200 밀리초 미만입니다.
CLS: 예상하지 못한 레이아웃 이동입니다. 양호한 값은 0.1 이하입니다.

임계값은 75 백분위수에 적용되며, 공식 Google 검색을 위한 Core Web Vitals 개요에 정리되어 있습니다. Search Console 또는 CrUX에서 확인한 실제 방문자 데이터가 노트북에서 한 번 실행한 실험실 테스트보다 우선합니다.

실험실 도구도 여전히 중요합니다. 이 도구는 워터폴, 메인 스레드, 사용되지 않는 코드와 구체적인 수정 후보를 보여줍니다. 필드 데이터는 문제가 존재한다는 사실을 알려주고, 실험실 데이터는 그 이유를 설명하는 데 도움을 줍니다.

먼저 문제의 범위를 정의하세요

모바일과 데스크톱을 비교합니다.
홈페이지, 글, 서비스, 목록, 양식, 온라인 상점 등 템플릿을 구분합니다.
빠른 국가와 느린 국가, 기기 및 트래픽 소스를 확인합니다.
필드 데이터가 좋지 않은 URL 그룹을 찾습니다.
대표 페이지에 대해 재현 가능한 실험실 추적 기록을 수집합니다.

빠른 홈페이지 하나가 빠른 웹사이트 전체를 의미하지는 않습니다. 오래된 휴대전화에서 느린 방문이 한 번 발생했다고 해서 시스템 전체를 다시 작성해야 하는 것도 아닙니다.

가장 일반적으로 효과가 큰 개선 작업

1. 서버와 HTML

첫 번째 바이트까지 걸리는 시간을 측정하고 DNS, 연결, 서버 대기 및 리디렉션으로 나누어 확인합니다. 긴 대기 시간은 호스팅, 데이터베이스, 캐시되지 않은 페이지, 느린 API 또는 리디렉션 체인에서 발생할 수 있습니다. 공개 콘텐츠에는 적절한 페이지 캐시를 활성화하고, 필요한 경우 객체 캐시를 사용합니다. 로그인 사용자, 장바구니 및 개인화 콘텐츠는 캐시에서 올바르게 제외합니다.

2. 주요 이미지

LCP는 주로 대표 이미지입니다. 표시 크기에 맞는 크기로 제공하고 srcset, 압축 및 적절한 대체 형식과 함께 최신 WebP 또는 AVIF를 사용합니다. 주요 이미지에는 지연 로딩을 적용하지 말고, 첫 화면 아래의 이미지에 적용합니다. 이미지의 너비와 높이를 지정해 브라우저가 공간을 미리 확보하도록 하면 CLS를 낮게 유지할 수 있습니다.

3. CSS와 글꼴

사용하지 않는 스타일은 신중하게 제거하고 중요한 CSS는 작게 유지합니다. 필요한 두께와 문자 집합으로 글꼴을 제한하고, 로컬 파일은 장기간 캐시하며, 실제로 초기에 필요한 글꼴만 미리 로드합니다. 글꼴 열 개를 미리 로드하면 또 다른 대기열만 만들어집니다.

4. JavaScript와 상호작용

큰 번들을 분할하고 중요하지 않은 코드는 지연 실행하며, 필요하고 동의가 허용되는 경우에만 타사 코드를 로드합니다. async와 defer는 마법이 아니므로 스크립트 순서와 의존성을 테스트해야 합니다. 메인 스레드의 긴 작업은 나누고, 분석 도구 때문에 클릭이 지연되도록 만들지 않습니다.

5. 타사 도구

채팅, 히트맵, 광고 픽셀, 동영상 및 A/B 테스트 도구는 네트워크 요청과 프로세서 작업을 추가합니다. 모든 스크립트에는 담당자와 비즈니스상 이유가 있어야 합니다. 설치 가이드가 가장 짧다는 이유만으로 헤더에서 동기식으로 로드하지 마세요. 분석 도구는 Google Tag Manager를 통해 관리할 수 있지만, 컨테이너 자체가 성능 문제를 해결해 주지는 않습니다.

WordPress: 계층은 줄이고 제어력은 높이기

WordPress 문서는 호스팅, 플러그인의 수와 품질, 이미지, 캐시 및 전송 네트워크를 통해 성능 문제를 해결할 것을 권장합니다. 최적화 개요와 캐시에 대한 별도의 설명을 읽어보세요.

먼저 스테이징 환경에서 WordPress, PHP, 테마 및 플러그인을 업데이트합니다.
사용하지 않는 플러그인과 서로 겹치는 캐시 또는 축소 도구를 제거합니다.
데이터베이스 쿼리와 느린 외부 호출을 프로파일링합니다.
데이터베이스 유지보수를 계획하되, 리비전이나 메타데이터를 무작정 삭제하지 않습니다.
각 최적화 후 양식, 검색, 로그인 및 구매 흐름을 테스트합니다.

최고의 WordPress 플러그인에서 합리적인 추가 기능 선택에 대해 설명합니다.

하지 말아야 할 일

점수를 높이기 위해 다른 사람의 분석 또는 광고 스크립트를 서버에 다운로드하지 마세요. 보안 및 기능 업데이트를 잃을 수 있습니다.
변경되는 파일의 이름을 버전 관리하지 않은 채 1년 동안 캐시하도록 설정하지 마세요.
모든 템플릿을 테스트하지 않고 자동화된 보고서에 따라 CSS나 JavaScript를 제거하지 마세요.
성공 여부를 Lighthouse만으로 판단하지 마세요. Google은 좋은 Core Web Vitals만으로 높은 순위나 훌륭한 사용자 경험이 보장되지는 않는다고 명확히 설명합니다.
고객에게 필요한 콘텐츠나 기능을 숨겨 웹사이트 속도를 높이지 마세요.

4주 계획

1 주 차: 필드 데이터 기준선, 실험실 측정 및 템플릿 목록을 작성합니다.
2 주차: 서버, 캐시, 리디렉션 및 가장 큰 LCP 리소스를 점검합니다.
3 주차: 이미지, 글꼴, CSS, JavaScript 및 타사 도구를 점검합니다.
4 주 차: 회귀 테스트, 재측정, 모니터링 및 문서화를 진행합니다.

각 변경 사항에 대해 날짜, URL, 변경 전후의 지표, 기능적 영향 및 롤백 방법을 기록합니다. 전환율, 양식 완료율 및 오류도 추적해야 합니다. 더 빨라졌지만 판매가 줄어든 페이지는 최적화가 끝난 것이 아닙니다.

기술 감사와 GA4를 통해 웹사이트의 기술적 기반과 분석 도구를 먼저 점검하세요. 영향과 비용을 기준으로 수정 작업의 우선순위를 정해야 한다면 문의를 통해 연락해 주세요.