‹LINK rel=SUBRESOURCE href=file› не кэшируется, несмотря на правильные заголовки кэша. Появляется, чтобы загрузить дважды с ответом 200OK

Я использую Glyphicons на своем веб-сайте, они служат частью Bootstrap 3. При просмотре вкладки «Сеть» консоли разработчика я понял, что они загружаются поздно (когда парсер браузера добрался до этого), и было место для повышения производительности путем перенос этого элемента в браузер раньше.

В Chrome это можно сделать через:

<link rel="subresource" href="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.1.1/fonts/glyphicons-halflings-regular.woff">

В <HEAD> документа.

Я вижу, что время DOMContentLoaded увеличивается таким образом, что предполагает, что этот файл загружается дважды (сначала в строке 5 на снимке экрана, а затем во второй и последней строке). Мое подозрение также подтверждается тем, что он загружается дважды с помощью кода ответа HTTP (200), который говорит мне, что оба раза он пришел с удаленного сервера и не был получен из кэша.

Посмотреть, как выглядит консоль разработчика, можно здесь: http://oi60.tinypic.com/2t9n7.jpg (На случай, если tinypic выйдет из строя, вот он в моем почтовом ящике: https://www.dropbox.com/s/vlwgywatg9rsg8v/subresourcenotcached.png)

Заголовки кэша в HTTP-версии этого актива есть, но стоит отметить, что вывод вкладки сети на консоли разработчика выглядит одинаково как для HTTP, так и для HTTPS.

HTTP/1.1·200·OK(CR)(LF)
Server:·cloudflare-nginx(CR)(LF)
Date:·Mon,·02·Jun·2014·17:49:06·GMT(CR)(LF)
Content-Type:·application/octet-stream(CR)(LF)
Content-Length:·23320(CR)(LF)
Connection:·close(CR)(LF)
Last-Modified:·Thu,·13·Feb·2014·22:45:07·GMT(CR)(LF)
Expires:·Sat,·23·May·2015·17:49:06·GMT(CR)(LF)
Cache-Control:·public,·max-age=30672000(CR)(LF)
Access-Control-Allow-Origin:·*(CR)(LF)
CF-Cache-Status:·HIT(CR)(LF)
Accept-Ranges:·bytes(CR)(LF)
CF-RAY:·13457c53f04d0378-LAX(CR)(LF)
(CR)(LF)

Кто-нибудь знает, как я могу получить этот файл .woff для кэширования и правильно использовать возможность LINK SUBRESOURCE в Chrome?


http google-chrome caching spdy
person Rajan Patel    schedule 02.06.2014    source источник
comment
Если вы посмотрите на столбец инициатора, кажется, что первый экземпляр исходит от синтаксического анализатора (это будет ваш <link rel="subresource"...>), а второй экземпляр исходит из скрипта. Я думаю, что сам Bootstrap делает этот запрос, хотя я не могу точно сказать, где именно.   -  person pieman72    schedule 03.06.2014
comment
Это правильно. Сначала я вызываю файл через LINK SUBRESOURCE в надежде, что он будет кэширован. bootstrap.min.css ссылается на этот файл, и когда DOM рисуется в браузере и встречаются SPAN, которые должны отображать содержимое из этого файла .woff, нормальный процесс заключается в запросе файла .woff в это время. Он должен извлекаться с HTTP-статусом 304 (файл не изменен) вместо выполнения нового HTTP-запроса (и повторной загрузки) с сообщением об успешном завершении 200 OK...   -  person Rajan Patel    schedule 03.06.2014

Ответы (1)


arrow_upward
1
arrow_downward

Это ошибка в текущем Chrome. Взгляните на https://code.google.com/p/chromium/issues/detail?id=312327

person wintermeyer    schedule 29.09.2014