Просьба, чтобы браузеры кэшировались максимально настойчиво
Это о веб-приложении, которое вручает изображения. Так как тот же запрос будет всегда возвращать то же изображение, я хочу, чтобы браузеры доступа кэшировали изображения максимально настойчиво. Я в значительной степени хочу сказать браузер
Вот Ваше изображение. Разрешение и сохраняет его; это действительно не собирается изменяться в течение следующих нескольких дней. Никакая потребность возвратиться.В самом деле. Я обещаю.
Я действительно, до сих пор, устанавливаю
Cache-Control: public, max-age=86400 Last-Modified: (some time ago) Expires: (two days from now)
и, конечно, возвратите a 304 not modified если запрос имеет соответствующее If-Modified-Since заголовок.
Есть ли что-либо еще, что я могу сделать (или что-нибудь, что я должен сделать по-другому) доносить смысл моего сообщения к браузерам?
Приложение размещается на Google App Engine, в случае, если это имеет значение.
7 ответов
Возможно, вас заинтересует следующая статья Google Code:
Короче говоря, все современные браузеры должен иметь возможность кэшировать ваши изображения соответствующим образом в соответствии с инструкциями с этими заголовками HTTP.
Вы можете сделать лучше . 304 по-прежнему являются HTTP-запросом / ответом. Хотя изображение не загружается снова, задержка может убивать.
Если вы можете включить идентификатор версии в имена ваших изображений, вы можете установить максимальный возраст на 2 года. Таким образом, вы предотвратите 304 с. Если изображение когда-либо изменится, вы обновите идентификатор версии, тем самым изменив имя файла. Это гарантирует, что браузер выдаст новый запрос.
Требуются некоторые изменения в структуре вашего проекта. Идентификатором версии может быть номер версии SVN на момент последнего обновления образа, и он может быть автоматически сгенерирован во время сборки. Вам также необходимо обновить html, поэтому, если у вас есть логическое сопоставление между именем изображения и путем к нему, ваша работа будет проще.
Изображения редко обновляются, поэтому вы также можете использовать ручной подход, если не можете автоматизировать то, что я описал выше. Хитрость заключается в том, чтобы добавлять только новые изображения, а не изменять их.
Попробуйте .htaccess, например
<ifmodule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifmodule>
<ifmodule mod_deflate.c>
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-javascript
</ifmodule>
<ifmodule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
</ifmodule>
<ifmodule mod_headers.c>
<filesMatch "\\.(ico|pdf|flv|jpg|jpeg|png|gif|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesmatch>
<filesMatch "\\.(css)$">
Header set Cache-Control "max-age=604800, public"
</filesmatch>
<filesMatch "\\.(js)$">
Header set Cache-Control "max-age=216000, private"
</filesmatch>
<filesMatch "\\.(xml|txt)$">
Header set Cache-Control "max-age=216000, public, must-revalidate"
</filesmatch>
<filesMatch "\\.(html|htm|php)$">
Header set Cache-Control "max-age=1, private, must-revalidate"
</filesmatch>
</ifmodule>
Я не знаю, поможет ли это помимо решений, предлагаемых другими, но вы можете использовать автономные веб-приложения HTML5 возможность более явно попросить браузер сохранить локальную копию.
В заголовке кеша есть очень важное значение, которое вы здесь не упомянули:
«post-check = 900, pre-check = 3600»
Прочтите эту статью по этой теме (и выполните поиск дополнительных сведений) :
Вы могли бы добавьте представление ETag для каждого изображения, а затем сравните его с заголовком If-None-Match во входящих запросах (см. « Почему не доставлено мое пользовательское изображение кеширование в браузере? "). Это избыточно при использовании предпочтительного заголовка Last-Modified , и это просто еще один способ сказать 304 в любом случае. (Я думаю, что GAE делает это автоматически для статических файлов, хотя не уверен.)
Gravatar устанавливает очень старые Last-Modified даты - по умолчанию, похоже, «среда, 11 января 1984 года, 08:00: 00 GMT ». По истечении 5 минут браузеры будут часто проверять наличие обновленных изображений. Другими словами, я думаю, они приглашают 304-х, а не пытаются убедить браузеры просто использовать локальный кеш. Их заголовки выглядят следующим образом:
Date: Sat, 20 Mar 2010 07:52:43 GMT
Last-Modified: Wed, 11 Jan 1984 08:00:00 GMT
Expires: Sat, 20 Mar 2010 07:57:43 GMT
Cache-Control: max-age=300
Большая разница в сроке действия - вам нужно два дня, а им - пять минут. Поэтому, если вы хотите, чтобы браузеры использовали кэшированное изображение в течение 48 часов, делайте то, что вы делаете, установите только Cache-Control: max-age = 172800 (86400 - 24 часа).
Срок хранения кэша в несколько дней очень низкий. Вы должны установить его на один год или даже больше. Конечно, это может вызвать проблемы при фактическом изменении изображения, но вы можете решить это, добавив номер версии к изображению и изменив страницу, которая ссылается на изображение, чтобы включить путь к новому изображению.
Подробнее о кешировании веб-приложений я писал здесь: http://patchlog.com/web/7-methods-to-cache-web-applications/