예산에 맞춘 페이지 속도: 가장 중요한 최적화

가장 중요한 최적화

Core Web Vitals 컨설턴트로서 저는 페이지 속도 지원에 대한 다양한 요청을 받습니다. 그리고 네, 때로는 예산이 많지 않을 때도 있습니다. 그런 경우에는 시간을 더욱 효율적으로 사용하고, 실제로 Core Web Vitals를 향상시키는 고효율, 저노력 최적화만 수행해야 합니다.

Arjen Karel이 2026년 3월에 마지막으로 검토함

수치가 이를 증명합니다. 2025 Web Almanac에 따르면, 모바일 오리진의 48%만이 세 가지 Core Web Vitals를 모두 통과합니다. 모바일 페이지의 중간 무게는 2.6MB이며, 632KB의 JavaScript(그 중 251KB는 사용되지 않음)가 포함되어 있습니다. 이는 큰 예산 없이도 고칠 수 있는 문제들입니다.

Core Web Vitals 팁: 저의 온콜 컨설팅(On-Call Consultancy)은 전문가의 도움을 받을 수 있는 가장 예산 친화적인 방법입니다. 2시간 세션(€300)을 예약하시면 Core Web Vitals 문제를 진단하고, 가장 시급한 문제를 해결하며, 나머지에 대한 명확한 전략을 제공해 드립니다. 상담 전에 미리 준비하므로 시간을 낭비하지 않습니다.

세션 예약하기!

1. 먼저 문제를 파악하세요

예산에 맞춰 웹 성능을 최적화할 때는 가능한 한 가장 효과적으로 최적화하고 있는지 절대적으로 확신해야 합니다. 즉, 가장 먼저 진짜 문제가 무엇인지 알아야 한다는 뜻입니다.

우수한 무료 도구인 PageSpeed Insights를 사용하여 CrUX 데이터를 조회할 수 있습니다. CrUX 데이터는 Google이 사용하는 데이터 소스이므로 중요하게 여겨지는 유일한 데이터 소스입니다.

CrUX 점수 아래에 Lighthouse 감사가 표시됩니다.

Lighthouse 감사에 대해 명확히 말씀드리겠습니다! 현시점에서는 Lighthouse에 신경 쓰지 않습니다. 왜일까요? Core Web Vitals를 측정하지 않기 때문입니다. 물론 Lighthouse는 훌륭한 테스트 도구이며 모든 제안 사항을 자유롭게 탐색할 수 있지만, 우리는 예산이 한정되어 있으므로 Core Web Vitals를 통과하는 데 신경을 씁니다. 지금 당장은 합성 테스트 통과 여부에 관심이 없습니다!

다시 CrUX 데이터로 돌아가 보겠습니다. 다음은 예산이 한정된 경우 따라야 할 몇 가지 지침입니다. 정확히 이 순서대로 Core Web Vitals를 조사하기 시작하고 다음 문제들에 먼저 집중하세요!

• Time to First Byte를 통과하지 못한다면 그것부터 고치세요!
• First Contentful Paint를 통과하지 못한다면 렌더링 차단 리소스를 수정하세요(스크립트 지연 및 스타일 최적화).
• Largest Contentful Paint를 통과하지 못한다면 해당 LCP에 필요한 리소스의 우선순위를 지정하세요(글꼴이나 이미지 등).
• CLS를 통과하지 못한다면 모든 이미지에 width와 height를 추가하고, CSS 트랜지션을 찾아 제거하며, 늦게 렌더링되는 요소(광고, 제품 필터 등)를 위한 공간을 예약하세요.
• Interaction to Next Paint를 통과하지 못한다면 잘못된 타이밍에 너무 많은 JavaScript를 사용하고 있을 가능성이 높습니다. 불필요한 스크립트와 플러그인을 제거하고, CoreDash와 같은 RUM 도구를 사용하여 가장 느린 스크립트를 찾으세요.

2. 이미지 최적화하기

2025 Web Almanac에 따르면 이미지는 모바일 페이지 중간값 기준 911KB를 차지합니다. 이는 전체 페이지 무게의 3분의 1이 넘는 수치입니다. 그리고 동일한 품질에서 WebP가 더 작음에도 불구하고 57%의 LCP 이미지가 여전히 JPG로 제공되고 있습니다. 제한된 예산 하에서 이미지 최적화는 최소한의 노력으로 최대의 효과를 제공합니다.

무료로 이미지를 WebP로 변환하기

이미지를 WebP와 같이 더 새롭고 빠르며 최신 형식으로 변환할 수 있는 무료 도구, 솔루션 및 플러그인이 많이 있습니다. 예를 들어 WordPress의 경우 훌륭하고 무료인 WebP Express를 추천합니다.

지연 로딩(lazy loading) 구현하기

지연 로딩은 이미지가 보이는 뷰포트에 거의 들어올 때까지 로드되지 않아야 함을 브라우저에 신호로 보냅니다. 페이지에 15개의 이미지가 있고 그중 3개만 페이지의 보이는 부분에 있다면, 보이지 않는 뷰포트에 있는 이미지에 안전하게 loading="lazy"를 추가할 수 있습니다.

이 문제를 해결하는 방법에는 2가지가 있습니다. 첫 번째는 CMS에서 지연 로딩을 활성화하는 것입니다. 이렇게 하면 모든 이미지에 지연 로딩이 추가됩니다. 그런 다음 보이고 중요한 이미지에 대해 지연 로딩을 제거하는 방법을 설명서에서 참조하세요. 다른 방법은 스크롤 아래(below-the-fold) 이미지에 수동으로 loading="lazy"를 추가하는 것입니다. 전체 가이드는 화면 밖 이미지 지연 방법을 참조하세요.

<img loading="lazy" src="image.jpg" width="800" height="600">

이미지 fetchpriority 설정하기

이미지 태그에 fetchpriority="high"를 추가함으로써 우리는 브라우저에 이 이미지가 다른 이미지들보다 더 중요하며 가장 먼저 다운로드되어야 한다는 신호를 보냅니다. 이미지 사전 로드(preloading) 및 103 Early Hints를 포함하는 더 나은 방법들이 있지만, fetchpriority 설정은 간단하고 빠르며 효과적입니다! 페이지에서 가장 중요한 이미지를 식별하고 템플릿을 편집하여 이미지에 fetchpriority="high"를 추가하기만 하면 됩니다.

<img fetchpriority="high" src="image.jpg" width="800" height="600">

3. 브라우저 캐싱 수정하기

예산 친화적인 호스팅을 사용하고 있다면 웹 서버가 최적으로 구성되지 않았을 가능성이 있습니다. 제가 정기적으로 접하는 실수 중 하나는 잘못 구성된 브라우저 캐싱입니다. 적절한 캐싱 헤더가 없으면 재방문자는 동일한 이미지, 스크립트 및 스타일시트를 다시 다운로드하게 됩니다. 이는 대역폭과 시간의 낭비입니다.

웹 서버로 Apache를 사용하는 경우 웹사이트의 루트 디렉터리에 .htaccess라는 파일을 만들고 다음 줄을 추가하기만 하면 됩니다.

<FilesMatch "\.(ico|pdf|jpg|jpeg|png|webp|gif|css|js|woff|woff2)$">
  <IfModule mod_headers.c>
    Header set Cache-Control "max-age=172800, public, must-revalidate"
  </IfModule>
</FilesMatch>

.htaccess 파일을 편집하는 동안 GZIP 압축도 활성화하세요. 이것은 브라우저로 전송하기 전에 텍스트 기반 리소스(HTML, CSS, JavaScript)를 압축합니다. 대부분의 사이트에서 이는 전송 크기를 60~80%까지 줄여줍니다.

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript
  AddOutputFilterByType DEFLATE application/javascript application/json
</IfModule>

NGINX와 같은 다른 웹 서버를 사용하는 경우 호스팅 제공업체에 연락하여 이 문서를 보여주세요!

4. Cloudflare 고려하기 (무료 플랜도 도움이 됩니다)

무료 플랜에서도 Cloudflare는 중요한 성능 기능의 많은 부분을 제공합니다. 예산 호스팅을 사용 중이라면 DNS를 Cloudflare로 전환하는 것은 최소한의 노력으로 최대한의 효과를 낼 수 있는 변경 사항 중 하나입니다. 자세한 설명은 완벽한 Cloudflare 구성 가이드를 참조하세요.

무료 플랜에서

1. 빠른 DNS. Cloudflare DNS 서버는 무료이며 아마도 예산 호스팅 제공업체의 DNS 서버보다 성능이 뛰어날 것입니다. 2025 Web Almanac의 CrUX 데이터에 따르면 모바일 오리진의 44%만이 좋은 TTFB를 가지고 있습니다. 느린 DNS가 일반적인 원인이며, Cloudflare로 전환하면 즉시 이 문제를 해결할 수 있습니다.
2. HTTP/3 및 Brotli. Cloudflare는 최신 프로토콜과 가장 빠른 압축 방법을 사용합니다. 자세히 설명하지 않더라도, 이로 인해 네트워크 속도가 최소 10% 이상 빨라질 것이라고 확신하셔도 좋습니다.
3. 일관된 브라우저 캐싱. Cloudflare는 정적 리소스를 캐싱하는 데 있어 강력한 실적을 보유하고 있습니다. 기본 구성이 아마도 현재 사용 중인 것보다 나을 것입니다.
4. 정적 리소스를 위한 엣지 캐싱. Cloudflare는 이미지, 스크립트 및 CSS 파일과 같은 정적 리소스의 버전을 캐시하고 엣지 네트워크에서 최종 사용자에게 직접 제공합니다. 이렇게 하면 오리진 서버로 왕복할 필요가 없어집니다.
5. Rocket Loader. Rocket Loader는 스크립트 로드를 지연시키고 이로 인해 발생하는 복잡한 문제를 처리합니다. 투박한 방법이긴 하지만 수동으로 스크립트를 지연시킬 수 없는 경우 Largest Contentful Paint와 같은 페인트 지표를 향상시킬 수 있습니다. 참고: Rocket Loader는 더 이상 사용되지 않는 브라우저 API를 사용하며 PageSpeed Insights에서 이를 표시할 수 있습니다. 이러한 경고가 표시되면 수동으로 스크립트를 지연시키는 것을 고려하세요.

Pro 플랜에서

무료 Cloudflare 플랜을 볼 때마다 가장 먼저 하는 말 중 하나는 "Pro로 가세요!"입니다. 더 빠른 사이트를 위해 $25를 지불할 여유가 있고 의향이 있다면 고려해 보는 것이 좋습니다.

1. 모든 무료 기능. 당연히 Pro 플랜에는 모든 무료 기능이 포함됩니다.
2. WordPress용 Cloudflare APO. WordPress용 APO는 방문자가 로그인하지 않은 경우 엣지 네트워크에 페이지를 캐시하는 완벽한 솔루션입니다. 이는 Time to First Byte 속도를 엄청나게 높일 수 있습니다.
3. 무손실 및 손실 이미지 최적화. Cloudflare Pro 버전을 사용하는 주요 이점 중 하나는 이미지 최적화입니다. Cloudflare는 이미지를 WebP 형식으로 변환 및 캐시하고 이러한 형식을 허용하는 방문자에게만 제공합니다.

5. 가능한 한 많이 셀프 호스팅하기

간단하고 효과적인 또 다른 최적화는 정적 리소스를 셀프 호스팅하는 것입니다. 많은 사이트에서 정적 리소스는 외부 CDN에서 호스팅됩니다. 예를 들어 jQuery는 https://code.jquery.com/에서, Bootstrap은 https://cdn.jsdelivr.net에서, 글꼴은 https://fonts.googleapis.com에서 호스팅됩니다. 매력적이라는 점은 이해합니다. 이러한 CDN은 쉽고 빠른 것처럼 보이지만 실제로 사용하는 것은 좋지 않은 아이디어이며 사이트 속도를 늦춥니다.

이러한 유형의 파일에 공유 CDN을 사용한다는 아이디어는 브라우저가 아직 웹사이트 간에 이러한 파일을 공유할 수 있었을 때는 타당했습니다. 그런 시대는 지났습니다. 결과적으로 새로운 방문자는 항상 정적 파일을 다운로드해야 하며 각 파일에 대해 새로운 서버에 새롭게 연결해야 합니다. 그리고 이러한 새로운 서버에 대한 새로운 연결은 많은 추가 시간을 소모할 수 있습니다.

해결책은 해당 타사 파일을 셀프 호스팅하는 것입니다. 이 작업은 쉽습니다. 파일을 다운로드하여 서버에 배치하고 해당 파일에 대한 참조를 변경하기만 하면 됩니다. 특히 글꼴의 경우 Google Fonts를 셀프 호스팅하는 방법을 참조하세요.

6. 스크립트 지연시키기

거대한 병목 현상은 페이지의 head에 있는 스크립트를 차단하는 것일 수 있습니다. 이러한 스크립트는 때때로 페이지 로딩을 최대 20초까지 지연시킬 수 있습니다! 2025 Web Almanac에 따르면 모바일 페이지의 15%만이 렌더링 차단 리소스 감사를 통과하는 것으로 나타났습니다. 이는 이 문제가 얼마나 널리 퍼져 있는지 알려줍니다.

이러한 스크립트를 지연시키는 것은 전혀 어렵지 않습니다. 스크립트 태그에 defer를 추가하기만 하면 완료됩니다. 가능하다면 이렇게 하세요! 템플릿을 편집하고 다음과 같이 스크립트를 변경하세요.

<!-- 기존의 차단 스크립트 태그 -->
<script src="script.js"></script>

<!-- 새로운 지연 스크립트 태그 -->
<script defer src="script.js"></script>

하지만 함정이 있습니다! 스크립트 태그에 defer를 추가하면 온갖 종류의 문제와 종속성 오류가 발생할 수 있습니다. 그리고 예산이 부족하기 때문에 발생할 수 있는 모든 문제를 해결하기 위해 JavaScript 전문가를 고용할 여유가 없다고 가정해야 합니다. 따라서 스크립트를 지연시키고 오류가 있는지 확인해 보세요(Chrome에서 Ctrl+Shift+I를 누르고 console 탭 확인). 테스트 후 문제가 없다면 운이 좋은 소수에 속합니다! 문제가 있는 경우 다음 솔루션 중 하나를 사용해야 합니다. 전체 내용을 보려면 JavaScript를 지연시키는 16가지 방법을 참조하세요.

Rocket Loader 사용하기

앞서 논의한 바와 같이 Cloudflare의 무료 버전은 Rocket Loader에 대한 액세스를 제공합니다. 이것은 페이지의 모든 스크립트를 지연시킵니다. 결코 완벽하지는 않지만 대부분의 경우 꽤 훌륭하게 작동합니다.

플러그인 사용하기

대부분의 CMS 기반 사이트에는 거대한 플러그인 저장소가 있습니다. JavaScript를 지연시키고 스크립트 지연에 수반될 수 있는 모든 복잡한 문제를 처리해 주는 수많은 플러그인이 있습니다.

7. 글꼴 최적화하기

웹 글꼴은 예산 사이트에서 숨겨진 성능 비용입니다. 2025 Web Almanac에 따르면 중간값 페이지는 122KB의 글꼴 파일을 로드합니다. Google Fonts에서 글꼴을 로드하는 경우 처음 방문할 때마다 추가적인 DNS 조회 및 TCP 연결을 만들게 됩니다.

두 가지 무료 해결책:

1. 글꼴을 셀프 호스팅하세요. 글꼴 파일을 다운로드하여 자체 서버에 배치하고 거기서 로드하세요. 이렇게 하면 fonts.googleapis.com 및 fonts.gstatic.com에 대한 연결 오버헤드가 제거됩니다.
2. font-display: swap을 추가하세요. 이것은 웹 글꼴이 다운로드되는 동안 즉시 fallback 글꼴로 텍스트를 표시하도록 브라우저에 지시합니다. 방문자는 콘텐츠를 더 빨리 보게 되고 보이지 않는 텍스트 문제를 피할 수 있습니다. 전체 전략은 웹 글꼴 로드 중 보이지 않는 텍스트 수정 방법을 참조하세요.

8. 캐싱, 캐싱, 캐싱

예산이 한정되어 있고 호스팅에 많은 비용을 지불하고 싶지 않을 때, 캐싱은 웹사이트 속도를 높이는 가장 효과적인 방법 중 하나입니다. 캐싱은 특히 높은 Time to First Byte에 효과적입니다. 캐싱은 다양한 수준에서 수행할 수 있습니다.

클라이언트 측 캐시: 브라우저가 가능한 한 많은 정적 리소스를 캐시하도록 지시하게끔 웹 서버를 구성하세요. 이렇게 하면 서버의 부하가 감소합니다. (섹션 3의 .htaccess 예제를 참조하세요.)

객체 캐시(Object cache): 객체 캐시는 복잡한 데이터베이스 쿼리의 결과와 같이 재생성하는 데 계산 비용이 많이 들 수 있는 데이터를 저장하는 데 사용할 수 있습니다. 호스팅 업체에 Redis 또는 Memcached를 설치해 달라고 요청하세요.

전체 페이지 캐시(Full page cache): CMS를 사용 중이라면 사이트에 전체 페이지 캐시를 추가하고 싶을 것입니다. WordPress의 경우 WP Fastest Cache 또는 WP Core Web Vitals가 좋은 선택입니다.

9. 전략적인 호스팅 선택하기

호스팅에 있어서는 여러 곳을 비교해 보는 것이 좋으며, 가장 비싼 호스팅이 항상 가장 빠른 것은 아닙니다. 일반적으로 CMS에 최적화된 호스팅 플랜을 찾는 것이 좋습니다. 만물상과 같은 곳은 무엇 하나 전문적이지 않기 때문입니다. 최소한 PHP 8+, HTTP/2 및 SSD 스토리지를 포함하는 호스팅을 찾으세요. 이러한 기본 사항을 갖춘 좋은 WordPress 호스트는 항상 일반적인 공유 호스트보다 성능이 뛰어납니다.

10. 성능 모니터링하기

이 모든 최적화는 실제로 효과가 있었는지 모른다면 아무 가치가 없습니다. 실험실에서 Lighthouse가 평가하는 방식뿐만 아니라 실제 방문자가 사이트를 어떻게 경험하는지 볼 수 있도록 Real User Monitoring을 설정하세요. 실험실 점수는 디버깅에 유용하지만, Google이 순위를 매기는 데 사용하는 것은 실제 방문자의 필드 데이터입니다. CoreDash는 실제 사용자의 Core Web Vitals를 추적하여 현재 상태를 정확히 알려줍니다.