Ajax의 캐시는 브라우저에서 유지 관리됩니다. 서버로 전송 된 특정 URL의 경우 AJAX는 첫 번째 요청 중에 서버와 만 상호 작용합니다. 후속 요청에서 Ajax는 더 이상 서버에 요청을 제출하지 않지만 캐시에서 직접 데이터를 추출합니다.
경우에 따라 매번 서버에서 업데이트 된 데이터를 가져와야합니다. 아이디어는 정상 응용 프로그램에 영향을 미치지 않고 URL을 다르게 요청하는 것입니다. URL 후에 임의의 컨텐츠를 추가하십시오.
예를 들어
url = url+"&"+math.random ();
핵심 사항 :
1. 매번 요청한 URL이 다릅니다 (Ajax 캐시가 작동하지 않습니다)
2. 일반적인 응용 프로그램에 영향을 미치지 않습니다 (가장 기본)
여기에는 두 가지 결론이 있습니다.
1 : Ajax 캐시 및 HTTP 캐시는 동일합니다
최신 브라우저의 HTTP 및 캐싱 메커니즘은 Ajax의 XMLHTTPRequest 객체보다 훨씬 나쁩니다. 따라서 AJAX 요청에 대해 인식하거나 신경 쓰지 않습니다. 그것은 단순히 일반적인 HTTP 캐싱 규칙을 따르고 서버에서 반환 한 응답 헤더를 통해 캐시합니다.
이미 HTTP 캐시를 이해하고 있다면 HTTP 캐시의 지식을 사용하여 AJAX 캐시를 이해할 수 있습니다. 유일한 차이점은 응답 헤더를 설정하는 방법이 일반 파일과 다를 수 있다는 것입니다.
다음 응답 헤더는 Ajax 캐시 가능하게 만들 수 있습니다.
만료 :이 항목은 향후 적절한 시점으로 설정해야합니다. 시점의 설정은 컨텐츠 변경 빈도에 따라 다릅니다. 예를 들어, 요청 된 재고 수량이 있으면 만료 값은 10 초 후에가 될 수 있습니다. 요청 된 사진이라면 만료 값은 자주 변경되지 않기 때문에 더 길어질 수 있습니다. 만료 헤더를 사용하면 브라우저가 일정 시간 동안 로컬 캐시 된 데이터를 재사용 할 수 있으므로 서버 데이터와의 불필요한 상호 작용을 피할 수 있습니다.
최종 수정 :이 항목을 설정하는 것이 좋습니다. 이를 통해 브라우저는 요청 헤더에서 if-modified-since를 사용하여 조건부 GET 요청을 보낼 때 로컬 캐시 된 컨텐츠를 확인합니다. 데이터를 업데이트 할 필요가 없으면 서버는 304 응답 상태를 반환합니다.
캐시 제어 : 적절한 상황의 경우 모든 중간 프록시 및 캐시를 다른 사용자와 저장하고 공유 할 수 있도록이 값을 공개해야합니다. Firefox에서는 HTTPS 요청에 대한 캐시도 지원합니다.
물론 포스트 메소드를 사용하여 ajax를 보내면 사후 요청이 캐시되지 않기 때문에 캐시 할 수 없습니다. AJAX 요청에 다른 효과 (예 : 은행 계좌 간 전송)가있는 경우 사후 요청을 사용하십시오.
우리는 데모를 설정했습니다 (이 데모는 더 이상 볼 수 없음 (□) ノ)을 설정하여 이러한 헤더의 작동 방식을 명확히합니다. HTTPWatch에서는 응답 헤더 정보에 위의 3 개의 응답 헤더를 설정하는 것을 알 수 있습니다.
'ajax 업데이트'버튼을 정기적으로 클릭하면 시간이 다른 분이있는 경향이 있습니다. 만료 된 응답 헤더가 다음 순간으로 설정되어 있기 때문입니다. 아래 스크린 샷에서는 다음과 같이 볼 수 있습니다. 업데이트 버튼을 반복적으로 클릭하면 AJAX 요청이 네트워크 활동을 생성하지 않고 브라우저의 로컬 캐시를 읽습니다 (전송 및 전송 막대의 값은 0입니다).
캐시 된 데이터가 1 분을 초과했기 때문에 마지막 클릭으로 1 : 06.531 시간에 네트워크 데이터 전송이 생성 된 AJAX 요청. 서버는 새로운 데이터 사본이 얻어 졌음을 나타 내기 위해 200 개의 응답 상태를 반환했습니다.
이 데모는 버튼이어야한다고 생각합니다. 클릭 할 때마다 현재 시간을 가져 와서 현재 페이지로 돌아갑니다.
2 : IE 브라우저는 시간 만료가 만료되기 전에 Ajax를 통해 얻은 콘텐츠를 새로 고치지 않습니다.
때로는 Ajax가 페이지를로드 할 때 페이지의 특정 부분 (예 : 가격 목록)을 채우는 데 사용됩니다. 사용자의 이벤트 (예 : 버튼 클릭)에 의해 트리거되지 않지만 페이지가로드되면 JavaScript를 통해 전송됩니다. 마치 AJAX 요청이 포함 된 리소스 (예 : JS 및 CSS)와 동일합니다.
해당 페이지를 개발하는 경우 새로 고침 할 때 임베디드 AJAX 요청 컨텐츠를 업데이트 할 수 있습니다. 임베디드 리소스 (CSS 파일, 그림 등)의 경우 브라우저는 사용자가 새로 고침되는지 F5 (새로 고침) 또는 Ctrl+F5 (Force Refresh)인지 자동으로 다음 유형의 요청을 자동으로 보냅니다.
1.F5 (새로 고침) : 요청 컨텐츠에 마지막으로 수정 된 응답 헤더가 있으면 브라우저는 조건부 업데이트 요청을 보냅니다. 비교를 위해 if-modified-since 요청 헤더를 사용하여 서버가 불필요한 데이터의 전송을 피하기 위해 304 상태를 반환 할 수 있도록합니다.
2.Ctrl+F5 (Force Compert) : 브라우저에 무조건 업데이트 요청을 보내도록 지시하고 요청 헤더의 캐시 제어가 'No-Cache'로 설정됩니다. 이것은 모든 중간 프록시 및 캐시를 알려줍니다. 브라우저는 캐시되었는지 여부에 관계없이 최신 버전을 가져와야합니다.
Firefox는이 새로 고침 메소드를 페이지에로드 할 때 전송 된 AJAX 요청으로 전파 하고이 AJAX 요청을 임베디드 리소스로 취급합니다. 아래는 Firefox에서 HTTPWatch의 스크린 샷으로, 새로 고침 될 때 AJAX 요청의 효과를 보여줍니다 (F5) 페이지 :
Firefox는 Ajax가 시작한 요청이 조건부인지 확인합니다. 이 예에서는 데이터가 10 초 미만으로 캐시되면 서버는 304를 반환하고 10 초를 초과하면 서버가 200을 반환하고 데이터를 다시 작성합니다.
즉, 페이지가로드 될 때 시작된 AJAX 요청은 페이지의 다른 부분을 새로 고치는 것과 아무 관련이없는 것으로 간주되며 사용자의 새로 고침 방법의 영향을받지 않습니다. 캐시 된 Ajax 데이터가 만료되지 않은 경우 서버로 전송 된 요청이 없습니다. 캐시에서 직접 데이터를 읽고 httpwatch에서 (캐시) 결과입니다. 다음 그림은 캐시가 IE에서 만료되지 않은 경우 F5를 눌러 새로 고치는 것입니다.
Ctrl+F5를 통해 새로 고침 되더라도 Ajax를 통해 얻은 데이터는 캐시에서 읽습니다.
이는 AJAX를 통해 얻은 모든 것이 만료되지 않은 경우 IE에 따라 업데이트되지 않음을 의미합니다. CTRL+F5를 사용하여 새로 고침을 강요하더라도. 최신 데이터를 얻을 수있는 유일한 방법은 캐시를 수동으로 지우는 것입니다. HTTPWatch 도구 모음을 사용할 수 있습니다.
캐시 결과와 304 결과는 다릅니다. 캐시는 실제로 200 (캐시), 304는 304입니다. 캐시는 실제로 서버에 요청을 보내지 않습니다. Chrome에서 시간이 0이고 응답도 비어 있음을 알 수 있습니다. 그러나 304는 다릅니다.
304 요청은 브라우저가 시작한 조건부 요청입니다. 이 요청에는 if-modified-since 요청 헤더가 제공됩니다. 브라우저가 시간을 보낸 후 파일이 수정되지 않은 경우 서버 측은 304 상태를 반환하고 브라우저에 로컬 캐시 컨텐츠를 사용하도록 지시합니다. 요청이 서버 측로 전송되는 것만 큼 빠르지 않지만 서버 측은 데이터를 보내지 않습니다.
200 (캐시)과 304가 모두있는 Taobao의 홈페이지를 확인할 수 있습니다. 차이점을 확인할 수 있습니다.
요약 :
우리는 Ajax가 페이지 로딩 속도를 높일 수있는 주된 이유는 Ajax를 통해 중복 데이터의로드를 줄이고 주문형 획득을 달성하기 때문입니다. 이 경우 AJAX 프로그램을 작성할 때 서쪽으로 보내고 클라이언트에 다시 캐시하여 데이터로드 속도를 더욱 향상시킬 수 있습니다. 이는 데이터를로드하면서 브라우저 메모리의 데이터를 캐시하는 것입니다. 데이터가로드되면 페이지가 새로 고침되지 않는 한 데이터가 메모리에 영원히 캐시됩니다. 사용자가 데이터를 다시 보면 서버에서 데이터를 얻을 필요가 없어 서버의로드를 크게 줄이고 사용자의 경험을 향상시킵니다.