extend_cache not working - to long TTL given on Css

[al...@bobbie.de]

Hi,

I'm running pagespeed on www.bobbie.de. Static assets come from static.bobbie.de, in order to save cookies etc, but it's the same box behind.

Now it happens every now and then, that a user hits www.bobbie.de, and pagespeeds servers our html referencing "styles.css" unmodified. I.e. not optimised but also not with the content hash in the URL. That will then result in the user browser using a cached, but old and outdated version of the file. I do understand why it can be that the optimised version of styles.css is not yet available (albeit I need to debug that - will be seperate thread), but why doesn't the extend_cache filter change the URL? Can't be a timing issue, reading the file takes virtually no time, and the webserver needs to read it anyway...? I'd like to enforce the usage of hash modified URLs somehow?

regards

Alex

[Longinos]

Hi

I see this from you web

https://static.bobbie.de/skin/frontend/bobbie/default/css/A.styles.css.pagespeed.cf.QPyllp2mKY.css

1. cache-control:
   max-age=31536000
2. content-encoding:
   gzip
3. content-length:
   89993
4. content-type:
   text/css
5. date:
   Fri, 11 Jan 2019 10:10:09 GMT
6. etag:
   W/"0"
7. expires:
   Sat, 11 Jan 2020 10:10:09 GMT
8. last-modified:
   Fri, 11 Jan 2019 10:10:09 GMT
9. pragma:
   public
10. server:
    nginx
11. status:
    200
12. vary:
    Accept-Encoding
13. x-original-content-length:
    623195
14. x-page-speed:
    1.12.34.3-0

[Alexander Gran]

Hi,

 

sure, this is a request where all works ok (URL has been changed, file has been optimised).

However sometimes this is referenced as https://static.bobbie.de/skin/frontend/bobbie/default/css/styles.css, i.e. without the content hash.

As this seems to be a cache invalidation issue (one of the three hard things…[1]), I can’t reproduce that reliably.

 

[1] https://martinfowler.com/bliki/TwoHardThings.html

 

 

Regards
Alex

 

Von: mod-pagesp...@googlegroups.com <mod-pagesp...@googlegroups.com> Im Auftrag von Longinos
Gesendet: Freitag, 11. Januar 2019 11:13
An: mod-pagespeed-discuss <mod-pagesp...@googlegroups.com>
Betreff: Re: extend_cache not working - to long TTL given on Css

 

Hi

 

I see this from you web

 

https://static.bobbie.de/skin/frontend/bobbie/default/css/A.styles.css.pagespeed.cf.QPyllp2mKY.css

1.  cache-control:

max-age=31536000

2.  content-encoding:

gzip

3.  content-length:

89993

4.  content-type:

text/css

5.  date:

Fri, 11 Jan 2019 10:10:09 GMT

6.  etag:

W/"0"

7.  expires:

Sat, 11 Jan 2020 10:10:09 GMT

8.  last-modified:

Fri, 11 Jan 2019 10:10:09 GMT

9.  pragma:

public

10.   server:

nginx

11.   status:

200

12.   vary:

Accept-Encoding

13.   x-original-content-length:

623195

14.   x-page-speed:

1.12.34.3-0

El jueves, 10 de enero de 2019, 15:43:26 (UTC+1), al...@bobbie.de escribió:

Hi,

 

I'm running pagespeed on www.bobbie.de. Static assets come from static.bobbie.de, in order to save cookies etc, but it's the same box behind.

Now it happens every now and then, that a user hits www.bobbie.de, and pagespeeds servers our html referencing "styles.css" unmodified. I.e. not optimised but also not with the content hash in the URL. That will then result in the user browser using a cached, but old and outdated version of the file. I do understand why it can be that the optimised version of styles.css is not yet available (albeit I need to debug that - will be seperate thread), but why doesn't the extend_cache filter change the URL? Can't be a timing issue, reading the file takes virtually no time, and the webserver needs to read it anyway...? I'd like to enforce the usage of hash modified URLs somehow?

 

regards

Alex

--
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/5b359e20-eaa7-4787-9c5c-c256fbe53208%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Longinos]

Hi

I see it....

These css file had images in it? Yes, they had..... I think is a bug.

When css had images in it, some times the images are webp converted and some times the images a jpg optimized, so you had 2 optimized url for the same file, 1 for webp and 1 fpr non webp request cappable.

My workaround about it is:

1.- fecht the page with firefox, some hit until all the images in the css are rewrited.

2.- copy the optimized content of the css file and paste it as the original file . I will say with the optimized urls.

3.- put a disallow directive in pagespeed config that disables rewriting .pagespeed.has urls (pagespeed Disallow *.pagespeed.*;)

4.- restart nginx

Then the css url be the same in chrome and in firefox and don´t flip-flap between optimized and uptimized.

Hope this help

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-discuss+unsub...@googlegroups.com.