내가 웹 표준을 변경하지 않고 가능한 것 같습니다 무엇으로 최상의 결과를 얻을 수있는 방법을 찾기 위해 관련 문제를 연구하기 시작했고, 나는 캐싱에 대해 궁금 :
업데이트 나는 하나를 발견했다. 페이지의 모든 하위 리소스의 최종 수정 날짜를 초기 HTML 페이지와 함께 보낼 수 있다면 브라우저는 모든 리소스를 한 번 이상로드 한 후에 수정 된 헤더를 묻지 않을 수 있습니다. 처음 요청시에만 모든 리소스를 보내는 것이 좋을 것입니다. 브라우저가 캐시를 사용하는 것이 더 좋을 것이므로 (Barmar가 지적한대로) 첫 번째로드에서만 유용 할 것이고 후속로드에 좋지 않을 것이므로, .
이제 웹 확장을 사용하더라도 if-modified-since 헤더를 얻을 수 없으므로 서버에 접속하는 대신 캐시 된 버전을 사용하도록 브라우저에 지시 할 수는 없습니다.
그때 그들의 정적 파일을 해시하고 그들에게 1 년의 유효 기간을 제공함으로써 트래픽을 줄이기 위해 시도하는 방법에 Facebook에서 해당 게시물을 발견했다. 이것은 url이 파일의 내용을 보관한다는 것을 의미합니다. 그들은 여전히 불필요한 if-modified-since 요청을 보았고, Firefox와 Chrome이 재로드 버튼의 동작을 변경하여 정적 리소스를 다시로드하지 않도록 설득 할 수있었습니다. Firefox의 경우 새로운 cache-control: immutable 헤더가 필요하며 Chrome의 경우 그렇지 않습니다.
나는 이전에 그런 것을 보았던 것을 기억하고 있으며 자원의 내용을 해시하고 데이터베이스에서 10 년 이상 서비스하는 것보다이 문제에 대한 해결책이 더 많습니다. 그것은 파일 이름의 새로운 버전 번호입니다. 훨씬 더 편리한 솔루션은 버전 쿼리 문자열을 추가하는 것이지만, turns out that that doesn't always work입니다. 이러한 파일을 참조하는 파일도 변경해야하기 때문에
인정 하듯이, 당신의 파일 이름을 변경하면 모든 시간은 귀찮은이다. 그러나 파일을 실제로 변경할 필요는 없습니다. 서버를 제어하는 경우 logo.vXXXX.png이 logo.png으로 리디렉션되도록 리디렉션 규칙을 작성하는 것처럼 간단 할 수 있습니다 (여기서 XXXX는 신기원 이후 초 단위로 최종 수정 된 시간 소인). [1]. 이제 템플리트 시스템이 wordpress 'wp_enqueue_script처럼 타임 스탬프를 자동으로 생성하도록하십시오.WordPress는 실제로 쿼리 문자열 기술을 자체적으로 만족시킵니다. 이제 만료일을 먼 미래로 설정하고 변경 불가능한 캐시 헤더를 사용할 수 있습니다. 브라우저가 캐시 제어를 존중하면 이제 완전히 중복되므로 etags 및 if-modified-since 헤더를 안전하게 무시할 수 있습니다.
이 솔루션을 사용하면 브라우저에서 캐시 유효성 검사를 요청하지 않으며 사전에 만료 날짜를 결정하지 않아도 부실 리소스가 표시되지 않습니다.
깨끗한 캐시의 동일한 페이지에서 리소스를 가져 오는 여러 요청을 피할 방법을 피하는 방법에 대한 원래의 질문에 대한 답변은 없지만 이후에는 브라우저 캐시가 지워지지 않는 한), 당신은 좋다! 나는 그것이 나를 위해 충분하다고 생각한다.
[1] 응용 프로그램의 버전 번호를 사용하여 페이지가 리소스를 참조 할 때마다 모든 리소스의 타임 스탬프를 확인하는 서버 오버 헤드를 피할 수 있습니다. 개발을위한 디버그 모드에서는 타임 스탬프를 사용하여 파일을 수정할 때마다 버전을 버릴 필요가 없습니다.
출처
2017-12-09 00:58:54
nus
HTTP 프로토콜을 변경하고 브라우저를 다시 디자인해야이 새로운 모델을 사용할 수 있습니다. – Barmar
브라우저는 많은 구성 요소를 캐시하므로 매번 다운로드 할 필요가 없습니다. – Barmar
@Barmar 알아,하지만 그들은 웹 애플 리케이션의 전체 버전도 캐시 할 수 있습니다. 데이터가 ajax를 통해 가져 오는 경우 새 버전의 릴리스 당 한 번만 앱이 변경됩니다. – nus