Lighthouse Use efficient cache lifetimes: 해결 방법

"Use efficient cache lifetimes"가 Lighthouse 점수를 떨어뜨릴까요?

Lighthouse는 캐시 수명이 30일 미만인 모든 정적 파일을 Use efficient cache lifetimes 인사이트("캐시 수명이 길면 페이지 재방문 속도를 높일 수 있습니다")에 표시합니다. Lighthouse 13 이전에는 "Serve static assets with an efficient cache policy", 구형 PageSpeed Insights에서는 "Leverage browser caching"으로 불렸던 항목입니다. 이 항목은 점수에 반영되지 않으며 점수를 바꿀 수도 없습니다. Lighthouse는 항상 빈 캐시 상태로 로드하기 때문입니다. 서버, CDN 또는 캐싱 플러그인에서 캐시 수명을 더 길게 설정하세요.

Lighthouse에서 Use efficient cache lifetimes는 무슨 의미인가요?

Lighthouse 설명은 다음과 같습니다. "캐시 수명이 길면 페이지 재방문 속도를 높일 수 있습니다. 캐싱에 대해 자세히 알아보기."

Lighthouse는 캐시 수명이 30일 미만이거나 수명이 아예 없는 모든 스크립트, 스타일시트, 폰트, 이미지, 동영상, 오디오 파일을 나열합니다. 캐시 수명은 파일의 Cache-Control 헤더에 있는 max-age 값이거나 Expires 날짜까지 남은 시간입니다. 다른 도메인의 파일도 자체 파일과 똑같이 표시됩니다.

Lighthouse는 Cache-Control 헤더에 no-cache, no-store, private, must-revalidate가 포함된 파일은 max-age 값과 관계없이 제외합니다. 캐시하지 않기로 선택했다고 간주하기 때문입니다. max-age=0인 파일도 제외하며, HTML 페이지 자체는 절대 목록에 올리지 않습니다.

Google Tag Manager, GA4, Meta Pixel을 로드하는 페이지입니다. Google은 태그를 private으로 전송하므로 셋 중 Meta Pixel만 표시됩니다. Lighthouse 13.5.0, PageSpeed Insights와 동일한 시뮬레이션 스로틀링 적용.

브라우저 캐싱은 어떻게 작동하나요?

브라우저는 파일과 함께 캐시 수명을 저장합니다. 다음 페이지를 열거나 다시 방문할 때 저장된 사본을 먼저 확인합니다.

• 수명이 남아 있을 때: 브라우저는 사본을 사용하며 요청을 전혀 보내지 않습니다. 서버 응답을 기다리지 않는 유일한 경우입니다.
• 수명이 만료되었을 때: 브라우저는 파일과 함께 받았던 ETag나 Last-Modified 날짜로 서버에 파일 변경 여부를 묻습니다. 변경되지 않았다면 서버는 파일 본문 없이 304 Not Modified로 응답합니다. 다운로드는 절약되지만 파일마다 서버 왕복이 발생하며, 서버가 모든 스타일시트에 응답할 때까지 페이지를 페인트할 수 없습니다.
• 수명이 만료되었고 ETag나 Last-Modified도 없을 때: 브라우저가 파일을 다시 다운로드합니다.

Chrome에서 일반 새로고침은 수명이 유효한 파일을 다시 확인하지 않습니다. Firefox와 Safari는 Cache-Control에 immutable이 없으면 다시 확인합니다.

Chrome 86부터 모든 사이트는 자체 캐시를 갖습니다. 방문자가 다른 사이트에서 이미 다운로드한 폰트나 jQuery 파일이라도, 동일한 URL이라도 현재 사이트에서 다시 다운로드합니다. 따라서 서드파티의 캐시 수명은 사이트 내 다음 페이지와 재방문 시에만 도움이 되며, "어차피 다들 캐시해 뒀다"는 말은 더 이상 Google 폰트를 불러올 이유가 되지 못합니다(직접 호스팅하세요).

브라우저 캐시와 CDN 캐시는 서로 다르며, WordPress 캐싱 플러그인의 페이지 캐시 역시 다릅니다. CDN이나 페이지 캐시는 서버가 매 방문자마다 페이지를 생성하거나 전송하지 않도록 사본을 보관하여 TTFB를 단축합니다(캐시 기간). 브라우저 캐시는 특정 방문자 한 명을 위해 요청 자체를 생략합니다. 이 인사이트는 오직 브라우저 캐시만 다루므로, 페이지 캐시가 이미 켜져 있어도 이 항목은 해결되지 않습니다.

캐시 수명을 늘리면 LCP와 FCP가 개선될까요?

첫 방문 시 FCP와 LCP

변화가 없습니다. Slow 4G 환경의 모바일 기기에서 WooCommerce 제품 페이지를 테스트했을 때, 헤더가 전혀 없는 경우부터 1년인 경우까지 모든 조건에서 첫 페인트는 2.13초, LCP는 2.26초였습니다. 첫 방문 시에는 캐시에 아직 아무것도 없기 때문입니다. Lighthouse와 PageSpeed Insights는 항상 이 방식으로만 페이지를 로드합니다. Lighthouse에서 이 항목이 빨간색으로 표시되고 옆에 FCP와 LCP 절약 시간이 나와 있더라도, 이 인사이트를 해결한다고 해서 Lighthouse 점수나 지표가 달라지지는 않습니다.

파일에 4가지 캐시 헤더를 적용한 동일 제품 페이지입니다. Lighthouse 13.5.0, 모바일, 시뮬레이션 스로틀링.

다음 페이지 및 재방문 시 FCP와 LCP

첫 방문 시 2.13초 대비 첫 페인트(FCP) 시간(단위: 초):

• 성능 개선은 수명이 유효한 파일에서 나옵니다. 일주일 뒤 1년 수명을 설정한 페이지의 첫 페인트는 0.78초로 첫 방문의 약 3분의 1 수준이었습니다. 남은 시간은 HTML 대기 시간뿐입니다. 재방문 시 LCP 요소인 제품 사진은 no-store(2.24초)를 제외한 모든 헤더에서 첫 페인트와 동시에 나타났습니다.
• 304 응답을 거치는 재방문은 첫 방문만큼이나 느렸습니다. 수명이 설정되지 않았을 때 일주일 뒤 쇼핑몰 자체 파일 13개가 모두 304로 응답했습니다. 네트워크 전송량은 404 kB 대신 1 kB에 불과했지만, 첫 페인트는 1.94초로 전체를 다시 다운로드했을 때보다 겨우 0.19초 빨랐을 뿐입니다.
• 짧은 수명은 당장의 방문만 커버하고 재방문 전에 만료됩니다. Cloudflare의 4시간 설정은 다음 페이지를 캐시에서 제공했지만, 일주일 뒤에는 304 응답을 확인해야 했습니다. 오직 1년 설정만이 두 경우 모두를 커버했습니다.
• no-cache와 no-store는 모든 페이지를 느리게 만듭니다. 다음 페이지 로딩 시간을 0.79초에서 각각 1.93초와 2.11초로 늘려 놓았습니다.

네트워크 속도를 제한한 모바일 기기에서 0.8초 시점의 두 페이지.

실제 Slow 4G 환경에서는 모든 조회가 더 오래 걸리지만 헤더 간 우열은 그대로 유지됩니다. Fast 4G 환경에서는 1년 수명 설정 시 재방문에서 0.52초 만에 페인트되었고, 304 응답을 거친 재방문은 해당 환경의 첫 방문과 똑같이 0.85초가 걸렸습니다.

Use efficient cache lifetimes는 언제 무시해도 될까요?

Lighthouse에 자체 파일이 표시되고 방문자가 며칠 또는 몇 주 뒤에 다시 방문한다면 반드시 고치세요. 서버 규칙 하나면 끝나고 페이지 로드 시 아무런 비용도 들지 않습니다. 다음의 경우에는 그대로 두어도 됩니다.

• 목록에 표시된 모든 파일이 다른 도메인에 있거나 호스팅 플랫폼에서 제공되는 경우(아래 참조). Shopify에서는 항상 여기에 해당합니다.
• CSS와 JavaScript 파일명이 동일한 상태로 내용만 변경되고 버전을 추가할 수 없는 경우. 이 때는 짧은 수명이 올바른 선택이며 Lighthouse 목록에 계속 남게 됩니다.
• 광고 캠페인 랜딩 페이지처럼 거의 모든 방문자가 페이지만 보고 다시 방문하지 않는 경우. 캐시를 활용할 방문자가 없습니다.

field data에서 캐시 수명의 효과를 어떻게 측정하나요?

field data에는 첫 방문과 다음 페이지 이동, 재방문이 함께 섞여 있습니다. CoreDash에서 모바일 LCP를 Repeat Visitor 기준으로 그룹화한 다음, TTFB도 동일하게 확인해 보세요.

데모 사이트 acme-pagespeed.com의 CoreDash 화면: 모바일, p75.

재방문자의 LCP는 0.65초, 신규 방문자는 1.74초입니다. 이 격차가 전부 캐시 때문은 아닙니다. 브라우저가 이미 서버와 연결을 맺고 있는 경우가 많아 재방문자는 0.87초 대신 323ms로 첫 바이트를 더 빨리 받습니다. 따라서 LCP에서 TTFB를 빼야 합니다. 첫 바이트 이후 대기 시간은 재방문자가 0.33초, 신규 방문자가 0.87초입니다. 이 0.54초가 대략 캐시가 절약해 주는 시간이며 전체 격차의 절반 정도입니다. 더 빠른 첫 바이트가 나머지 절반을 차지합니다.

세션 내 다음 페이지만 따로 보려면 Navigation Origin 기준으로 그룹화하세요. same origin은 방문자가 사이트 내 다른 페이지에서 이동해 왔음을 의미합니다. CrUX는 이러한 모든 방문을 페이지당 또는 사이트당 단일 p75로 합산하므로 이러한 구분을 보여줄 수 없습니다.

DevTools에서 파일의 캐시 헤더를 어떻게 확인하나요?

Network 패널을 열고 Disable cache가 꺼져 있는지 확인하세요(언제 켜야 하는지는 DevTools 네트워크 설정에 나와 있습니다). 페이지를 로드한 뒤 두 번째 페이지로 이동해 봅니다. Status 및 Size 열에서 각 파일의 처리 상태를 볼 수 있습니다.

• Size 열의 (disk cache) 또는 (memory cache): 요청 없이 캐시에서 가져왔습니다.
• Status 열의 304: 브라우저가 서버에 확인을 요청했고 파일 본문 없이 응답받았습니다.
• 크기가 표시된 200: 다시 다운로드했습니다.

Slow 4G 환경에서 일주일 뒤 재방문 시 Network 패널의 모습입니다.

파일을 클릭하고 Headers 탭을 여세요. Response Headers 항목에서 cache-control과 expires는 서버가 보낸 수명을 보여주며, etag와 last-modified는 브라우저가 재확인에 사용할 수 있는 값입니다. 명령줄에서는 다음과 같이 확인합니다.

curl -sI https://www.example.com/wp-content/themes/acme/style.css | grep -iE "cache-control|expires|etag|last-modified"

Performance 패널에도 동일한 인사이트가 있습니다. 새로고침을 기록한 뒤 Insights 사이드바에서 Use efficient cache lifetimes를 여세요. 대상 파일이 나열되고 Network 트랙에 윤곽선으로 강조됩니다. 수명이 없는 파일은 여기에서 0ms로 표시되고 Lighthouse에서는 None으로 표시됩니다. 헤더를 기준으로 판단하므로 캐시에서 가져온 파일이라도 수명이 짧으면 여전히 목록에 표시됩니다.

Use efficient cache lifetimes는 어떻게 해결하나요?

Lighthouse에 나열된 각 파일의 도메인을 보면 헤더를 누가 설정하는지 알 수 있습니다. 자체 도메인의 파일이라면 서버, 호스팅 업체 또는 CDN이며, 다른 도메인의 파일이라면 해당 파일 제공업체입니다.

nginx, Apache, IIS, Caddy

자체 서버에서는 파일 형식별로 규칙 하나만 추가하면 수명을 설정할 수 있습니다. 아래 규칙들은 immutable을 포함해 1년을 부여합니다. 이미지에 적용하고, CSS, JavaScript, 폰트는 URL에 버전이 포함된 경우에 적용하세요(파일별 권장 캐시 수명). nginx의 경우:

location ~* \.(?:css|js|mjs|woff2|svg|png|jpe?g|gif|webp|avif|ico)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

디스크에서 해당 파일을 제공하는 server 블록에 이 설정을 추가하세요. 설정에 이러한 확장자를 처리하는 location이 이미 있다면 그곳에 add_header 줄을 대신 추가하세요. nginx는 일치하는 첫 번째 정규식 location만 적용하기 때문입니다. 기존 expires 줄이 있다면 제거해야 파일에 Cache-Control 헤더가 중복으로 붙지 않습니다. location 블록 내부의 add_header는 해당 파일에 대해 server 블록의 모든 add_header를 무효화하므로, server 블록의 add_header 줄(예: HSTS 헤더)도 이 location 안에 함께 복사해 넣어야 합니다.

Apache의 경우 .htaccess에 다음 내용을 추가하세요.

<IfModule mod_headers.c>
  <FilesMatch "\.(css|js|mjs|woff2|svg|png|jpe?g|gif|webp|avif|ico)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

FilesMatch는 파일명을 기준으로 동작하므로 PHP가 생성하는 페이지는 고유 헤더를 유지합니다. 설정 후에도 Lighthouse에 여전히 파일이 나열된다면 서버에 규칙이 적용되지 않은 것입니다. mod_headers가 꺼져 있거나, 호스팅 업체가 .htaccess를 무시하는 다른 서버에서 이 파일들을 제공하고 있을 수 있습니다. 호스팅 업체에 문의하세요.

IIS는 기본적으로 수명을 전혀 보내지 않습니다. 정적 파일이 있는 폴더로 범위를 지정하여 web.config에 헤더를 설정하세요.

<configuration>
  <location path="assets">
    <system.webServer>
      <httpProtocol>
        <customHeaders>
          <add name="Cache-Control" value="public, max-age=31536000, immutable" />
        </customHeaders>
      </httpProtocol>
    </system.webServer>
  </location>
</configuration>

Caddy의 경우:

@static path *.css *.js *.mjs *.woff2 *.svg *.png *.jpg *.jpeg *.gif *.webp *.avif *.ico
header @static Cache-Control "public, max-age=31536000, immutable"

WordPress

WordPress 자체는 /wp-content/나 /wp-includes/의 어떤 파일에도 수명을 보내지 않습니다. 호스팅 업체, 서버 또는 플러그인이 이를 결정합니다. Kinsta, WP Engine, WordPress VIP, WordPress.com은 이미 1년을 전송하므로, 이곳에서 호스팅한다면 Lighthouse에 나열되는 파일은 대체로 다른 도메인의 파일입니다(아래 참조). 이 알림은 대개 수명을 보내지 않는 Apache 공유 호스팅, 직접 구축한 nginx 서버, 또는 Cloudflare 기본 설정 뒤에서 주로 나타납니다. 주요 캐싱 플러그인 설정은 다음과 같습니다.

• WP Rocket은 Apache 및 LiteSpeed 서버의 .htaccess에 mod_expires 규칙을 작성합니다. CSS와 JavaScript는 1년, 이미지와 폰트는 4개월입니다. nginx에서는 아무 작업도 하지 않으므로 위의 nginx 규칙을 추가하거나 호스팅 업체에 문의하세요.
• LiteSpeed Cache는 Browser Cache가 기본적으로 꺼져 있습니다. LiteSpeed Cache > Cache > Browser에서 켜면 1년으로 전송됩니다.
• W3 Total Cache는 Browser Cache가 기본적으로 켜져 있습니다. nginx의 경우 서버 설정에 직접 include해야 하는 nginx.conf 파일을 작성합니다.

WordPress는 로드하는 모든 스타일시트와 스크립트에 ?ver=를 추가합니다. 기본값은 WordPress 버전이며 테마나 플러그인이 전달하는 버전이 붙기도 합니다. 이 값은 업데이트 시에만 변경됩니다. 버전을 변경하지 않고 자체 CSS를 수정하면 URL이 그대로 유지되어 재방문자는 캐시 수명이 다할 때까지 이전 CSS를 계속 유지합니다. 파일을 수정할 때마다 URL이 바뀌도록 파일 수정 시간을 버전으로 지정하여 로드하세요.

add_action( 'wp_enqueue_scripts', function () {
  $file = '/css/custom.css';
  wp_enqueue_style( 'acme-custom', get_stylesheet_directory_uri() . $file, array(), filemtime( get_stylesheet_directory() . $file ) );
} );

업로드 파일에는 버전이 없습니다. WordPress는 다시 업로드한 파일에 새 이름(photo-1.jpg)을 부여하므로 플러그인이 동일한 이름으로 미디어를 대체하지 않는 한 1년으로 설정해도 안전합니다.

Cloudflare 및 기타 CDN

Cloudflare의 Browser Cache TTL은 모든 요금제에서 기본 4시간입니다. 서버가 수명을 보내지 않거나 더 짧은 수명을 보내면 Cloudflare가 4시간을 전송하며, Lighthouse는 해당 파일을 "4h"로 표시합니다. 서버에서 수명을 설정하고 Browser Cache TTL(Caching > Configuration)을 Respect Existing Headers로 전환하세요. 또는 정적 파일 형식에 대해 브라우저 TTL을 설정하는 Cache Rule을 만드세요. 도메인 전체(zone-wide) 설정을 1년으로 올리지 마세요. 버전 관리가 되지 않는 CSS를 포함해 Cloudflare가 더 짧은 헤더로 제공하는 모든 파일에 적용되기 때문입니다. 기타 설정에 대한 자세한 내용은 Core Web Vitals 통과를 위한 Cloudflare 설정을 확인하세요.

CloudFront와 Fastly는 서버의 헤더를 브라우저에 그대로 전달합니다. 이들 플랫폼의 TTL 설정은 CDN이 사본을 보관하는 기간만 변경합니다. Bunny에서는 Override Browser Cache Time을 적용한 Edge Rule을 통해 파일 확장자별 수명을 설정합니다.

Shopify

Shopify는 이미 테마 파일, 업로드 파일, 제품 이미지에 1년(public, max-age=31557600)을 부여하며, Shopify 헤더는 변경할 수 없습니다. Shopify 환경에서 Lighthouse에 표시되는 파일은 Shopify 자체 및 설치된 앱에서 비롯된 것입니다. 자체 도메인의 /cdn/shopifycloud/ 경로에 있는 동적 결제 버튼(portable-wallets, 5분), shop-js 로더(30분), web pixels manager(60초) 등입니다. 수정할 부분이 없습니다. 이 알림은 무시하세요.

Next.js 및 기타 빌드 도구

Next.js는 /_next/static/ 하위의 모든 파일에 immutable을 포함해 1년을 부여하며, 이는 재정의할 수 없습니다. public/ 경로의 파일은 max-age=0을 받고(Vercel에서는 must-revalidate 포함), /_next/image는 must-revalidate를 전송하므로 이 인사이트는 둘 다 건너뜁니다. Next.js 사이트에서 Lighthouse에 파일이 표시된다면 서드파티에서 비롯되었거나 앞단의 프록시 또는 CDN이 헤더를 덮어쓰고 있기 때문입니다. 내용에 따라 이름이 바뀌는 public/ 내 파일의 경우 next.config.js에서 1년으로 설정하세요.

module.exports = {
  async headers() {
    return [{
      source: '/fonts/:path*',
      headers: [{ key: 'Cache-Control', value: 'public, max-age=31536000, immutable' }],
    }]
  },
}

다른 스택이라면 번들러가 파일명에 해시를 포함하도록 설정하여(app.3f9a1c.js), 변경될 때마다 새 URL이 생성되게 하세요. 그런 다음 해당 파일들에 1년을 전송하세요.

직접 수정할 수 없는 서드파티 및 플랫폼 파일

제공업체는 모든 사이트에서 스크립트를 한 번에 업데이트할 수 있도록 수명을 짧게 유지하며, 그 헤더를 사용자가 변경할 수는 없습니다. Lighthouse는 제공업체가 전송하는 수명과 함께 다음과 같은 파일들을 자주 나열합니다.

• Meta Pixel (fbevents.js): 20분
• Hotjar: 60초
• Google Analytics의 구형 analytics.js: 2시간
• Google Maps (maps/api/js): 30분
• Stripe (js.stripe.com/v3): 2분
• 자체 도메인의 Cloudflare 전용 스크립트 (email-decode.min.js, Rocket Loader): 2일

이 파일들은 그대로 두세요. 자체 헤더를 적용하겠다고 fbevents.js나 gtag.js 같은 로더를 직접 호스팅하지 마세요. 복사본에 제공업체의 업데이트가 반영되지 않습니다. 대신 다음과 같이 대처할 수 있습니다.

• URL에 정확한 버전이 지정된 공개 CDN에서 라이브러리를 로드하세요. jsDelivr는 swiper@11에 7일을 부여하지만 정확한 버전에는 1년을 부여합니다. 또는 특정 버전을 고정해 직접 호스팅하면서 자체 헤더를 부여하세요.
• 이메일 주소 난독화(Email Address Obfuscation)처럼 필요 없는 Cloudflare 기능을 끄세요.
• 더 이상 아무도 사용하지 않는 태그를 삭제하세요.

파일별 권장 캐시 수명

• URL에 버전이나 해시가 있는 CSS, JavaScript, 폰트: immutable을 포함해 1년을 설정하세요. Cache-Control: public, max-age=31536000, immutable. 새 버전은 새 URL이므로 브라우저가 즉시 새로 가져옵니다.
• 이미지: 동일한 헤더를 적용하세요. 이미지가 변경되면 새 파일명을 부여하세요. 아무도 이전 이미지를 볼 수 없게 됩니다.
• 버전이 없는 CSS, JavaScript, 폰트: 버전부터 먼저 추가하세요(위의 WordPress 및 빌드 도구 설명 참조). 버전을 추가하기 전까지는 수명을 짧게 유지하고 Lighthouse 목록에 표시되는 것을 감수하세요. 동일한 이름으로 변경되는 스타일시트에 긴 수명을 적용하면 재방문자는 새 HTML에 이전 CSS가 적용된 화면을 보게 됩니다.
• HTML: Cache-Control: no-cache 또는 짧은 max-age를 설정하세요. 수명이 길면 방문자가 이전 페이지를 계속 보게 되기 때문입니다.
• 알림을 없애겠다고 정적 파일에 no-store, no-cache, must-revalidate를 절대 사용하지 마세요. 매 페이지뷰마다 모든 파일을 다시 확인하거나 다시 다운로드하게 됩니다(위의 다음 페이지 항목 참조).

새로 설정한 캐시 수명이 작동하는지 어떻게 확인하나요?

먼저 앞서 설명한 대로 curl이나 Headers 탭으로 파일의 헤더를 확인하세요. 새로운 max-age가 표시되어야 합니다. 그런 다음 모바일에서 Lighthouse를 실행하세요. 해당 파일이 더 이상 나열되지 않으며 점수와 지표는 위의 4개 보고서처럼 그대로 유지됩니다. 제품 페이지 테스트 시 매번 점수가 96점 또는 80점으로 나왔는데, 이는 헤더와 전혀 무관했습니다. 따라서 설정 수정 후 점수가 달라졌더라도 이는 캐시와 아무 관련이 없습니다.

방문자가 다시 방문하여 새로운 수명이 적용된 파일을 받기 시작하면, 며칠 내로 CoreDash의 재방문자 데이터에 그 효과가 가장 먼저 나타납니다. CrUX와 Search Console은 최근 28일 데이터를 보여주므로, 설정을 수정한 지 2주가 지나도 표시되는 데이터의 절반은 여전히 이전 사이트의 데이터입니다.

목록에 나열된 파일 중 어느 것을 직접 고쳐야 하는지, 혹은 재방문자가 이미 가지고 있는 파일을 기다리느라 지연을 겪고 있는지 확실하지 않으신가요? Core Web Vitals 파워 아워에서 헤더와 field data를 함께 점검해 드립니다. 통화가 끝나기 전에 서버에 바로 적용할 수 있는 규칙을 전달해 드립니다.