Serve static assets with an efficient cache policy - TTL is set to None

[sunithakarthikeyan]

URL Tested: https://www.sify.com/

Serve static assets with an efficient cache policy 71 resources found

Concern : TTL was set as 365 days for css/js/jpg in CDN (CloudFront) & Browser Caching also enabled for 365 days

But the test result says resource 'https://www.sify.com/css/sifyhomebootstrap.css" TTL as NONE

However when CSS file is test individually it says 100 %

curl -H "Accept-Encoding: gzip" -I https://www.sify.com/css/sifyhomebootstrap.css

HTTP/2 200

content-type: text/css

date: Fri, 28 Feb 2020 08:41:49 GMT

server: nginx/1.14.0 (Ubuntu)

last-modified: Wed, 22 Jan 2020 11:17:22 GMT

etag: W/"5e282f42-1560e"

expires: Sat, 27 Feb 2021 08:41:49 GMT

cache-control: max-age=31536000

content-encoding: gzip

vary: Accept-Encoding

x-cache: Hit from cloudfront

via: 1.1 dfe5e935c0c0fad38fd86957eb86fe51.cloudfront.net (CloudFront)

x-amz-cf-pop: DEL54-C3

x-amz-cf-id: lKku9kMxjd_7DlnJeeiCpMsn-rdDZagZb9nT9z7tCx10llMLdvbAzQ==

age: 272426

[patrickhulce]

Thanks for filing @sunithakarthikeyan! I'm not able to reproduce this issue though. Could you provide the rest of the information from the bug template?

The only resources I see it flagging are these three which seem to be legit.

[nerlijma]

Happens the same to me.

site: https://odontologiazingman.com/

Checking with google page speed insights:

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fodontologiazingman.com%2F&hl=es

for instance: it marks mapa.png as no cached:

But:

First time you loaded it in chrome it returns 304 - Not modified, and in the docs it says:

Maybe 304 has to added to consider a resource cacheable to (when it has also the cache-control response header...?

[patrickhulce]

I'm not able to reproduce your result either @nerlijma everything passes :/

[nerlijma]

@patrickhulce, you are right, it seems that chrome and google developers page

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fodontologiazingman.com%2F&hl=es

do not use the same version of lighthouse. In chrome audit, the error is gone.

[peixotorms]

@patrickhulce

This is likely related to #10532 that I reported 3 weeks ago.

If you test from different regions, you get different score results. Now it seems there is also inconsistency in this metric as well... for example:

I am also seeing this on another site.

Here is a test from Japan: https://i.imgur.com/IR1iQpF.png

And here is the same test from Canada: https://i.imgur.com/06Q7Db2.png

Can't you guys proxify all requests through the USA or something like that, to ensure consistency?

For example, web.dev always makes requests from the same region, so why would the pagespeed insights tool make requests from different regions, depending on where the user is testing from?

[patrickhulce]

This is likely related to #10532 that I reported 3 weeks ago.

Thanks for the insight @peixotorms!

I would expect these to be completely orthogonal root causes though.

Performance metrics and the score are expected to be different depending on the test location, i.e. users using your application from different locations will experience different performance and so any UX-centric performance metrics should capture that difference or they are inaccurate. Meanwhile cache headers received on individual resources are not expected to be different depending on the test location.

The rest of your comment is better continued in #10532

[peixotorms]

Yes, I agree they can be completely different root causes, but they are still related in a sense, that different regions "likely" have slightly different deployed code, or maybe there is some cache in between that needs to be purged.

I don't know if it's only one region having the cache headers issue, or if it's random. I could be on a site by site case or it could be that it always happen in certain regions.

[exterkamp]

May be related to these other header issues... #10610

[sfarbota]

I am seeing the same issue as well with the latest stable version of Chrome. Hopefully these additional details will help.

Provide the steps to reproduce

1. Run LH on https://www.coleparmer.com/
2. Expand "Serve static assets with an efficient cache policy" section
3. Look for images reporting no TTL

What is the current behavior?

"Serve static assets with an efficient cache policy" section of Lighthouse on Chrome DevTools reports many image files as having no TTL even though they have a cache-control/max-age header.

What is the expected behavior?

Lighthouse should only report the files that truly have no TTL.

Environment Information

• Affected Channels: Chrome DevTools (not sure about others)
• Lighthouse version: 5.7.0
• Chrome version: first noticed in 81.0.4044.122 (Official Build) (64-bit), then updated to 81.0.4044.129 (Official Build) (64-bit) and the issue persists
• Node.js version: ? (Is this relevant for Chrome DevTools issues?)
• Operating System: Windows 10 Pro, Version 1809, OS build 17763.1158

Additional Details

• Location: Los Angeles, California, USA
• Date/Time: 4/29/2020 @ 10:30 AM PT
• Issue exists in Incognito session: Yes
• Issue exists in Guest session with no extensions: Yes
• Customized Chrome flags:
  • Out of blink CORS: Disabled
  • SameSite by default cookies: Enabled
  • Enable removing SameSite=None cookies: Enabled
  • Cookies without SameSite must be secure: Enabled
• JSON Export of LH audit from Chrome DevTools: https://pastebin.com/V8qapmEY
• Sample from above export showing incorrect 0 values for image cache TTL:

"items": [
          {
            "url": "https://pim-resources.coleparmer.com/image-badge/always-in-stock-sm.png",
            "cacheLifetimeMs": 0,
            "cacheHitProbability": 0,
            "totalBytes": 23604,
            "wastedBytes": 23604
          },
          {
            "url": "https://pim-resources.coleparmer.com/image-badge/buy-more-and-save-sm.png",
            "cacheLifetimeMs": 0,
            "cacheHitProbability": 0,
            "totalBytes": 23576,
            "wastedBytes": 23576
          },

• Screenshots:

[ManishMaheshwari]

This issue is also observed when testing www.expedia.com. Lighthouse 5.7.1 is reporting logo.svg as a non-cacheable resource, whereas the same is cacheable in the server response.

[patrickhulce]

@ManishMaheshwari there is a comma missing in that cache-control response header

[septatrix]

Why does Lighthouse require an explicit Cache-Control? To my knowledge browser already start caching resources as long as an ETag and Last-Modified are set

[chrisjshields]

Any update on this? Still seeing a TTL of None in Lighthouse when Cache-Control is set to public, max-age: 31536000 (one year)

[WebWizzards]

Ditto, I am having the same issue. Is there "still" no update/fix on this from Google/Lighthouse!?

[crosskpixel]

The same here

[hydRAnger]

The same here