Pagespeed not caching results for any significant time

75 views
Skip to first unread message

Alexander Gran

unread,
Jun 5, 2017, 6:48:21 PM6/5/17
to ngx-pagespeed-discuss
Hi,

I have pagespeed setup for my site and it is working just fine when I time my requests correctly.
Means for an inital request I always run into the exceed timeouts, which is ok.
When I wait just long enough, I get everything reqritten/compressed/minified etc as I'd like it.
When I now just wait a few minutes, all this seems lost and pagespeed starts all over again.

I'm a bit lost in debugging that, any ideas?

I use memcached+filecache, but the later is unused so far.
I do see quite some expirations in pagespeed_admin/graphs#cache_type, but I'd like to know why they are expiring.

regards
Alex

Joshua Marantz

unread,
Jun 5, 2017, 9:34:01 PM6/5/17
to ngx-pagesp...@googlegroups.com
Please see https://modpagespeed.com/doc/filter-cache-extend -- the server-side cache expiration is based on the origin TTL, or 5 minutes by default, if no TTL is specified at origin.



--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

Alexander Gran

unread,
Jun 6, 2017, 11:04:07 AM6/6/17
to ngx-pagespeed-discuss
Hi,

Yes, I've got that enabled. But I thought it works like this:
a.) first request pagespeed initially requests upstream ressource, hashes it and starts processing in background.
b.) 2 min later, second request, ressource has been processed and is delivered with TTL 1 year and the hash as a filename
c.) 1 hour later, third request. pagespeed requests ressource (that might have a TTL < 1hour in upstream), realises the hash is the same and sends out the processed ressource from cache

What I see is this:
This is expected.
But now:

So to me it looks like the hash stays the same, still pagespeed isrebuilding the .cf. version again. This should come from cache, no?

Site has very litte load (it is not public yet), so cache should have enough space.

So what I'm looking for is a way to debug that behaviour.

regards
Alex

Alexander Gran

unread,
Jun 6, 2017, 10:18:35 PM6/6/17
to ngx-pagespeed-discuss
Hi,

for further ideas, here are some headers:
Original css file, i.e. with Pagespeed=off:
content-encoding:gzip
content-type:text/css
date:Wed, 07 Jun 2017 02:14:34 GMT
etag:W/"PSA-aj-1C1y2ZmNCm"
expires:Sat, 02 Jun 2018 01:46:53 GMT
pragma:public
server:nginx
status:200
vary:Accept-Encoding
vary:Accept-Encoding
x-original-content-length:4074

file after Pagespeed:
age:281
cache-control:max-age=31536000, public
content-encoding:gzip
content-length:881
content-type:text/css
date:Wed, 07 Jun 2017 01:46:59 GMT
etag:W/"0"
expires:Thu, 07 Jun 2018 01:46:59 GMT
last-modified:Wed, 07 Jun 2017 01:46:59 GMT
pragma:public
server:nginx
status:200
vary:Accept-Encoding
x-amz-cf-id:_nkJ8X9kYLpnXmQSpAs3HvxdtGO-SIfgmch4ytU-_5LleHjuaT6uNA==
x-cache:Hit from cloudfront
x-original-content-length:4076
x-page-speed:1.11.33.4-0

Same without Cloudfront in between:
cache-control:max-age=31536000, public
content-encoding:gzip
content-type:text/css
date:Wed, 07 Jun 2017 01:46:59 GMT
etag:W/"0"
expires:Thu, 07 Jun 2018 01:46:59 GMT
last-modified:Wed, 07 Jun 2017 01:46:59 GMT
pragma:public
server:nginx
status:200
vary:Accept-Encoding
vary:Accept-Encoding
x-original-content-length:4076
x-page-speed:1.11.33.4-0

Joshua Marantz

unread,
Jun 6, 2017, 11:50:18 PM6/6/17
to ngx-pagesp...@googlegroups.com
I believe the cache has enough space.  But I'm confused about the origin cache TTL.  When I first read your message I thought the origin was expiring in PageSpeed's cache.  E.g. if your origin TTL is max-age=300 then after 5 minutes the pagespeed cache entries will be stale.  On an active site, the resource would be refreshed in pagespeed's cache after 4 minutes, but only if there is traffic.  So a common problem for a site that isn't live is that the server doesn't wake up to freshen the cache often enough, and the resources go stale.

But I don't understand how that explanation works with the data you've supplied.

Could you try refreshing with ?PageSpeedFilters=+debug and see what gets referenced in the HTML?  That should inject some comments into the HTML explaining why optimizations were not fully applied.

--

Alexander Gran

unread,
Jun 7, 2017, 6:16:40 AM6/7/17
to ngx-pagespeed-discuss
Hi,

yes, I hope it does (any straight forward way to find out)? We have memcached but also file cache, although I don't see any data in the later one.
On first request (where a .cc. is delivered) debug gives something like:
><!--deadline_exceeded--><!--deadline_exceeded for filter CssFilter--><!--deadline_exceeded--><!--deadline_exceeded for filter CacheExtender-->

Which is kind of expected. Subsequent requests than return the .cf. and have
<!--CSS not inlined since it&#39;s bigger than 2048 bytes--><!--Cannot rewrite https://www.hostname.com/js/calendar/menuarrow.gif for an unknown reason--><!--Image does not appear to need resizing.--><!--Image has transparent pixels, is sensitive to compression noise, and has no animation.--><!--The image was not inlined because it has too many bytes.-->

Which also looks okish to me.
However a few mins later, I'm back at the .cc.

So, it really looks like optimisations *are* fully applied, but get removed from cache virtually immediately.

regards
Alex

Joshua Marantz

unread,
Jun 7, 2017, 8:46:29 AM6/7/17
to ngx-pagesp...@googlegroups.com
The file-cache serves only as a backing store for objects (usually origin images) that are too large for memcached (>1MB).

I think the problem we're running into here is that when you minify CSS that has background images or CSS imports, it must be re-checked based on the earliest expiration of any of those nested assets.

We've had trouble in the past matching the symptoms you see.  One remedy is to try to make your origin TTLs a little longer.  It might be related (for example) to menuarrow.gif or other assets.

However your headers were confusing to me because you said the first one was taken with pagespeed=off, but I saw etag:W/"PSA-aj-1C1y2ZmNCm" which comes from PageSpeed, and a long TTL.  I'm also not sure how Cloudflare fits into the topology.



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

Alexander Gran

unread,
Jun 7, 2017, 9:15:00 AM6/7/17
to ngx-pagespeed-discuss
Thanks,

I'll take a look into all references and make sure their expiration headers are OK.
The headers are really just copy pasted, should be correct, however strange they are...
Do I need to worry about the cannot rewrite for unknown reason? Or better, how to get to the unknown reason?!

Problem also happens without cloudfare, they are just proxying.

Cheers
Alex

Joshua Marantz

unread,
Jun 7, 2017, 9:24:27 AM6/7/17
to ngx-pagesp...@googlegroups.com
Cloudlare is just proxying?  Not caching?

RE "unknown reason"...errr. don't know?  My gut is that this issue is not related to what you are trying to solve here. I think we could track down that string in our .cc file and tease out some more detailed causality, which might involve digging into a few layers of APIs.  However I think it's probably not worth it in this case.


Alex

Alexander Gran

unread,
Jun 7, 2017, 9:27:53 AM6/7/17
to ngx-pagesp...@googlegroups.com
Yes, also caching, sure. But just the static assets, and my problem is that already in the html (which comes directly from pagespeed) the issue is visible. Also I had the problem when disabling cloudfront(I. E. Not using sharding/rewrite) 

Isn't there a way to enable logging regarding cache hit/mis? 

Will check the referenced css/images later tonight. 

Regards 

Am 07.06.2017 3:24 nachm. schrieb "'Joshua Marantz' via ngx-pagespeed-discuss" <ngx-pagesp...@googlegroups.com>:
Cloudlare is just proxying?  Not caching?

RE "unknown reason"...errr. don't know?  My gut is that this issue is not related to what you are trying to solve here. I think we could track down that string in our .cc file and tease out some more detailed causality, which might involve digging into a few layers of APIs.  However I think it's probably not worth it in this case.

On Wed, Jun 7, 2017 at 9:15 AM, Alexander Gran <al...@zodiac.dnsalias.org> wrote:
Thanks,

I'll take a look into all references and make sure their expiration headers are OK.
The headers are really just copy pasted, should be correct, however strange they are...
Do I need to worry about the cannot rewrite for unknown reason? Or better, how to get to the unknown reason?!

Problem also happens without cloudfare, they are just proxying.

Cheers
Alex

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

Joshua Marantz

unread,
Jun 7, 2017, 9:34:16 AM6/7/17
to ngx-pagesp...@googlegroups.com
Right, so when I asked about Cloudflare, I as wondering whether, when PageSpeed fetched its input resources (e.g. css files and the images referenced from them) it as actually fetching them through Cloudflare, which might have cached them, and potentially rewritten their headers.  Or whether when PageSpeed fetches its input resources it does so directly from your origin, either due to MapOriginDomain or LoadFromFile, or the way you have your domains mapped.


On Wed, Jun 7, 2017 at 9:27 AM, 'Alexander Gran' via ngx-pagespeed-discuss <ngx-pagesp...@googlegroups.com> wrote:
Yes, also caching, sure. But just the static assets, and my problem is that already in the html (which comes directly from pagespeed) the issue is visible. Also I had the problem when disabling cloudfront(I. E. Not using sharding/rewrite) 

Isn't there a way to enable logging regarding cache hit/mis? 

Will check the referenced css/images later tonight. 

Regards 
Am 07.06.2017 3:24 nachm. schrieb "'Joshua Marantz' via ngx-pagespeed-discuss" <ngx-pagespeed-discuss@googlegroups.com>:
Cloudlare is just proxying?  Not caching?

RE "unknown reason"...errr. don't know?  My gut is that this issue is not related to what you are trying to solve here. I think we could track down that string in our .cc file and tease out some more detailed causality, which might involve digging into a few layers of APIs.  However I think it's probably not worth it in this case.


On Wed, Jun 7, 2017 at 9:15 AM, Alexander Gran <al...@zodiac.dnsalias.org> wrote:
Thanks,

I'll take a look into all references and make sure their expiration headers are OK.
The headers are really just copy pasted, should be correct, however strange they are...
Do I need to worry about the cannot rewrite for unknown reason? Or better, how to get to the unknown reason?!

Problem also happens without cloudfare, they are just proxying.

Cheers
Alex

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.
Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.

Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

Alexander Gran

unread,
Jun 7, 2017, 12:32:32 PM6/7/17
to ngx-pagespeed-discuss
Hi,

here we go. All the following wihtout cloudfront for simplicity.
I have took the js/calendar/menuarrow.gif as the first thing to look at, as this is the first content referenced in the css.
What I se weird is that pagespeed seems to remove its cache-control header.
When I hit /js/calendar/menuarrow.gif?PageSpeed=off I get this.
  1. cache-control:
    max-age=31104000
  2. content-length:
    68
  3. content-type:
    image/gif
  4. date:
    Wed, 07 Jun 2017 16:20:28 GMT
  5. etag:
    "5932afe8-44"
  6. expires:
    Sat, 02 Jun 2018 16:20:28 GMT
  7. last-modified:
    Sat, 03 Jun 2017 12:47:36 GMT
  1. pragma:
    public
  2. server:
    nginx
  3. status:
    200
    Which looks perfectly fine to me (I have removed the double cache-control header I had in the meantime).

    Now the same gif with PageSpeed:
    1. content-length:
      68
    2. content-type:
      image/gif
    3. date:
      Wed, 07 Jun 2017 10:25:39 GMT
    4. etag:
      "5932afe8-44"
    5. expires:
      Sat, 02 Jun 2018 10:25:39 GMT
    6. last-modified:
      Sat, 03 Jun 2017 12:47:36 GMT
    1. pragma:
      public
    2. server:
      nginx
    3. status:
      200
      It has kept the expires, but dropped the cache-control. Now obviously, if pagespeed is using this cache-control to detec if the css has to be regenerated, this goes wrong.

      Comparing that to
      and 
      pagespeed leaves a cache-control header in place.

      BTW, I have tried with and without pagespeed MapOriginDomain localhost www.domain.com, and also with and without pagespeed LoadFromFile

      regards
      Alex
       

      Am Mittwoch, 7. Juni 2017 15:34:16 UTC+2 schrieb Joshua Marantz:
      Right, so when I asked about Cloudflare, I as wondering whether, when PageSpeed fetched its input resources (e.g. css files and the images referenced from them) it as actually fetching them through Cloudflare, which might have cached them, and potentially rewritten their headers.  Or whether when PageSpeed fetches its input resources it does so directly from your origin, either due to MapOriginDomain or LoadFromFile, or the way you have your domains mapped.

      On Wed, Jun 7, 2017 at 9:27 AM, 'Alexander Gran' via ngx-pagespeed-discuss <ngx-pagesp...@googlegroups.com> wrote:
      Yes, also caching, sure. But just the static assets, and my problem is that already in the html (which comes directly from pagespeed) the issue is visible. Also I had the problem when disabling cloudfront(I. E. Not using sharding/rewrite) 

      Isn't there a way to enable logging regarding cache hit/mis? 

      Will check the referenced css/images later tonight. 

      Regards 
      Am 07.06.2017 3:24 nachm. schrieb "'Joshua Marantz' via ngx-pagespeed-discuss" <ngx-pagesp...@googlegroups.com>:
      Cloudlare is just proxying?  Not caching?

      RE "unknown reason"...errr. don't know?  My gut is that this issue is not related to what you are trying to solve here. I think we could track down that string in our .cc file and tease out some more detailed causality, which might involve digging into a few layers of APIs.  However I think it's probably not worth it in this case.

      On Wed, Jun 7, 2017 at 9:15 AM, Alexander Gran <al...@zodiac.dnsalias.org> wrote:
      Thanks,

      I'll take a look into all references and make sure their expiration headers are OK.
      The headers are really just copy pasted, should be correct, however strange they are...
      Do I need to worry about the cannot rewrite for unknown reason? Or better, how to get to the unknown reason?!

      Problem also happens without cloudfare, they are just proxying.

      Cheers
      Alex

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.
      Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
      For more options, visit https://groups.google.com/d/optout.

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      Joshua Marantz

      unread,
      Jun 7, 2017, 12:44:59 PM6/7/17
      to ngx-pagesp...@googlegroups.com
      Sorry, there are a lot of variables in play here.  Let me try to enumerate:
      • Cache-Control setting at origin
      • MapOriginDomain or not
      • LoadFromFile or not (and the caching overrides associated with those)
      • PageSpeed cache has up-to-date cop[y of input resource
      • PageSpeed cache has optimization metadata
      • PageSpeed cache has optimized output resource
      Note that for a multi-input resource like a CSS file with images, the expiration date for the optimization is computed based on the minimum of all the expiration dates for the inputs.  If these are all 1-year (like your headers) then you are good to go (with LoadFromFile off).  But I think if there is a single background-img that 404s on our fetch, then that taints the entire suite of inputs as having 5 minute expiration.  So it's worthwhile scanning your CSS to see if that might be happening.

      If you have LoadFromFile on, then PageSpeed doesn't see your cache-control headers at all (because it loads directly from your disk), so the 1-year input TTL is not used.  To simplify the problem, let's leave LoadFromFile off for now.

      -Josh

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

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.

      Otto van der Schaaf

      unread,
      Jun 7, 2017, 1:56:05 PM6/7/17
      to ngx-pagesp...@googlegroups.com
      There is a gap in time between the date: headers for the requests with pagespeed on and off.
      That strikes me as odd.. Is there another caching layer involved? Or can the time gap be explained otherwise?

      Otto

      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-di...@googlegroups.com.

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

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

      Alexander Gran

      unread,
      Jun 7, 2017, 8:06:27 PM6/7/17
      to ngx-pagespeed-discuss
      Yes, weird. I can't seem to reproduce this now, which I guess is a good sign.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      Alexander Gran

      unread,
      Jun 7, 2017, 8:08:02 PM6/7/17
      to ngx-pagespeed-discuss
      Thanks Josh!

      I wasn't aware of the fact that the 404 has such an influence. Maybe this could need an extra highlight in docs / debug.
      So, to sum that up (and make any fellow coming in via google happy):

      The TTL of a CSS file is based on the minimum TTL of any ressource within that CSS file, any http 404 of a ressource will take that down to 5 minutes.

      Maybe it would be benefical to highligh in debug the ressource(s) that define the TTL of a CSS, so one knows where to look.

      I have now made an effort to eliminate all the 404s (and cleanup some code while on the go;) That seems to have done the trick.

      Will now see to get the other stuff, like loadfromfile back on, and finalise a fight on my svgs.

      regards
      Alex
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.
      Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
      For more options, visit https://groups.google.com/d/optout.

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.
      Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
      For more options, visit https://groups.google.com/d/optout.

      Alexander Gran

      unread,
      Jun 8, 2017, 9:25:00 AM6/8/17
      to ngx-pagespeed-discuss
      Back here again.

      I fear we still have to check the cannot rewrite for an unknown reason issue.
      See this image
      which is one that get this cannot reqrite warning (Its referenced from a css) in debug.

      Pagespeed sets an expire time of 5 minutes.

      When you load without pagespeed, i.e.
      expire time is fine and it also has it's caching info.

      Pagespeed is set to loadfromfile for this url.
      When I disable the loadfromfile, the caching info is fine, but I still get the cannot reqrite info in debug.

      regards
      Alex

      Alexander Gran

      unread,
      Jun 8, 2017, 9:32:29 AM6/8/17
      to ngx-pagespeed-discuss
      you can test the non loadfromfile one at 

      Otto van der Schaaf

      unread,
      Jun 8, 2017, 9:36:44 AM6/8/17
      to ngx-pagespeed-discuss
      There is a known issue that involves assets that cannot be optimized further, in-place resource optimization, and loadfromfile: https://github.com/pagespeed/mod_pagespeed/issues/1485

      There's also a PR with a first stab at fixing it, but I'm not sure if that goes into the right direction yet https://github.com/pagespeed/mod_pagespeed/pull/1492 

      Otto


      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-di...@googlegroups.com.

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

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

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

      Joshua Marantz

      unread,
      Jun 8, 2017, 9:39:22 AM6/8/17
      to ngx-pagesp...@googlegroups.com
      What Otto said.  Plus, LoadFromFile definitely has this limitation in 1.11, but there is a remedy in 1.12 (LoadFromFileCacheTtlMs) and a workaround in 1.11 (ModPagespeedImplicitCacheTtlMs).

      I think in this case, in-place resource optimization is not the main goal, but having the url-rewriting optimization work more consistently.



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

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      Alexander Gran

      unread,
      Jun 8, 2017, 11:07:26 AM6/8/17
      to ngx-pagespeed-discuss
      Sure this is the same issue?
      I tried disabling IPRO and/or LFF, still getting the same issue.
      Also tried bloating up the images (with imagemagick convert -quality 11), still issue persists, albeit they are now optimized.

      Will going to HEAD or merging that PR get me anywhere?

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

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

      Joshua Marantz

      unread,
      Jun 8, 2017, 11:20:08 AM6/8/17
      to ngx-pagesp...@googlegroups.com
      This is related to 5-minute TTLs for in-place optimized results on LoadFromFile inputs.

      It is not related to image optimization failing for unknown reason.  However, image-optimization failures will not affect your cache TTL.


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

      --
      You received this message because you are subscribed to a topic in the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/ngx-pagespeed-discuss/kld8umUYd9c/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.

      --
      You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsubscri...@googlegroups.com.
      Reply all
      Reply to author
      Forward
      0 new messages