Ответ из двух частей:
- Вы не должны видеть 304
- Но разве это хорошая идея?
Вы не должны видеть 304
Я понимаю, что когда я посещаю многие сайты, используя, например, jQuery из CDN Google, ему придется «загружать» сценарий только один раз в течение очень долгого времени, но мой браузер все еще пытается подключиться к серверу Google, и запросите файл сценария, а затем получите код состояния неизмененного кода 304.
Не должно, нет, если он уважает заголовок Cache-Control:
Cache-Control:public, max-age=31536000
... что говорит о дате на ресурсе, браузер может кэшировать его до года. Нет необходимости в каком-либо HTTP-запросе на всех (и это то, что я вижу в Chrome, если я не форсирую его, нет запросов на всех , просто заметка с надписью «из кэша»; запустил Firefox и удостоверился, что Firebug был включен для всех страниц, впервые пришел в StackOverflow за длинный раз с Firefox [который я использую только для тестирования], и, конечно же, он не выдал никакого запроса на JQuery вообще).
Например, возможно, для ответа 304 потребуется 200 мс, но если ваш браузер правильно кэширует, для загрузки из кеша будет 0 мс.
Полный набор соответствующих заголовков, которые я вижу по принудительному запросу:
Cache-Control:public, max-age=31536000
Date:Wed, 17 Aug 2011 21:56:52 GMT
Expires:Thu, 16 Aug 2012 21:56:52 GMT
Last-Modified:Fri, 01 Apr 2011 21:23:55 GMT
... так что моему браузеру не нужно будет запрашивать этот путь снова почти год.
См. Комментарий @Dave Ward ниже: Чтобы получить максимальные результаты кеширования, используйте полный номер релиза, например ::
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js'></script>
<!-- very specific ---^^^^^ -->
вместо
<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js'></script>
<!-- very generic ----^ -->
Хорошо, но разве это хорошая идея?
Это полностью зависит от вас. Даже с таким отступлением:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js'></script>
<script>
if (typeof jQuery === "undefined") {
document.write("<scr" + "ipt src='/my/local/jquery.js'></scr" + "ipt>");
}
</script>
... или аналогичный, UX, если CDN не работает, будет ужасный . Браузер будет вращаться целую вечность, пытаясь подключиться к нему. Откат такого рода поможет, только если CDN быстро ответит сбоем, что маловероятно.
Это означает, что если CDN Google выйдет из строя, вам придется быстро настроить то, что вы обслуживаете, чтобы использовать вместо этого локальную копию. Поэтому защита от этого становится упражнением по мониторингу (серверов Google; не переусердствуйте, иначе они будут недовольны) отказом на уровне сервера, чтобы начать обслуживание страниц с локальным путем. (Или путь Microsoft по теории, что Google и Microsoft, вероятно, не делятся базовой технологией CDN, учитывая, насколько хорошо они ладят.)
Для меня ответ на большинстве сайтов, вероятно, таков: продолжайте и используйте CDN, реагируйте, если и когда CDN Google для библиотек выйдет из строя. Обратная сторона: если вы довольны своей общей загрузкой страницы, загружая ее с вашего сервера, не причиняйте вреда до тех пор, пока трафик не будет достаточно высоким, и вы стремитесь извлечь максимальную выгоду из своей работы. Но многие (и много-много) сайтов полагаются на CDN Google, и если он выйдет из строя, ваш сайт будет далеко не одинок в своих ошибках ...