라이트하우스 점수가 거짓인 이유: 워드프레스 사이트 실전 성능 최적화

Source: Dev.to

Lighthouse는 클라이언트가 웹사이트가 느리다고 생각할 때 가장 먼저 보내는 자료입니다. Performance 탭의 스크린샷, 빨간색·노란색 구역에 표시된 점수, 그리고 “이거 고쳐줄 수 있나요?”라는 질문이죠.
솔직히 답하자면: “고친다는 것이 무엇을 의미하느냐에 달려 있습니다.”

Lighthouse는 구글 서버에서 실행되는 헤드리스 Chrome 인스턴스를 이용해 제한된 모바일 연결 환경을 시뮬레이션한 결과를 측정합니다. 매우 유용한 진단 도구이지만, 실제 사용자에게는 전혀 의미가 없는 방식으로 점수를 조작할 수도 있습니다.

이 가이드는 Lighthouse가 보고하는 내용과 실제 방문자에게 빠른 WordPress 사이트를 만들기 위해 필요한 요소 사이의 차이, 그리고 실무에서 최적화 우선순위를 어떻게 잡아야 하는지를 다룹니다.

Lighthouse는 여섯 가지 지표를 보고하지만, 그 중 세 가지는 사용자 경험과 구글 순위에 직접적이고 측정 가능한 영향을 미칩니다: LCP(Largest Contentful Paint), INP(Interaction to Next Paint, 2024년에 FID를 대체), CLS(Cumulative Layout Shift).

• LCP는 가장 큰 가시 요소(보통 히어로 이미지나 큰 헤딩)가 완전히 렌더링되는 데 걸리는 시간을 측정합니다. 구글은 2.5초 이하를 ‘좋음’으로 간주합니다. 대부분의 WordPress 사이트에서 LCP는 대표 이미지나 히어로 섹션 배경에 의해 좌우되며, 거의 항상 가장 먼저 최적화해야 할 대상입니다.
• INP는 사용자가 페이지와 상호작용한 뒤 페이지가 반응하는 데 걸리는 시간을 측정합니다. JavaScript가 무겁게 사용되는 WordPress 환경이 가장 큰 걸림돌이 됩니다. 프런트엔드에 JS를 추가하는 모든 플러그인은 잠재적인 INP 킬러입니다.
• CLS는 페이지 로드 중 요소가 뛰어다니는지, 즉 시각적 안정성을 측정합니다. WordPress에서 흔히 문제를 일으키는 원인은 명시적인 크기가 없는 이미지, 로드 중 레이아웃 변화를 일으키는 웹 폰트, 그리고 콘텐츠를 아래로 밀어내는 광고·임베드입니다.

이 세 가지에만 집중하고 나머지는 무시한다면 의미 있는 작업의 80%를 수행한 셈입니다.

LCP 최적화 핵심 포인트

1. 히어로 이미지가 우선 리소스로 처리되지 않는 경우
   기본적으로 WordPress는 이미지를 lazy‑load합니다. 즉, 뷰포트에 가까워질 때까지 로딩을 미룹니다. 페이지 로드 시 이미 뷰포트에 보이는 히어로 이미지에 lazy‑load를 적용하면 오히려 LCP가 악화됩니다.

   <img src="hero.jpg" loading="eager" fetchpriority="high" width="1200" height="800" alt="Your descriptive alt text here">

   loading="eager"와 fetchpriority="high"를 히어로 이미지 태그에 직접 추가하면 브라우저가 이를 고우선순위 리소스로 인식해 즉시 로드합니다.

   [Image: 여기 설명적인 대체 텍스트]

   또한 width와 height 속성을 명시하면 이미지가 로드되기 전 레이아웃에 정확한 공간이 예약되어 CLS를 방지합니다.

2. 이미지 포맷·용량
   모바일 연결에서 2 MB JPEG 히어로 이미지는 다른 모든 최적화를 무시하고도 나쁜 LCP를 초래합니다. 적절한 크기의 WebP 이미지와 올바른 srcset 구현은 선택이 아니라 기본 요건입니다.

3. 특정 이미지에 대해 lazy‑load를 비활성화해야 할 때

   add_filter( 'wp_lazy_loading_enabled', function( $default, $tag_name, $context ) {
       if ( $tag_name === 'img' && $context === 'the_content' ) {
           return false;
       }
       return $default;
   }, 10, 3 );

   프로덕션 환경에서는 이렇게 개별 이미지에만 적용하고, 전역적으로 lazy‑load를 끄면 화면 아래쪽 이미지 로딩이 크게 느려집니다.

INP 최적화 핵심 포인트

대부분의 WordPress 사이트에서 INP가 나쁜 이유는 메인 스레드에서 JavaScript가 과도하게 실행되기 때문입니다. 프런트엔드에 JS를 로드하는 모든 플러그인은 동일한 단일 스레드를 놓고 경쟁합니다. 사용자가 클릭했을 때 플러그인 스크립트가 바쁘면 응답이 지연됩니다.

진단 방법은 간단합니다. Chrome DevTools → Performance 탭을 열고 클릭·폼 입력 같은 상호작용을 기록한 뒤, 메인 스레드를 차단하는 Long Task를 찾아보세요. 원인 스크립트는 대부분 즉시 식별됩니다.

• 초기 렌더링이나 위‑폴드 인터랙티비티에 필요하지 않은 스크립트는 defer

  // 사용자 상호작용 이후에 로드
  document.addEventListener('click', function loadScript() {
      const script = document.createElement('script');
      script.src = 'heavy-widget.js';
      document.head.appendChild(script);
      document.removeEventListener('click', loadScript);
  }, { once: true });

• WordPress에 적용하기
  모든 활성 플러그인을 점검하고, “모든 페이지에 JS를 로드할 필요가 있는가?”를 질문하세요. 많은 플러그인이 실제로는 특정 페이지나 포스트 타입에서만 필요함에도 전역으로 스크립트를 로드합니다. 조건부 로딩을 통해 불필요한 JS를 크게 줄일 수 있습니다.

  add_action( 'wp_enqueue_scripts', function() {
      if ( is_singular( 'post' ) ) {
          wp_enqueue_script( 'my-plugin-script', get_template_directory_uri() . '/js/plugin.js', array(), '1.0', true );
      }
  });

CLS 최적화 핵심 포인트

웹 폰트가 유발하는 CLS는 WordPress 테마에서 가장 흔하고 간과되기 쉬운 문제 중 하나입니다. 브라우저는 페이지를 로드하면서 fallback 시스템 폰트로 텍스트를 표시하고, 웹 폰트가 로드되면 교체하면서 레이아웃이 움직입니다.

현대적인 해결책은 font-display: swap을 사용하고 중요한 폰트를 미리 로드(preload)하는 것입니다.

@font-face {
    font-family: 'PrimaryFont';
    src: url('/fonts/primary-font.woff2') format('woff2');
    font-display: swap;
}

font-display: swap은 폰트가 준비될 때까지 fallback 폰트로 즉시 텍스트를 표시하고, 웹 폰트가 준비되면 교체하도록 지시합니다. 미리 로드(preload)와 결합하면 교체가 거의 눈에 띄지 않을 정도로 빠르게 이루어집니다.

Google Fonts를 직접 호스팅하면 DNS 조회를 하나 줄일 수 있고, 캐시 헤더를 직접 제어할 수 있어 LCP·CLS 최적화에 큰 도움이 됩니다.

서버‑레벨 캐싱

WordPress 사이트에 서버‑레벨 캐시가 없으면 모든 요청마다 불필요한 작업을 수행합니다. PHP가 실행되고, DB 쿼리가 수행되며, HTML이 매번 조립됩니다. 공유 호스팅 환경에서는 이 과정이 페이지 로드에 눈에 띄는 지연을 초래합니다.

• Object Cache(Redis, Memcached) → 반복 요청 시 DB 쿼리 비용 제거
• Page Cache → 사전 생성된 HTML 파일을 직접 제공, PHP 전혀 통과하지 않음
• CDN Cache → 정적 자산을 방문자와 가까운 엣지 서버에서 제공

최적화 우선순위: 페이지 캐시 → 오브젝트 캐시 → 정적 자산 CDN. 각 레이어는 앞 단계의 효과를 증폭시킵니다.

대부분의 관리형 호스팅에서는 서버‑레벨 캐시가 이미 제대로 설정돼 있기 때문에 플러그인‑레벨 캐시의 필요성이 낮아집니다. 추가 플러그인을 도입하기 전에 현재 호스팅 스택이 제공하는 캐싱 기능을 정확히 파악하세요.

실제 데이터와 Lighthouse 점수 차이

실험실 환경에서 95점이라는 Lighthouse 점수는 실제 사용자 데이터가 Google Search Console에서 LCP 평균 4초를 보인다면 의미가 없습니다. 실험실 점수는 단일 시뮬레이션 로드만을 측정합니다. 실제 사용자는 이미 연결이 따뜻하고, 캐시된 리소스를 가지고 있으며, 다양한 디바이스·네트워크 환경을 가집니다.

Search Console의 CrUX(Chrome User Experience Report) 데이터는 28일 동안 수집된 실제 사용자 경험을 반영합니다. 이 데이터가 구글 순위에 사용되며, 여러분