Re: The Page speed test says the cache duration for my images is 5 minutes (for the desktop version)

219 views
Skip to first unread message
Message has been deleted

Jeff Kaufman

unread,
Aug 24, 2015, 4:12:28 PM8/24/15
to mod-pagespeed-discuss
I see:

Leverage browser caching for the following cacheable resources:
Getting 5 minute cache TTLs for .pagespeed. resources generally indicates some kind of misconfiguration.  Do you have multiple servers for parchance.fr with different pagespeed settings?  Or do you have another layer of caching set up on PageSpeed's output?

On Mon, Aug 24, 2015 at 3:50 PM, 1234 <nouveau.co...@gmail.com> wrote:
Hello, 

I test the speed of my website with the page speed Insight : goo.gl/DmjuaQ  

But in the desktop result, the cache duration for my images is 5 minutes, even if I put in the .htacess this : 

ExpiresActive On
ExpiresDefault "access plus 7 days"

For the other page, I have no problem : goo.gl/zPDxJF

Have you an idea for my problem ?

Thank you in advance, and sorry for my english.

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/8dc81fa2-d9e1-4813-be30-6567de7a3ba6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Message has been deleted

Jeff Kaufman

unread,
Aug 25, 2015, 9:47:33 AM8/25/15
to mod-pagespeed-discuss
There's something weird with the entries in your HTTP cache for these
images. For example, if I fetch:

1. http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/automobile.png.pagespeed.ce.0.png

This shows us what's in your http cache for automobile.png. It should
be identical to what I get if I fetch:

2. http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/automobile.png?PageSpeed=off

But instead it's identical to what I get if I fetch:

3. http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/automobile.png

The third url gives us a version of automobile.png optimized by
PageSpeed (via IPRO), and looking at it I can verify that it's
optimized: the redundant alpha channel in the original image has been
removed.

So #2 and #3 are working properly, but #1 is giving us the optimized
image (#3) instead of the original image (#1).

Additionally when I try to use wget on your site I get "403
Forbidden". It sounds like you have something running to keep out
unknown UAs? Could you paste the config for that? And anything else
custom on your site's server config? It could be confusing PageSpeed,
where PageSpeed is trying to fetch the original image but instead ends
up fetching the optimized image?

Do you have anything in your server's error log for these images?

----------------------------------------------------------------------
My notes are below, probably only interesting to me.
----------------------------------------------------------------------


I picked one of the images, a background image on a div specified in a
style attribute:
"http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/automobile.png".

PageSpeed is turning this into
"/images/documents-activite/carte-visite/background/thumb/automobile.png.pagespeed.ce.gJ-G6u8poh.png".

* It's now site-relative instead of absolute because you have
trim_urls turned on.
* I don't know why it's cache extended instead of rewritten as an image.

When I fetch the pagespeed version in curl I see:

Cache-Control: max-age=300,private

Same when I fetch it with Chrome:

Cache-Control: max-age=300,private

When I fetch the page with ?PageSpeedFilters=+debug I see:

<div id="..." onclick=...' class="..." alt="..." title="..."
style="background:url(/images/documents-activite/carte-visite/background/thumb/automobile.png.pagespeed.ce.Qlc8LkJsS7.png)
no-repeat center center"></div>
<!--Flattening failed: Cannot rewrite
http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/automobile.png
for an unknown reason-->

While it says "flattening failed", it's also now giving a different
url, and the new url has "Cache-Control: max-age=31536000".

In general, passing in PageSpeedFilters=+debug really shouldn't change
what resource I get in response.

If I fetch the page with
?PageSpeedFilters=rewrite_images,rewrite_css,rewrite_style_attributes
then I see the url rewritten as:

http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/xautomobile.png.pagespeed.ic.m3EFfZtpXa.png

Which is fully rewritten and gets the proper "Cache-Control:
max-age=31536000" header.

When I put a copy of your page on a test server and fetch it with
?PageSpeedFilters=-rewrite_images I get
automobile.png.pagespeed.ce.gJ-G6u8poh.png (the same as your site)
served with "Cache-Control: max-age=31536000" (not the same as your
site).

We can compare five images:

1. The image served without PageSpeed (automobile.png)
2. The image served with PageSpeed on your site (ce.gJ-G6u8poh)
3. The image served with PageSpeed on your site in debug mode (ce.Qlc8LkJsS7)
4. The image served with PageSpeed on my test server (ce.gJ-G6u8poh)
5. The image served with PageSpeed IPRO on your site (automobile.png)

I'm seeing that 1 and 4 are the same, which we'd expect. 2 and 3
should also be the same as 1 and 4, but instead are identical to each
other. 5 should be smaller than the rest, being optimized, but
instead is identical to 2 and 3. 2/3/5 are smaller (6602 bytes) than
1/4 (7176 bytes). The main difference is that 1/4 has an unnecessary
alpha channel (100% opaque everywhere) while 2/3/5 does not.

On Tue, Aug 25, 2015 at 5:50 AM, 1234 <nouveau.co...@gmail.com> wrote:
> Hello Jeff Kauffman, I'm happy to see you because you have already help me
> for my old pagespeed problems.
>
> Yes, you see right in the deskop result.
>
> So here the content of my .htaccess file (this is the only .htaccess file in
> the website and is in the document root) :
>
> Options +FollowSymLinks
> RewriteEngine On
>
>
> ExpiresActive On
> ExpiresDefault "access plus 7 days"
>
>
> ModPagespeed on
>
>
> ModPagespeedEnableFilters
> trim_urls,remove_comments,collapse_whitespace,recompress_images,sprite_images,rewrite_css,outline_css,combine_css,rewrite_javascript,outline_javascript,combine_javascript
> ModPagespeedDisableFilters defer_javascript
> SetOutputFilter DEFLATE
> AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml
> application/x-javascript text/javascript image/gif image/png image/jpeg
>
>
>
> I have no probleme for this page goo.gl/wYEZvx or for the home page.
>
> So I don't know the source of the problem.
> https://groups.google.com/d/msgid/mod-pagespeed-discuss/421d64c3-95bb-4877-b02d-f975de1ba49f%40googlegroups.com.
Message has been deleted

Jeff Kaufman

unread,
Aug 25, 2015, 1:44:17 PM8/25/15
to mod-pagespeed-discuss
On Tue, Aug 25, 2015 at 1:40 PM, 1234 <nouveau.co...@gmail.com> wrote:
 max-age=31536000 (365 days) is larger than the .htacess ExpiresDefault directive, i don't know why.


PageSpeed renamed that resource to include a hash of its content in the filename, which means when the content changes the filename PageSpeed uses for it will change.  PageSpeed overrides your ExpiresDefault directive for these resources because the hashing means they're safe to give a long cache lifetime to.  This is called longcaching.

This isn't the problem here though.  Instead the question is how PageSpeed is coming to think that a PageSpeed optimized resource is the unoptimized input resource.
Message has been deleted

Jeff Kaufman

unread,
Aug 25, 2015, 2:33:17 PM8/25/15
to mod-pagespeed-discuss
Could you send me the rest of your apache config?  I'm worried there might be other things there affecting the way fetching works.

(Blocking wget isn't being a problem for me; I was using curl.  But I thought it might be indicative of something that would affect our fetching.)

On Tue, Aug 25, 2015 at 1:59 PM, 1234 <nouveau.co...@gmail.com> wrote:
max-age=31536000 (365 days) is larger than the .htacess ExpiresDefault directive, i don't know why.
=> You're right, it's not a problem. 

I think the problem may come from the images themself, because the image http://www.parchance.fr/images/documents-activite/modele-carte-visite.png.pagespeed.ce.6vK5QlkBsk.png optimized by pagespeed in the same page doesn't have problem, the cache duration is 365 instead of 5 minutes : 

Accept-Rangesbytes
Cache-Controlmax-age=31536000
ConnectionKeep-Alive
Content-Encodinggzip
Content-Length4504
Content-Typeimage/png
DateTue, 25 Aug 2015 17:55:38 GMT
EtagW/"0"
ExpiresWed, 24 Aug 2016 17:55:38 GMT
Keep-Alivetimeout=5, max=100
Last-ModifiedTue, 25 Aug 2015 17:55:38 GMT
ServerApache/2.2.22 (Debian)
VaryAccept-Encoding

So I comment the wget directive in my .htacces so you can download the image http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/automobile.png to see the problem. Do you think this image have a problem to make working long caching ?

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
Message has been deleted
Message has been deleted
Message has been deleted

Jeff Kaufman

unread,
Aug 26, 2015, 8:58:05 AM8/26/15
to mod-pagespeed-discuss

On Wed, Aug 26, 2015 at 5:45 AM, 1234 <nouveau.co...@gmail.com> wrote:
Hello, 

just a notice : 


In the firefox console, this image has "private" in the cache response :

Cache-Control  max-age=300,private


=> "private" in the value, "what does it means" ?
Because, private doesn't appear for the others images.


Do you see any with 5min TTLs that aren't marked "private"?  The  "max-age=300,private" is because PageSpeed detected that the hash didn't match and doesn't want to poison intermediate caches.  In this case I've manually substituted "0" for the correct hash, so it's not surprising that it doesn't match.

Looking over your configuration I don't see anything that would lead to getting the wrong things into the HTTP cache.  So it sounds like it might be a bug in how we make ipro resource recordings in some cases.  I'll look into it in our code.

Jeff Kaufman

unread,
Aug 26, 2015, 9:14:22 AM8/26/15
to mod-pagespeed-discuss
Without having dug into the code yet, my hypothesis is that there's
some case where the IPRO resource recorder sees a pagespeed-optimized
resource and puts a copy of that in the cache.

To check this, would you be able to turn off IPRO, clear your cache,
and see if this recurs?

ModPagespeedInPlaceResourceOptimization off

1234

unread,
Aug 26, 2015, 9:50:10 AM8/26/15
to mod-pagespeed-discuss

To check this, would you be able to turn off IPRO, clear your cache, 
and see if this recurs? 
    ModPagespeedInPlaceResourceOptimization off 

Yes, I add the ModPagespeedInPlaceResourceOptimization off directive, clear my firefox cache, and when I reload the page, the url of this image http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/automobile.png.pagespeed.ce.gJ-G6u8poh.png
has a new token (pagespeed.ce.gJ-G6u8poh.png) and firefox console displays that :


Accept-Ranges bytes
Cache-Control max-age=31536000
Connection Keep-Alive
Content-Encoding gzip
Content-Length 6986
Content-Type image/png
Date Wed, 26 Aug 2015 13:51:39 GMT
Etag W/"0"
Expires Thu, 25 Aug 2016 13:51:39 GMT
Keep-Alive timeout=5, max=100
Last-Modified Wed, 26 Aug 2015 13:51:39 GMT
Server Apache/2.2.22 (Debian)
Vary Accept-Encoding



=> Cache-Control max-age=31536000 (365 days) instead of 5 minutes, but doesn't match 7 days.
What is IPRO and what does it means ?

Jeff Kaufman

unread,
Aug 26, 2015, 9:54:11 AM8/26/15
to mod-pagespeed-discuss
On Wed, Aug 26, 2015 at 9:50 AM, 1234 <nouveau.co...@gmail.com> wrote:
>
>> To check this, would you be able to turn off IPRO, clear your cache,
>> and see if this recurs?
>> ModPagespeedInPlaceResourceOptimization off
>
>
> Yes, I add the ModPagespeedInPlaceResourceOptimization off directive, clear
> my firefox cache, and when I reload the page, the url of this image
> http://www.parchance.fr/images/documents-activite/carte-visite/background/thumb/automobile.png.pagespeed.ce.gJ-G6u8poh.png
> has a new token (pagespeed.ce.gJ-G6u8poh.png) and firefox console displays
> that :
>
>
...
> Cache-Control max-age=31536000
> ...
>

Great!

I'm still working on figuring out how this would work with our IPRO code.

> => Cache-Control max-age=31536000 (365 days) instead of 5 minutes, but
> doesn't match 7 days.

Yes, that's expected. As I wrote upthread, the filename now has a
hash of the image's contents (gJ-G6u8poh) which means that it's safe
to be cached indefinitely, because if the image changes then PageSpeed
will generate different html with a different filename with the new
hash.

> What is IPRO and what does it means ?
>

IPRO is short for "InPlaceResourceOptimization" which you turned off
above. It allows optimizing images/css/js without changing their
urls. In general it's less efficient but also less likely to interact
badly with javascript.

Jeff

1234

unread,
Aug 26, 2015, 10:02:39 AM8/26/15
to mod-pagespeed-discuss
Thank you very much.

In others words, if I understand, IPRO optimize resources without rewrite their urls ?

And do you advice me to keep the ModPagespeedInPlaceResourceOptimization off  directive in my .htaccess ? I work a lot with javascript because some web pages has huge javascript code which interact with images.

Jeff Kaufman

unread,
Aug 26, 2015, 10:29:38 AM8/26/15
to mod-pagespeed-discuss
Two more questions:

a) Is your .htaccess in /carte-visite/ or somewhere else?

b) Could you send your pagespeed.conf as well?

I'm setting up a test server now to replicate this.

> In others words, if I understand, IPRO optimize resources without rewrite
> their urls ?
>

Yes.

> And do you advice me to keep the ModPagespeedInPlaceResourceOptimization off
> directive in my .htaccess ? I work a lot with javascript because some web
> pages has huge javascript code which interact with images.
>

It does sound like IPRO is a good fit for your site if we can get it
working right. Let me debug this some on my side and get back to you
it a bit.
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
0 new messages