Hey All,
I am new to the forum here. I have a question about why when I test the main site domain forum.bonusfeber.no; I get failures on Browser Cached images. But if you try the images directly (@either cdn. OR forum.) they will pass with flying colors?
Leverage browser caching of static assets: 50/100
FAILED - (No max-age or expires) - http://cdn.bonusfeber.no/styles/default/xenforo/icons/reisemal.png
FAILED - (No max-age or expires) - http://cdn.bonusfeber.no/styles/default/xenforo/icons/reisebrev.png
FAILED - (No max-age or expires) - http://cdn.bonusfeber.no/styles/default/xenforo/icons/andre_programmer.png
FAILED - (No max-age or expires) - http://cdn.bonusfeber.no/styles/default/xenforo/icons/hoteller_og_bonusprogrammer.png
Thanks,
-Bill
They don’t, actually. Compare these results:
Both show that navigation-tab.png has no expiry headers. Some other images do, however.
My guess is that you set up caching headers for these images after CloudFront first fetched them from your server. Not just the images, but also the headers are cached by the CDN at the initial pull request. To update the header contents, you’ll need to purge these resources from CloudFront’s edge servers. You can do this fairly easily from the AWS panel.
If you’re pushing your resources manually to CloudFront, rather than having them pulled from your server at the first request, you’ll have to manually correct the headers (in S3 or wherever you store them).
robzilla:
They don’t, actually. Compare these results:
WebPageTest Test - WebPageTest Details
WebPageTest Test - WebPageTest Details
Both show that navigation-tab.png has no expiry headers. Some other images do, however.
My guess is that you set up caching headers for these images after CloudFront first fetched them from your server. Not just the images, but also the headers are cached by the CDN at the initial pull request. To update the header contents, you’ll need to purge these resources from CloudFront’s edge servers. You can do this fairly easily from the AWS panel.
If you’re pushing your resources manually to CloudFront, rather than having them pulled from your server at the first request, you’ll have to manually correct the headers (in S3 or wherever you store them).
Hey Robzilla,
Yah… I tried a couple invalidations, but they still don’t seem to come through. Here is a curl -I result from one of the images:
curl -I http://cdn.bonusfeber.no/styles/default/xenforo/icons/bonusfeber_lounge.png
HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 3102
Connection: keep-alive
Accept-Ranges: bytes
Cache-Control: max-age=2678400
Cache-Control: public, must-revalidate, proxy-revalidate
Date: Mon, 07 Oct 2013 08:54:56 GMT
ETag: “523ca680-c1e”
Expires: Thu, 07 Nov 2013 08:54:56 GMT
Last-Modified: Fri, 20 Sep 2013 19:48:16 GMT
Pragma: public
Server: nginx
Age: 24341
Via: 1.0 xxxxx.cloudfront.net (CloudFront)
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: xxxxxxxx
AND here is the NGINX Config for that directory:
location ~ ^/(styles|css|js|cometchat|3p_content|data/attachments)/.*.(jpg|jpeg|gif|png|css|js|ico|xml|swf)$ {
access_log off;
log_not_found off;
expires 31d;
add_header Pragma public;
add_header Cache-Control “public, must-revalidate, proxy-revalidate”;
}
Is there anything missing from this header? I see a Max-Age so I don’t know why WPT says that there isn’t.
Thanks,
-Bill
Do you have a link to your WPT test results? The expiry headers are visible here:
http://www.webpagetest.org/result/131007_WX_T2X/1/details/
The results for your forum page show there are some PNGs without expiry headers:
http://www.webpagetest.org/result/131007_6F_T40/1/performance_optimization/#cache_static_content
When I fetch these images manually, I don’t get the expiry headers either, but that’s probably because they need to be purged first.
Since you’re redirecting forum.* to cdn.*, I can’t check the exact headers nginx sends for these images.
Hey robzilla,
I did an “invalidation” on
styles/
styles
from the AWS console, hours before I tested.
cdn.* points to the CDN who’s origin is stat.*
I curl -I tested the with with stat.* and while it shows in a slightly different order; it was all there:
curl -I http://stat.bonusfeber.no/styles/default/xenforo/icons/bonusfeber_lounge.png
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=2678400
Cache-Control: public, must-revalidate, proxy-revalidate
Content-length: 3102
Content-Type: image/png
Date: Mon, 07 Oct 2013 20:11:55 GMT
ETag: “523ca680-c1e”
Expires: Thu, 07 Nov 2013 20:11:55 GMT
Last-Modified: Fri, 20 Sep 2013 19:48:16 GMT
Pragma: public
Server: nginx
Connection: keep-alive
The CDN reports an Age header with a value of 547175 for this image: http://cdn.bonusfeber.no/styles/default/xenforo/icons/bonusfeber_lounge.png
Unless I’m mistaken, 547175 is approximately one week. Did you invalidate styles/* a week ago?
Also, note that there are no expiry headers for images within the 3p_content folder, such as http://stat.bonusfeber.no/3p_content/imgs/bonusfeber_logo.png
Hey robzilla,
Yah, I ran the invalidation before, not even an hour had past. I just tried another invalidation with:
styles/*
styles/
styles
3p_content/*
3p_content/
3p_content
And it is still showing… I am guessing this might be an issue on the AWS side then, with the invalidations not working. However, I am still confused why it does show on the CURL but WPT still says there is no max-age.
-Bil
Yeah, the age is now 593784 so apparently these files aren’t purged properly.
As for your images within 3p_content showing no cache headers (on stat.*), that’s probably a problem in your nginx configuration.
Since it’s a CDN, you may be hitting a different edge server locally than WPT is from its test location.
robzilla:
Yeah, the age is now 593784 so apparently these files aren’t purged properly.
As for your images within 3p_content showing no cache headers (on stat.*), that’s probably a problem in your nginx configuration.
Since it’s a CDN, you may be hitting a different edge server locally than WPT is from its test location.
Hey robzilla,
I got it all figured out. Thanks! I individually invalidated the files that were listed on the WPT page and the 3p_content; There was a previous directive in the NGINX config that was overriding the config I showed you. All fixed now
Thanks again,
-Bill