고주파 게시 시대의 프런트엔드 제공에서는 캐싱 및 압축 협업을 재설계해야 합니다.

프런트엔드 리소스가 고주파 릴리스 리듬에 진입하면 성능 문제는 곧 더 이상 "Brotli 켜기"만큼 간단하지 않게 됩니다. 첫 번째 화면에서는 속도가 느려지고 원본으로 돌아가는 트래픽이 증가하며 엣지 노드 CPU가 지터집니다. 표면적으로는 압축이 충분히 공격적이지 않은 것 같습니다. 더 자세히 살펴보면 캐싱과 압축이 개별적으로 최적화되어 결국 게시 링크에서 서로를 약화시키는 경우가 많습니다.

이런 종류의 문제는 일반적으로 첫 번째 버전에서는 노출되지 않습니다. 처음에는 팀에 약간의 분산된 신호만 표시되었습니다. 작은 변화로 인해 정적 리소스의 적중률이 저하되고, 주요 프로모션 전날 엣지 압축 CPU가 비정상적으로 증가했으며, 그레이스케일 단계의 반환 패킷 볼륨이 공식 트래픽과 일치하지 않았습니다. 계속 확인하면 단서는 대개 같은 것으로 수렴됩니다. 리소스 내용은 약간만 변경되었지만 캐시 키, 청크 분할 및 압축된 입력은 다른 집합이 되었으며 전송 계층은 전체 비용을 다시 삼킬 수밖에 없습니다.

리소스 해시가 안정될 때까지는 압축 이점을 누릴 수 없습니다.

여러 페이지, 여러 경로, 여러 팀으로 프런트엔드 프로젝트를 병렬로 릴리스한 후 가장 쉽게 간과되는 측면은 파일 이름 안정성입니다. 청크 분할이 약간만 표류하는 한 비즈니스 코드가 버튼의 복사본만 변경하더라도 최종 제품은 일련의 공개 번들의 해시를 다시 작성할 수도 있습니다. 캐싱 시스템이 보는 것은 새로운 객체의 배치이고, 압축 시스템이 보는 것은 처음으로 나타나는 입력의 배치입니다.

이때 압축률이 아무리 높아도 적중률이 무너지는 것을 막을 수는 없습니다. 이전 파일은 여전히 ​​에지 노드에 있고 새 파일의 키가 다시 입력되었습니다. 브라우저의 로컬 캐시는 완전히 유효하지 않으며 CDN은 소스를 다시 가져오고, 다시 압축하고, 다시 배포해야 합니다. 소규모 비즈니스 변경은 전체 전송 링크에 대한 반복 작업으로 확대됩니다.

실제로 유용한 작업은 일반적으로 압축 수준을 계속해서 조정하는 것이 아니라 먼저 출시된 제품의 안정성을 제어하는 것입니다.

• 공용 종속성을 별도의 레이어로 나누어 비즈니스 변경을 줄이고 기본 패키지를 모아 해시를 변경합니다.
• 타임스탬프, 빌드 번호 등 자주 발생하는 변경 사항을 제품 콘텐츠에 직접 혼합하지 마세요.
• 동일한 경로 근처의 코드는 컴파일할 때마다 다시 섞이지 않고 가능한 한 안정적인 덩어리로 분류되도록 합니다.

리소스 아이덴티티가 안정화되어야 캐시를 지속적으로 재사용할 수 있으며 압축 결과는 누적된 가치를 갖습니다.

고주파 기자간담회, 압축 문제를 사전 버전 문제로 다시 쓴다

리소스가 점점 더 단편화됨에 따라 단일 파일 Brotli 또는 gzip은 여전히 중요하지만 더 이상 전부는 아닙니다. 실제 비용은 중복된 부분으로 이동하기 시작합니다. 프레임워크 런타임 코드, 스타일 템플릿, 인터페이스 유형 선언, 패키저에서 생성된 패키징 레이어는 버전 배치 간에 매우 유사한 경우가 많습니다. 빠른 릴리스 템포를 사용하면 이러한 리프가 계속해서 전송됩니다.

문제는 압축 사전이 릴리스 흐름에 따라 관리되지 않으면 쉽게 최적화에서 중단으로 바뀔 수 있다는 것입니다. 사전을 미리 전환하면 이전 페이지에서 참조하는 새 사전이 일치하지 않습니다. 사전이 너무 많은 조각으로 잘려지고 에지 노드에서 유지 관리해야 하는 버전 수가 급격히 증가합니다. 사전 업데이트는 온라인 리소스와 동기화되지 않으며 적중되어야 하는 개체는 전체 전송으로 반환됩니다.

이는 최근 프런트엔드 전달의 매우 실용적인 변화이기도 합니다. 캐싱 전략과 압축 프로토콜은 더 이상 다른 팀에서 유지 관리할 수 없습니다. 리소스 버전, 사전 버전 및 캐시 키 공간은 본질적으로 동일한 게시 문제입니다.

다음과 같은 계층적 접근 방식은 일반적으로 "전체 사이트에 대한 통합된 강력한 압축"보다 더 안정적입니다.

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

핵심은 이 세 줄의 구성 자체가 아니라 그것이 표현하는 제약 조건입니다. 긴 수명 주기 리소스, 짧은 수명 주기 목록, 압축된 사전 버전은 동일한 릴리스 리듬에 따라 함께 발전해야 합니다.

원본으로 돌아가야 한다는 압박감은 파일이 너무 커서가 아니라 실패 방법이 너무 거칠기 때문인 경우가 많습니다.

또 다른 매우 일반적인 잘못된 판단은 대역폭 증가를 페이지 무게에 직접적으로 돌리는 것입니다. 페이지는 확실히 점점 무거워지고 있지만 온라인에서 더 위험한 앰프를 사용하는 것이 일반적입니다.

게시할 때마다 디렉터리, 접두사 또는 전체 사이트를 기준으로 제거하면 캐시 레이어의 메모리가 즉시 손실됩니다. 이때, 파일 크기가 계속 커지지 않더라도 원점 복귀 피크 값은 저절로 올라가게 됩니다. 소스가 반환되자마자 가장자리가 다시 압축되고 개체가 다시 따뜻해지며 브라우저가 다시 다운로드됩니다. 게시 기간은 작은 단계 변경에서 전체 사이트 재배치로 변경됩니다.

이러한 유형의 시나리오에서 가장 중요한 것은 제어 가능한 오류 반경입니다.

• 실제로 변경된 매니페스트, HTML 및 변경 가능한 리소스만 무효화합니다.
• 해시가 포함된 정적 파일을 제거하지 말고 자연스러운 전환을 위해 새로운 참조로 넘겨주세요.
• 한 번에 모두 삭제하는 대신 "먼저 새 리소스를 업로드한 다음 참조를 잘라낸 다음 이전 리소스를 재활용"하는 순서로 릴리스를 분할합니다.

전송 비용과 관련해 정말 민감한 점은 파일 크기뿐 아니라 시스템이 어떤 콘텐츠를 다시 가져와야 하는지 결정하는 방법입니다.

적용 가능한 경계는 자원 규모, 출시 빈도와 함께 결정됩니다.

이 공동 디자인 세트가 모든 사이트에 필요한 것은 아닙니다. 정적 페이지 수가 적고 리소스 패키지가 적으며 릴리스 빈도가 매주 또는 매월인 프로젝트의 경우 일반적으로 기존 해시 파일 이름과 Brotli 사전 압축을 사용하는 것이 충분히 안정적입니다.

다음과 같은 특성이 갖춰지면 캐싱과 압축을 함께 사용하여 빠르게 전달 인프라가 됩니다.

• 그레이스케일, 롤백 또는 지역 출시를 통해 하루에 여러 번 출시됩니다.
• 프론트엔드 제품은 크기가 크고, 공개 종속성이 많고, 청크 관계가 복잡합니다.
• CDN, 객체 스토리지, 엣지 압축 및 브라우저 캐싱이 동시에 전송 링크에 참여합니다.
• 트래픽이 너무 많아서 캐시 적중률과 원점 복귀 피크 값이 비용과 안정성을 직접적으로 반영합니다.

프런트 엔드 전달이 이 단계에 진입하면 압축은 더 이상 "파일을 더 작게 만드는 것"이 ​​아니며, 캐싱은 더 이상 "더 많은 콘텐츠 복사본을 저장하는 것"이 ​​아닙니다. 두 사람이 함께 결정하는 것은 소규모 비즈니스 변경의 경우 청크를 하나 더 보내는 것인지, 아니면 전체 전송 링크를 다시 실행해야 하는지 여부입니다. 게시 빈도가 높을수록 이 차이의 비용은 더 커집니다.