DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

Nginx Gzip 압축: 웹사이트 로딩 속도 향상

Nginx Gzip 압축을 활성화하여 텍스트 기반 응답을 줄이고 페이지 로딩 속도를 높이는 방법 — 안전한 설정, 대상 MIME 유형, 테스트 방법, CDN 고려 사항을 다룹니다.

Nginx Gzip 압축: 웹사이트 로딩 속도 향상

Nginx Gzip 압축은 텍스트 기반 응답을 네트워크로 전송하기 전에 축소하여 웹사이트 로딩 속도를 높입니다. 페이지에 HTML, CSS, JavaScript, JSON, XML 또는 SVG 파일이 포함된 경우 압축을 통해 사용자가 브라우저에서 보는 내용을 변경하지 않고 전송 크기를 줄일 수 있습니다.

목표는 간단합니다. 더 적은 바이트를 보내고, 대기 시간을 줄이며, 대역폭을 더 효율적으로 사용하는 것입니다. 대부분의 프로덕션 사이트에서 Gzip은 안전하게 활성화할 수 있는 가장 쉬운 Nginx 성능 향상 방법 중 하나입니다.

Nginx에서 Gzip 압축 작동 방식

Gzip 압축은 Nginx가 응답을 선택한 후 클라이언트로 보내기 전에 발생합니다. 브라우저는 Accept-Encoding 요청 헤더로 지원을 알립니다. Gzip이 활성화되고 응답 유형이 구성과 일치하면 Nginx는 본문을 압축하고 Content-Encoding: gzip과 함께 전송합니다.

이 방식은 텍스트 형식에 반복되는 패턴이 포함되어 있기 때문에 가장 효과적입니다. HTML 템플릿, CSS 클래스 이름, JavaScript 식별자, JSON 키는 일반적으로 매우 잘 압축됩니다. 이미지, 비디오, PDF, 아카이브는 이미 압축된 경우가 많으므로 Gzip으로 압축하려고 하면 파일 크기를 크게 줄이지 못하고 CPU만 낭비할 수 있습니다.

기본 구성은 일반적으로 http 블록에 배치하여 모든 서버 블록에 적용됩니다:

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

gzip on 지시문은 압축을 활성화합니다. gzip_types는 기본 text/html 외에 압축할 MIME 유형을 Nginx에 알려줍니다. gzip_min_length는 Gzip 헤더 오버헤드가 이점을 상쇄할 수 있는 작은 응답에 CPU를 낭비하지 않도록 합니다.

gzip_vary on은 Vary: Accept-Encoding 헤더를 추가합니다. 이는 사이트가 CDN 또는 공유 캐시 뒤에 있는 경우 중요합니다. 캐시는 압축된 버전과 압축되지 않은 버전이 동일한 URL의 다른 변형임을 알아야 하기 때문입니다.

더 넓은 Nginx 성능 기준을 위해 Nginx 성능 튜닝을 검토할 수도 있습니다.

사람들을 종종 놀라게 하는 한 가지 세부 사항: Nginx는 Gzip이 활성화되면 항상 text/html을 압축하므로 gzip_types에 text/html을 포함할 필요가 없습니다. 추가하면 Nginx가 MIME 유형이 중복되었다고 경고할 수 있습니다. 이 경고는 무해하지만 구성이 정리되지 않고 복사되었음을 나타냅니다.

안전한 압축 설정 선택

Nginx Gzip 압축의 가장 큰 실수는 압축 수준을 볼륨 노브처럼 취급하는 것입니다. 높을수록 항상 좋은 것은 아닙니다. Gzip 수준은 일반적으로 1에서 9까지입니다. 수준 1은 가장 빠르지만 덜 압축합니다. 수준 9는 더 많이 압축하지만 CPU 비용이 눈에 띄게 증가할 수 있습니다.

많은 웹사이트의 경우 gzip_comp_level 4, 5 또는 6이 실용적인 범위입니다. 서버에 너무 많은 부담을 주지 않으면서 강력한 압축을 제공합니다. Nginx 서버가 높은 트래픽을 처리하거나 소규모 인스턴스에서 실행되는 경우 수준 9로 바로 건너뛰지 마십시오.

좋은 기본값은 다음과 같습니다:

  • 균형 잡힌 설정을 위해 gzip_comp_level 5 사용.
  • 작은 응답이 압축을 건너뛰도록 gzip_min_length 1024 사용.
  • 이미 압축된 미디어가 아닌 텍스트 기반 자산을 압축.
  • 캐시 또는 CDN이 관련된 경우 gzip_vary on 유지.
  • 압축 활성화 후 CPU 사용량 테스트.

일반적인 시나리오는 다음과 같습니다. CSS, JavaScript 및 HTML 페이지가 많은 문서 사이트를 운영한다고 가정합니다. Gzip 전에는 페이지가 650KB의 텍스트 자산을 로드합니다. 압축을 활성화하면 전송 크기가 급격히 줄어들 수 있으며, 브라우저는 압축 해제 후에도 동일한 파일을 수신합니다. 느린 연결을 사용하는 사용자가 가장 큰 개선 효과를 봅니다.

이득은 모든 사이트에서 동일하지 않습니다. JPEG 이미지가 주를 이루는 페이지는 Gzip으로 크게 개선되지 않습니다. 대용량 JSON 응답을 보내는 대시보드는 많이 개선될 수 있습니다.

API의 경우 더 신중해야 합니다. {"ok":true}와 같은 작은 JSON 응답을 압축하는 것은 일반적으로 의미가 없습니다. 300KB 검색 결과 또는 보고 페이로드를 압축하는 것은 가치가 있습니다. API가 개인 데이터를 반환하고 동일한 응답에 사용자 제어 입력을 반영하는 경우 애플리케이션 팀과 압축 위험에 대해 논의한 후 모든 곳에서 활성화하십시오. 이것이 "API를 절대 압축하지 마라"는 의미는 아닙니다. 압축은 캐싱, 쿠키 및 응답 헤더와 동일한 검토 범주에 속한다는 의미입니다.

Gzip이 작동하는지 테스트하는 방법

Nginx 구성을 변경한 후 다시 로드하기 전에 구문을 테스트하십시오:

nginx -t

그런 다음 서비스 관리자 또는 배포 프로세스를 통해 Nginx를 다시 로드하십시오. 이는 구성 변경이므로 전체 바이너리 재시작이 아니므로 다시 로드로 충분합니다.

curl로 응답을 확인할 수 있습니다:

curl -I -H "Accept-Encoding: gzip" https://example.com/app.css

다음 헤더를 찾으십시오:

Content-Encoding: gzip

또한 다음을 확인하십시오:

Vary: Accept-Encoding

Content-Encoding: gzip이 보이지 않으면 응답 MIME 유형을 확인하십시오. 예를 들어 text/plain으로 제공되는 JavaScript 파일은 text/plain이 포함된 경우 계속 압축될 수 있지만, 특이한 콘텐츠 유형을 사용하는 사용자 정의 API 응답은 gzip_types 목록과 일치하지 않을 수 있습니다.

브라우저 개발자 도구도 도움이 될 수 있습니다. 네트워크 탭을 열고 페이지를 다시 로드한 후 응답 헤더와 전송된 크기를 검사하십시오. 압축 가능한 파일의 경우 전송된 크기가 압축되지 않은 리소스 크기보다 작아야 합니다.

또한 CDN을 사용하는 경우 CDN이 자체 압축을 수행할 수 있음을 기억하십시오. 이 경우 Nginx가 브라우저가 수신하는 내용을 결정하는 최종 계층이 아닐 수 있습니다. 가능하면 직접 오리진 액세스와 공개 CDN URL을 모두 테스트하십시오.

직접 오리진 응답은 압축되었지만 CDN 응답은 압축되지 않은 경우 CDN의 압축 설정과 캐시 키 동작을 확인하십시오. CDN 응답은 압축되었지만 오리진이 압축되지 않은 경우 괜찮을 수 있습니다. 많은 팀이 오리진 구성을 더 간단하게 유지하면서 CDN이 공개 정적 압축을 처리하도록 의도적으로 허용합니다.

Gzip에 주의해야 할 경우

Gzip은 대부분의 정적 및 동적 콘텐츠에 안전하지만, 천천히 진행하고 신중하게 테스트해야 하는 경우가 있습니다.

이미 압축된 파일은 압축하지 마십시오. 일반적인 예는 다음과 같습니다:

  • .jpg, .jpeg, .png, .webp
  • .mp4, .mov 및 기타 비디오 형식
  • .zip, .gz, .tar.gz 및 패키지 아카이브
  • 형식 및 전달 경로에 따른 대부분의 글꼴 파일

또한 CPU 사용량을 주시해야 합니다. 압축은 무료가 아닙니다. 서버가 이미 CPU 한도에 가깝게 실행 중인 경우 공격적인 압축을 활성화하면 부하가 걸릴 때 응답 시간이 더 나빠질 수 있습니다. 적당한 설정으로 시작한 다음 트래픽, 지연 시간 및 CPU를 모니터링하십시오.

보안에 민감한 애플리케이션은 공격자가 제어하는 입력 옆에 압축된 응답에 비밀을 노출하지 않도록 해야 합니다. 이는 더 전문화된 위험이지만, 토큰이나 개인 데이터가 포함된 페이지에 사용자 입력을 반영하는 앱에 대해 알아두는 것이 좋습니다.

정적 자산의 경우 빌드 파이프라인 중에 파일을 사전 압축하고 디스크에서 .gz 버전을 제공하는 또 다른 옵션이 있습니다. 이는 특히 대용량 JavaScript 번들의 경우 런타임 CPU를 줄일 수 있습니다. 동적 API 응답은 압축하려면 여전히 런타임 압축이 필요합니다.

사전 압축된 파일을 제공하는 경우 gzip_static on;을 활성화하고 .gz 파일이 압축되지 않은 파일과 정확히 동일한 자산 버전에서 생성되었는지 확인하십시오. 최신 app.js 옆에 오래된 app.js.gz가 있으면 실망스러운 버그입니다. Gzip을 요청하는 클라이언트만 이전 코드를 보게 됩니다.

gzip_static on;

이 지시문은 빌드 아티팩트에 유용하며 동적 업스트림 응답에는 유용하지 않습니다. 앱 서버에서 프록시된 동적 응답의 경우 업스트림이 이미 압축된 본문을 보내지 않는 한 Nginx는 여전히 런타임 압축이 필요합니다.

도움이 필요할 때

Gzip 활성화로 인해 높은 CPU, 일관되지 않은 CDN 동작 또는 이전 클라이언트에 대한 응답 손상이 발생하는 경우 숙련된 Nginx 관리자 또는 DevOps 엔지니어에게 문의하십시오. 또한 여러 포함된 구성 파일에 압축 설정이 혼합되어 있고 어떤 블록이 실제로 활성화되어 있는지 확실하지 않은 경우 도움을 받아야 합니다.

간단한 웹사이트의 경우 Gzip을 몇 분 안에 활성화할 수 있습니다. 트래픽이 많은 애플리케이션의 경우 다른 성능 변경과 마찬가지로 테스트하고, 점진적으로 롤아웃하고, 결과를 모니터링하십시오.

Nginx Gzip 압축은 텍스트가 많은 사이트와 API의 로딩 속도를 높이는 실용적인 방법입니다. MIME 유형을 집중하고, 적당한 압축 수준을 선택하고, 다시 로드 후 헤더를 확인하십시오. 작동하면 애플리케이션 코드는 그대로 유지되면서 사용자는 더 작은 응답을 받게 됩니다.