question regarding (from memory cache) vs (from disk cache)

[Matt]

Hello group

Does anyone know why chrome (canary, but similar for other channels) always disk caches webp, but always memory caches png/jpg in my scenario.

After converting my png and jpg files to webp, I created a map and associated location block in nginx as follows

http context

map $http_accept $webp {
     default "";
     "~*webp" ".webp";
}

server context

location ~* "^/wp-content/uploads/.+\.(png|jpe?g)$" {
    expires max;
    add_header Vary Accept;           #if this line is commented - chrome RAM caches images
    log_not_found off;
    access_log off;
    try_files $uri$webp $uri =404;    #if this line is commented - chrome RAM caches images
}

In an effort to see the benefits of webp, with jpg/png fallback, based on the accepts request header (not perfect but a start) I come up against a local performance hit.

So while effectively halving the image weight, Chrome always disk caches webp images, but memory caches other images. 

I would not care, if images bytes were always travelling, but as you see from the screenshots, implementing an aggressive local cache, introduces an average of 10-15% more latency (from 23ms to 26ms ish)

I realise this might not seem like a big issue :) 

Any thoughts gratefully received.

matt 

.

screenshots

jpg/png memory caching

webp disk caching

[dan...@chromium.org]

+image folks

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Matt]

thank you for your time.

It comes down to

Vary Accept;


I am not sure of the underlying cache logic, but I realise that serving multiple resources from the same URL leads to decisions being taken elsewhere by caches I am not responsible for. In this case the local cache.

After playing with this example, I can see that making an identical request, I receive an identical response payload with same etag etc.. the only difference is a few missing headers, see below. I assume the decisions chromium takes are completely correct, they just were not obvious to me.

Request identical both times.

:authority:wondershift.biz
:method:GET
:path:/chromium-dev/awesome/2000/very-old-format.jpg
:scheme:https
accept:image/webp,image/*,*/*;q=0.8
accept-encoding:gzip, deflate, sdch, br
accept-language:en-US,en;q=0.8
cache-control:no-cache
cookie:SESSION=value; wfvt_key=value
pragma:no-cache
referer:https://wondershift.biz/chromium-dev/
user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6 resisting sierra) Chrome/i2.KeWL Safari/12 N0t

Response (config set to send a vary accepts response header) - cache is on disk

accept-ranges:bytes
cache-control:max-age=315360000
content-length:25696
content-type:image/webp
date:Mon, 14 Nov 2016 20:16:28 GMT
etag:"5829f781-6460"
expires:Thu, 31 Dec 2037 23:55:55 GMT
last-modified:Mon, 14 Nov 2016 17:42:25 GMT
status:200
vary:Accept

Response (config set to NOT send a vary accepts response header) - cache is in memory
(missing response headers in bold)

accept-ranges:bytes
cache-control:max-age=315360000
content-length:25696
content-type:image/webp
date:Mon, 14 Nov 2016 20:13:52 GMT
etag:"5829f781-6460"
expires:Thu, 31 Dec 2037 23:55:55 GMT
last-modified:Mon, 14 Nov 2016 17:42:25 GMT
p3p:CP=WS has no P3P policy. This technology is outdated and not worth implementing
status:200
timing-allow-origin:*
x-content-type-options:nosniff
x-frame-options:deny
x-xss-protection:1; mode=block

Many thanks for your time.

[Charles Harrison]

Blink normally does not serve resources from memory cache if they have Vary headers. Some exceptions:

- preloads

- images (wonder why this isn't happening...)

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp?rcl=0&l=961

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Kouhei Ueno]

On Mon, Nov 14, 2016 at 1:09 PM, Charles Harrison <cshar...@chromium.org> wrote:

Blink normally does not serve resources from memory cache if they have Vary headers. Some exceptions:

- preloads

- images (wonder why this isn't happening...)

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp?rcl=0&l=961

Interesting. I did quick archaeology and this seems to come from r173127 to follow spec:

https://html.spec.whatwg.org/multipage/embedded-content.html#ignore-higher-layer-caching

I wonder why webp is an exception here?

--

kouhei