압축 된 버전의 콘텐츠 만 제공하는 경우 연결 수락 인코딩 헤더를 추가해야하나요?


11

방금 정적 사이트를 VPS에서 Amazon S3로 옮겼습니다. S3는 웹 서버가 아니므로 헤더를 기반으로 한 논리를 가질 수 없기 때문에 내 페이지의 압축 버전 만 제공하기로 결정했습니다. 또한 Cloudfront를 CDN으로 사용합니다.

http://gtmetrix.com/으로 내 페이지를 테스트하고 있었고를 추가하지 않아서 잘못된 메모를 받았습니다 vary accept encoding header. 그래서 이것이 무엇인지 확인했으며 압축 버전과 압축되지 않은 버전을 모두 제공 할 때 이해가되는 한 이해합니다.

이를 명확하게 설명해 드리겠습니다. 추가해야합니까? 감사 :)

답변:


7

내 페이지의 압축 된 버전 만 제공하기로 결정했습니다.

gzip 을 사용하여 압축 한 파일 만 제공하는 경우 HTTP 요청 에서 Vary: Accept-Encoding전송하지 않는 클라이언트에 제공 할 파일의 압축되지 않은 사본이 없기 때문에 사용 하면 도움이되지 않습니다 . 요즘 대부분의 고객이 이것을 보내므로 괜찮을 것입니다.Accept-Encoding: gzip

온라인 웹 사이트 성능 테스트는 압축 파일 만 제공한다는 사실을 알지 못하며 그 자체도 완벽하지는 않습니다. 예를 들어 사용하는 서비스에이 열이라는 열 아래에 나열되어 RECOMMENDATION있으므로 너무 염려되거나 구현하려고 시도하기 전에 이와 같은 제안을 실제로 찾아내는 것이 좋습니다.


난 그냥 내 의심이 게시물에서 온 것으로, 추가 할 : maxcdn.com/blog/accept-encoding-its-vary-important
케빈

너는 괜찮아. 이 기사에서는 Vary: Accept-EncodingCDN과 함께 오리진 서버에서의 사용 에 대해 설명 합니다. 당신이 지적했듯이, 오리진 서버는 이것을 제공하지 않으며 Google에 따르면 여기에서 더 이상 필요하지 않습니다 . All modern browsers support and automatically negotiate gzip compression for all HTTP requests.따라서 모든 사이트에서 gzip 을 사용하는 것이 좋습니다 . 그 기사 (2013 These days you're unlikely to have clients without compression, but why risk cache mixups?
dan

1
압축 파일 만 제공하기 때문에 "캐시 믹스 업"(예 : 동일한 파일의 압축되지 않은 버전)은 현재 상황에 적용되지 않습니다.
dan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.