asset 최적화

앞 글 웹 성능 최적화 기본 원칙에서는 측정을 바탕으로 성능을 개선하는 순환과 Core Web Vitals를 살펴봤습니다. 이번에는 그 가운데 프런트엔드 성능에서 가장 큰 몫을 차지하는 에셋(asset), 즉 이미지, CSS, 자바스크립트, 웹 글꼴 같은 정적 파일의 최적화를 다룹니다.

에셋마다 파일 크기를 줄이는 방법과 불러오는 시점을 조정하는 방법을 정리하고, 이것이 주요 콘텐츠가 보이는 시점인 LCP, 실험실에서 메인 스레드를 막는 시간인 TBT와 어떻게 이어지는지 함께 살펴봅니다. 마지막으로 모든 에셋에 적용되는 HTTP 캐시 전략을 정리합니다.

위 그림은 에셋을 바꾸고 전달하는 세 단계입니다. 첫 단계에서는 원본을 실제 표시 크기와 품질에 맞게 바꿉니다. 이미지는 srcset과 sizes로 표시 크기에 맞는 후보를 여럿 준비하고, 글꼴은 필요한 문자와 굵기만 남깁니다. 두 번째 단계에서는 압축하고, 쓰지 않는 CSS와 자바스크립트를 지우고, 필요한 단위로 나눈 뒤, 내용이 바뀐 파일에는 내용의 해시(hash)를 넣은 새 URL을 붙입니다. 이때 HTML과 매니페스트(manifest)가 새 URL을 가리키도록 함께 갱신해야 합니다. 세 번째 단계에서는 CDN과 HTTP 캐시로 전달하고 다시 씁니다.

그림 아래쪽은 불러오는 시점과 캐시의 원칙입니다. 첫 화면의 LCP 이미지와 핵심 CSS는 브라우저가 빨리 발견하게 하고, LCP 이미지는 지연 로딩하지 않으며, preload는 실제로 발견이 늦어지는 것을 확인한 중요한 자원에만 씁니다. 나중 화면의 자원은 화면 밖 이미지의 지연 로딩이나 필요한 시점의 동적 import()로 미룹니다. async와 defer는 쓸 때까지 내려받지 않는다는 뜻이 아니며, async는 준비되는 대로 순서 없이, defer는 해석이 끝난 뒤 문서 순서대로 실행하고 둘 다 내려받고 실행하는 비용을 없애지는 않습니다.

캐시는 바뀌지 않는 해시 에셋에 긴 max-age와 immutable을 주고, HTML은 짧게 캐시하거나 다시 확인해 새 에셋의 참조를 전달합니다. 그림 맨 아래의 설명처럼 글꼴이 바뀌며 생기는 레이아웃 이동, 나눈 자바스크립트의 실행 비용, 첫 화면 자원의 발견 지연을 다시 측정해야 하며, 파일이 작아졌다고 LCP, INP, CLS가 모두 나아지는 것은 아닙니다.

이미지 최적화

웹 페이지에서 가장 큰 용량을 차지하는 경우가 많은 것이 이미지라서, 이미지 최적화는 성능 개선 효과가 큰 영역입니다. 줄일 수 있는 길은 세 가지입니다. 같은 그림을 더 작은 파일로 담는 형식을 고르고, 화면에 실제로 필요한 크기로 압축하고, 당장 보이지 않는 이미지는 나중에 받는 것입니다. 아래의 세 절이 이 순서를 따릅니다.

알맞은 형식 고르기

JPEG는 색이 풍부하고 세밀한 사진에 알맞은 손실 압축 형식입니다. PNG는 투명한 배경이나 로고, 아이콘처럼 선명한 가장자리가 중요한 이미지에 알맞은 무손실 압축 형식입니다. WebP는 JPEG나 PNG보다 압축률이 좋으면서 품질 손실이 적고 투명도도 지원하며, 지금의 주요 브라우저가 모두 지원합니다. AVIF는 WebP보다 더 높은 압축률을 낼 수 있는 형식으로, 지원 범위를 확인해 함께 검토할 수 있습니다. SVG는 로고, 아이콘, 간단한 그림 같은 벡터 이미지에 알맞고 확대해도 깨지지 않으며 CSS로 꾸밀 수 있지만, 모양이 복잡하면 파일이 커질 수 있으므로 실제 결과를 비교합니다.

압축과 크기 조정

손실 압축은 JPEG나 WebP 등에 쓰며, 일부 데이터를 잃는 대신 파일을 크게 줄입니다. 무손실 압축은 PNG, GIF, SVG 등에 쓰며 데이터 손실 없이 파일을 줄입니다. Squoosh 같은 도구나 빌드 도구의 플러그인으로 압축을 자동화할 수 있습니다.

이미지는 실제로 화면에 표시될 크기에 맞춰 준비하고, 필요 이상으로 큰 해상도를 쓰지 않습니다. srcset과 sizes 속성을 쓰면 브라우저가 화면 크기와 해상도에 맞는 이미지를 골라 받습니다.

<img srcset="small.jpg 480w, medium.jpg 800w, large.jpg 1200w"
     sizes="(max-width: 600px) 480px, (max-width: 1000px) 800px, 1200px"
     src="medium.jpg" alt="산 위로 해가 뜨는 풍경" width="1200" height="800">

srcset은 각 이미지 파일과 그 실제 너비를, sizes는 화면 너비에 따라 이미지가 차지할 표시 너비를 알려 줍니다. 브라우저는 이 정보와 기기의 픽셀 밀도를 보고 알맞은 파일 하나를 고르며, src는 이를 지원하지 않는 환경을 위한 기본값입니다. width와 height를 적어 두면 이미지를 받기 전에 자리를 미리 잡아 두므로, 이미지가 나타나며 글이 밀리는 CLS를 막을 수 있습니다.

지연 로딩과 CDN

화면 밖에 있는 이미지는 지연 로딩(lazy loading)으로 나중에 불러옵니다. loading="lazy" 속성을 쓰거나 Intersection Observer API로 직접 구현할 수 있으며, 브라우저 내장 지연 로딩은 실제로 언제 요청을 시작할지 브라우저가 정해 화면에 들어오기 전에 미리 시작할 수도 있습니다.

<!-- 첫 화면의 LCP 이미지가 아닌, 화면 밖의 갤러리 이미지 예 -->
<img src="gallery.jpg" alt="갤러리 풍경" width="800" height="600" loading="lazy">

여러 지역에 서버를 둔 CDN에 이미지를 두면, 사용자와 가까운 서버에서 이미지를 보내 로딩이 빨라집니다.

CSS 최적화

CSS 파일은 기본으로 페이지를 그리는 것을 막으므로, 효율적으로 관리해야 합니다.

공백과 주석, 마지막 세미콜론 등을 지워 CSS를 줄이는 최소화는 cssnano나 webpack의 css-minimizer-webpack-plugin 같은 도구가 합니다. 실제로 쓰지 않는 CSS 규칙은 PurgeCSS 같은 도구로 지울 수 있는데, Bootstrap이나 MUI 같은 UI 프레임워크를 쓰면 쓰지 않는 CSS가 특히 많을 수 있습니다. 다만 자바스크립트로 나중에 붙이는 클래스까지 지우지 않도록 결과를 확인합니다.

첫 화면을 그리는 데 꼭 필요한 최소한의 CSS(critical CSS)는 HTML의 <head> 안 <style> 태그에 직접 넣으면, 외부 CSS 파일을 받을 때까지 화면 그리기가 늦어지는 것을 줄여 FCP와 LCP를 개선할 수 있습니다. 나머지 CSS는 나중에 불러옵니다.

여러 작은 아이콘을 큰 이미지 하나로 합치고 background-position으로 필요한 부분만 보이게 하는 CSS 스프라이트(CSS sprite)는 요청 수를 줄이는 예전 방법입니다. 요즘은 SVG 아이콘이나 HTML에 직접 넣는 인라인 SVG로 대신하는 경우가 많습니다. <link>의 media 속성으로 print처럼 특정 매체에서만 쓰는 CSS를 지정하면, 지금 화면에 적용되지 않는 CSS가 그리기를 막지 않게 할 수 있습니다. 다만 그런 CSS도 미리 내려받을 수 있으므로, 전송 자체를 건너뛴다고 생각하지는 않습니다.

자바스크립트 최적화

자바스크립트는 내려받는 시간뿐 아니라 해석하고 컴파일하고 실행하는 데 CPU 시간이 많이 들어, 네트워크와 메인 스레드 양쪽에 병목을 만들 수 있습니다.

Terser 같은 도구는 공백을 지우는 것에 더해 변수 이름을 짧게 바꿔 파일을 최소화합니다. 트리 셰이킹(tree shaking)은 webpack이나 Rollup 같은 번들러가 실제로 쓰는 코드만 최종 번들에 넣고 쓰지 않는 코드를 빼는 일입니다. 이렇게 빼려면 정적인 ES 모듈 구조와 패키지의 부수 효과(side effects) 정보처럼, 번들러가 빼도 안전한지 판단할 조건이 필요합니다(webpack의 트리 셰이킹 안내). Lodash처럼 큰 라이브러리에서 일부 기능만 쓸 때는 결과 번들을 비교해 보고, 파일을 나누는 것과 쓰지 않는 코드를 빼는 것을 구별합니다.

코드 분할은 번들을 여러 조각으로 나눠 지금 필요한 코드만 내려받게 합니다. React의 lazy()와 Suspense, Vue의 비동기 컴포넌트, 동적 import()를 활용합니다. 외부 <script>에 async를 붙이면 HTML 해석과 함께 내려받아 준비되는 대로 실행하므로 스크립트 사이의 실행 순서가 보장되지 않고, defer를 붙이면 해석이 끝난 뒤 문서 순서대로 실행하므로 순서에 의존하는 스크립트에 씁니다.

분석 도구, 광고, 소셜 미디어 위젯 같은 서드 파티(third-party) 스크립트는 성능에 큰 영향을 줄 수 있으므로, 꼭 필요할 때만 불러오거나 늦게 불러옵니다. 작은 기능 하나 때문에 큰 라이브러리 전체를 넣기보다 직접 구현하거나 가벼운 대안을 찾습니다. 그리고 메인 스레드를 50ms 넘게 붙잡는 긴 작업을 피하고, 복잡한 계산은 웹 워커로 옮깁니다.

웹 글꼴 최적화

웹 글꼴은 디자인을 일관되게 해 주지만, 용량이 커서 로딩 성능을 떨어뜨릴 수 있습니다. 특히 한글 글꼴은 글자 수가 많아 파일이 큽니다.

글꼴 형식은 압축률이 가장 좋은 WOFF2를 쓰며, 지금의 주요 브라우저가 모두 지원하므로 대부분 WOFF2 하나로 충분합니다. 실제로 페이지에서 쓰는 문자만 남긴 부분 집합 글꼴(subset font)을 만들면, 예를 들어 자주 쓰는 한글과 숫자, 영문만 남겨 파일을 크게 줄일 수 있습니다.

CSS의 @font-face 규칙에서 font-display 속성으로 글꼴을 불러오는 동안의 표시 방식을 정합니다. swap은 글꼴을 받기 전에는 시스템 글꼴로 보여 주다가 받은 뒤 웹 글꼴로 바꿉니다. 글꼴이 바뀌며 글자 모양이 잠깐 달라 보일 수 있지만, 글이 바로 보여 사용 경험에 좋습니다. optional은 아주 짧은 대기 시간 뒤 교체 기간을 두지 않아, 제때 준비되지 않은 글꼴은 그 화면에서 대체 글꼴을 계속 쓰게 될 수 있습니다. 내려받기를 항상 멈춘다는 뜻은 아닙니다(MDN의 font-display).

가장 중요한 글꼴 파일은 <link rel="preload" href="your-font.woff2" as="font" type="font/woff2" crossorigin>으로 브라우저가 가능한 한 빨리 받게 할 수 있습니다. 글꼴은 같은 출처라도 crossorigin 속성이 있어야 미리 받은 파일을 다시 씁니다.

HTTP 캐시 전략

HTTP 캐시는 모든 에셋에 적용할 수 있는 중요한 최적화입니다. 서버는 응답의 Cache-Control 헤더로 브라우저의 캐시 규칙을 알려 줍니다. public, max-age=31536000, immutable은 정적 에셋을 1년 동안 신선하게 보고 다시 확인하지 않아도 된다는 뜻으로, 다시 방문할 때 바로 불러오게 합니다. immutable은 그 응답이 신선한 동안 다시 확인을 건너뛰어도 된다는 뜻이라서, 파일 이름에 내용의 해시를 넣고 내용이 바뀌면 새 URL로 배포하는 방식과 함께 씁니다. no-cache는 저장은 하되 다시 쓰기 전에 항상 서버에 확인하라는 뜻이고, no-store는 아예 저장하지 말라는 뜻으로 민감한 정보에 씁니다.

ETag와 Last-Modified는 파일이 바뀌었는지 확인하는 검증 값입니다. 브라우저가 캐시된 에셋을 다시 요청할 때 If-None-Match나 If-Modified-Since 헤더에 이 값을 담아 보내면, 서버는 파일이 바뀌지 않았을 때 본문 없이 304 Not Modified로 응답합니다. 파일을 통째로 다시 보내는 것보다 훨씬 효율적입니다.

파일 이름에 bundle.1a2b3c4d.js처럼 해시나 버전을 넣어 내용이 바뀔 때마다 새 이름으로 배포하는 것을 캐시 무효화(cache busting)라고 합니다. 새 파일 이름은 새 캐시 항목이 되므로, 사용자가 새 파일을 받으려면 HTML이나 매니페스트도 그 새 URL을 가리켜야 합니다. 오래된 HTML이 옛 URL을 계속 가리키는 문제까지 저절로 풀어 주지는 않습니다.

If-None-Match: "asset-v1"

If-None-Match: "asset-v1"

위 그림은 저장해 둔 응답을 다시 확인해야 할 때의 흐름입니다. 저장된 응답에 ETag가 있으면 브라우저는 If-None-Match에 그 값을 담아 조건부 GET을 보내고, 서버가 내용이 같은지 판단합니다. 같으면 304로 새 본문 없이 응답하므로, 브라우저는 기존 본문을 그대로 쓰고 헤더 같은 메타데이터만 갱신합니다. 바뀌었으면 200과 새 본문이 오므로, 새 응답의 규칙을 보고 저장할지 판단해 기존 응답을 바꿉니다.

그림 아래쪽은 다른 경우를 정리합니다. 저장된 응답이 없으면(miss) 네트워크로 요청하고, 받은 응답이 저장해도 되는 규칙이면 본문과 헤더, 신선도 정보를 저장합니다. max-age 같은 신선도 기간 안이고 다시 확인할 요구가 없으면(fresh) 저장된 응답을 그대로 씁니다. 기간이 지났거나(stale) no-cache가 다시 확인을 요구하면 서버에 확인하는데, 이것이 위의 조건부 요청입니다.

no-store는 새 응답을 저장하지 말라는 뜻일 뿐, 이미 저장된 같은 URL의 응답을 지운다는 뜻은 아닙니다. private는 브라우저 같은 개인 캐시에는 저장해도 되지만 여러 사용자가 함께 쓰는 공유 캐시에는 저장하지 말라는 뜻으로, no-store와는 다른 규칙입니다. 그림 아래의 설명처럼 내용의 해시가 바뀐 새 URL은 옛 URL의 응답을 지우는 것이 아니라 다른 캐시 항목을 요청하는 것이며, 이 그림은 일반 HTTP 요청의 기본 흐름이라 서비스 워커나 오래된 응답을 허용하는 별도 규칙은 다루지 않습니다.

더 깊이: Cache-Control이 없어도 캐시되는 이유

서버가 Cache-Control을 보내지 않으면 브라우저가 캐시하지 않을 것 같지만, 실제로는 반대인 경우가 있습니다. HTTP 캐시 명세인 RFC 9111은 응답에 명시적인 만료 시간이 없을 때 캐시가 스스로 만료 시간을 추정해도 된다고 정하며, 이를 휴리스틱 신선도(heuristic freshness)라고 합니다. 명세는 정해진 계산법을 두지 않지만, Last-Modified가 있다면 그 시각부터 지난 시간의 일부만큼만 신선하다고 보라고 권하며, 그 비율의 예로 10%를 듭니다.

예를 들어 1년 전에 마지막으로 바뀐 파일을 Cache-Control 없이 보냈다면, 브라우저는 그 응답을 약 0.1년, 곧 한 달 남짓 동안 서버에 묻지 않고 다시 쓸 수 있습니다. 그래서 파일 이름에 해시가 없는 app.js를 고쳐 배포했는데 일부 사용자가 계속 옛 파일을 받는 일이 생길 수 있습니다. 명시적인 만료 시간이 있으면 캐시는 이런 추정을 하지 않습니다.

MDN의 HTTP 캐시 설명은 휴리스틱 캐시가 Cache-Control이 널리 쓰이기 전의 임시방편이라며, 사실상 모든 응답에 Cache-Control을 명시하라고 권합니다. 따로 정할 것이 없는 응답에는 기본으로 Cache-Control: no-cache를 보내 매번 다시 확인하게 하고, 사용자마다 다른 응답이라면 private를 더합니다.

계산으로 따져 보기

전송량만 계산하는 간단한 모델을 세워 봅니다. 첫 화면의 이미지 200kB, 로고 20kB, 글꼴 80kB, 자바스크립트 400kB와 화면 밖의 갤러리 300kB를 모두 처음에 요청하면 합계는 1000kB입니다. 갤러리만 필요한 시점으로 미루면 처음에 받는 양은 200 + 20 + 80 + 400 = 700kB로 30% 줄지만, 나중에 갤러리를 보면 300kB를 다시 받습니다. 이 모델은 캐시와 압축의 차이를 빼고 계산한 것이라, 전송량이 30% 줄었다고 LCP가 30% 빨라진다는 보장은 없습니다. 첫 화면의 LCP 이미지까지 함께 미루면 오히려 LCP가 늦어질 수 있습니다.

HTTP 캐시에서는, 이미 저장된 응답의 현재 나이(age)가 600초이고 max-age=3600이며 다른 확인 요구가 없다면 신선도가 3000초 남아 있습니다. 나이가 3700초가 되면 만료되지만, 본문이 바로 사라지는 것은 아닙니다. 저장된 ETag를 조건부 GET으로 보내 304를 받으면 기존 본문을 쓰고 메타데이터를 갱신하며, 이때도 네트워크 왕복과 헤더 전송은 일어납니다.

정리

• 에셋 최적화는 원본을 표시 크기에 맞게 바꾸고, 압축하고 나누고 해시 URL을 붙인 뒤, CDN과 HTTP 캐시로 전달하는 과정입니다.
• 이미지는 알맞은 형식과 압축, srcset과 sizes, width와 height로 크기와 자리를 맞추고, 화면 밖 이미지만 지연 로딩하며 LCP 이미지는 미루지 않습니다.
• CSS는 최소화와 쓰지 않는 규칙 제거, 핵심 CSS 인라인으로 그리기를 막는 시간을 줄입니다.
• 자바스크립트는 최소화, 트리 셰이킹, 코드 분할, async와 defer, 서드 파티 정리, 긴 작업 분리로 전송과 실행 비용을 줄입니다.
• 글꼴은 WOFF2와 부분 집합, font-display, preload로 크기와 표시 시점을 다룹니다.
• 해시 에셋은 긴 max-age와 immutable로, HTML은 짧은 캐시나 재확인으로 다루고, ETag로 바뀌지 않은 파일은 304로 다시 씁니다.

연습 문제

1. no-cache와 새 본문

① 저장된 응답의 나이가 60초로 아직 신선한데, 응답 규칙에 인수 없는 no-cache가 있다면 서버 확인을 건너뛸 수 있을까요? ② 확인 요청에 200과 새 본문이 왔다면, 기존 본문으로 계속 보여 줘야 할까요?

2. 오래된 HTML과 새 해시 파일

새 해시 이름의 자바스크립트 파일을 배포했는데, 어떤 사용자의 브라우저가 캐시된 오래된 HTML을 계속 쓰고 있어 옛 파일 이름을 가리킵니다. 새 파일이 저절로 선택될까요? 어떻게 해야 할까요?

3. 줄인 뒤의 초기 전송량

앞의 전송량 모델에서 자바스크립트를 400kB에서 250kB로 줄이고 갤러리도 필요한 시점으로 미뤘습니다. 처음에 받는 양의 합계와, 처음의 1000kB에 대한 감소율은 얼마일까요?

이것으로 13장을 마칩니다. 13장에서는 HTTPS와 XSS, CSRF 같은 웹 보안의 기초, 인증과 권한 관리, 측정을 바탕으로 한 성능 최적화의 원칙, 그리고 이미지와 CSS, 자바스크립트, 글꼴, HTTP 캐시를 다루는 에셋 최적화까지 서비스를 안전하고 빠르게 만드는 방법을 살펴봤습니다. 다음 장의 Git 기초와 협업 워크플로우부터는 Git으로 코드의 변경 이력을 관리하고 협업하는 방법을 시작으로, npm과 패키지 관리, webpack, Babel과 폴리필까지 개발 도구와 작업 흐름을 다룹니다.