outdoors

Hello Marko,

OK ; Thank you for narrowing down the issue to mis-configuration on the CDN or some other plugin. If I am unable to identify the cause, will seek out the technical expertise needed to identify the culprit.

Again thank you for your input

Hello Marko,

Not sure how to apply the last response to address my particular situation; because I am not as familiar with this specialty. I have some understanding but not how to address what you have outlined in order to populate a (cache-control: public, max-age=) for those 13 files. Which is consistent across all pages in regards to cache-control policy.

Is there someone who would give me a quote to identify this issue? Maybe purchase the PRO plugin and get this resolved?

Using GTMetrix there are 13 files out of the 28 request that have No CACHE TTL. This is the consistent throughout all pages.

Here are 3 examples (files) that have a Cache TTL
GTMetrix returns files that have a CACHE TTL (cache-control: public, max-age=)

analytics.js
Request URL: https://www.google-analytics.com/analytics.js
age: 2048
cache-control: public, max-age=7200
strict-transport-security: max-age=3136000; IncludeSubDomains; preload
x-cache: Hit from cloudfront
referer: https://mapnhike.com/

4ceac.js
Request URL: https://d1j7gyeyn3ijac.cloudfront.net/wp-content/cache/minify/4ceac.js
age: 431904
cache-control: max-age=31463637
strict-transport-security: max-age=3136000; IncludeSubDomains; preload
x-cache: Hit from cloudfront
referer: https://mapnhike.com/

JTURjIg1_i6t8kCHKm45_cJD3gnD_vx3rCs.woff2
Request URL: https://fonts.gstatic.com/s/montserrat/v15/JTURjIg1_i6t8kCHKm45_cJD3gnD_vx3rCs.woff2
age: 319178
cache-control: public, max-age=31536000
strict-transport-security: max-age=3136000; IncludeSubDomains; preload

Of the 13 files that do not have a cache-control with a max age; 6 are png files, 3 are .woff files, 1 is jpg, 2 are javascript, and 1 is css.

Is there someone who can identify why those 13 files are not populating a “(cache-control: public, max-age=)” policy and instruct me how to implement.

Thank you

Checked with ShortPixel
Verified there are no settings for a cache-control policy
They do not add anything to the .htaccess file as well
Response From ShortPixel Team: “Unfortunately, we are not related to this – ShortPixel only replaces the physical images and in your case it does not add anything to the htaccess”

Checked other .htaccess files: All located in sub-directories and not located in any parent directories

Found nothing in the httpd.conf that might be construed as referencing rewrite to the images
Could post for your review if needed

Checked Page-Cache-Advanced-Compatibility mode” – This is unchecked

Will continue to search for the reason this is happening and sure it will become apparent soon

Hello Marko

Thank you for all the variations of why this may be happening. Will go through each one and report back any findings. Good to know that the settings are correct in W3 Total Cache.

I am using ShortPixel and will verify any settings that may be affecting the header, the httpd.conf, and any search for any .htaccess files in parent directories. Will report back for those that may have similar issues.

Thanks again for assistance!

Hello, I made sure to speak with an AWS Engineer as well to rule out the Amazon Lightsail Distribution Configuration (CloudFront TTL Settings):

This is the Engineers Comments:

Thank you for your reply and feedback.

I have checked the screen shots that you have kindly provided and can see that both URLs match wp-content/* caching behavior. However, I can see that there is a cache control header set by the origin with both of them with value max-age=10 and this will override CF TTL values:

~ % curl -v /dev/null /wp-content/uploads/2020/09/logo_header-300×260.png” target=”_blank” rel=”nofollow noopener noreferrer”>https://d1j7gyeyn3ijac.cloudfront.net/wp-content/uploads/2020/09/logo_header-300×260.png

* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< content-type: image/png
< content-length: 6851
< server: Apache
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< last-modified: Tue, 17 Nov 2020 15:14:30 GMT
< accept-ranges: bytes
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< referrer-policy: no-referrer-when-downgrade
< pragma: public
< via: 1.1 95f372def48b268a5ae55a9a5ecb4479.cloudfront.net? (CloudFront), 1.1 f0300a9921a99446a44423d996042050.cloudfront.net? (CloudFront)
< x-amz-cf-pop: DUB2-C1
< date: Wed, 18 Nov 2020 18:20:11 GMT
< etag: “1ac3-5b44ef38c7682″
< cache-control: public, s-maxage=10
< x-cache: Miss from cloudfront
< x-amz-cf-pop: DUB2-C1

====================
The same for /wp-content/plugins/elementor/assets/lib/eicons/fonts/eicons.woff2?5.9.1″ target=”_blank” rel=”nofollow noopener noreferrer”>https://d1j7gyeyn3ijac.cloudfront.net/wp-content/plugins/elementor/assets/lib/eicons/fonts/eicons.woff2?5.9.1

cache-control
public, s-maxage=10
content-encoding
gzip
content-type
application/font-woff2
date
Wed, 18 Nov 2020 18:30:35 GMT
etag
“149a0-5b4296743ae56-gzip”
pragma
public
referrer-policy
no-referrer-when-downgrade
server
Apache
================================================

In case the origin sends Cache-Control header with the object, the value specified in the header will be applied as long as it falls between the minimum and the maximum TTL values configured in the CF’s caching behavior. If it’s greater than the maximum TTL, then the maximum TTL will be applied. If it’s lower than the minimum TTL, then the minimum TTL will be applied. Whatever the default TTL value is in this scenario, it will be ignored.

In case the origin doesn’t send Cache-Control header with the object, then the default TTL value should be applied as long as falls between the minimum and the maximum TTL values. If the default TTL value is greater than the maximum TTL, then the maximum TTL will be applied. If it’s lower than the minimum TTL, then the minimum TTL will be applied. So, the default TTL value is the main player here.

That being said, CF TTL values is out of the game here as there is a cache control header set by the origin.

On the other hand, CloudFront serves a file from an edge location until the cache duration that you specified passes—that is, until the file expires. After it expires, the next time the edge location gets a user request for the file, CloudFront forwards the request to the origin server to verify that the cache contains the latest version of the file. The response from the origin depends on whether the file has changed:

If the CloudFront cache already has the latest version, the origin returns a 304 status code (Not Modified).
If the CloudFront cache does not have the latest version, the origin returns a 200 status code (OK) and the latest version of the file.

Conclusion:

If a viewer request hits a specific caching behavior in CF, the default TTL value for that request will be applied UNLESS there is a cache control header set by the origin. If the origin sends a cache-control header, this will override CF TTL values.

I remain at your disposal for any further clarification.

Wish you a great day ahead!

References:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html

We value your feedback. Please share your experience by rating this correspondence using the AWS Support Center link at the end of this correspondence. Each correspondence can also be rated by selecting the stars in top right corner of each correspondence within the AWS Support Center.

Best regards,
Tariq A.
Amazon Web Services

Hello,

Just wanted to make sure I reference the documentation for Amazon Lightsail Distribution.
https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-changing-default-cache-behavior

It caches everything in
wp-inlcudes/*
wp-content/*

Referenced from Lightsail Article Above:

Advanced cache settings
The advanced settings can be used to specify the cache lifespan of content on your distribution, the allowed HTTP methods, HTTP header forwarding, cookie forwarding, and query string forwarding. The advanced settings that you specify apply only to the directory and files that your distribution caches, including the directory and file overrides that you specify as Cache.

You can configure the following advanced settings:

Cache lifespan (TTL)

Controls the amount of time your content stays in your distribution’s cache before your distribution forwards another request to your origin to determine if your content has been updated. The default value is one day. Reducing the duration allows you to better serve dynamic content. Increasing the duration means that your users get better performance because your files are more likely to be served directly from the edge location. Increasing the duration also reduces the load on your origin, because your distribution pulls content less frequently.

Note
The cache lifespan value that you specify applies only when your origin does not add HTTP headers such as Cache-Control max-age, Cache-Control s-maxage, or Expires to your content.

So no way to post/upload images into discussion; Allows me to “Choose the headers that are forwarded to your origin by your distribution. The response from your origin is cached by your distribution only for the specified headers” Right now it is configured “Forward headers I specify to include “host”

Hello,
After disabling CDN.. (W3)

Purged all cache through W3 and Reset Cache from Lightsail Distribution
May take a few moments

Thanks

Hello,

Web URL https://mapnhike.com

If I understood correctly:
Disabled CDN settings (W3 Total Cache – General Settings – CDN – unchecked Enable)
All set (Let me know and will purges cache from W3 and reset cache from Lightsail Distribution.

Viewing Lightsail Distribution and really no way to disable other than delete Distribution and recreate(let me know otherwise). Really don’t want to do that unless it is a must ?? …Let me know if this is the only way to verify the images not propagating the cache control.

CSS, JavaScript files working; cache-control max-age xxxxxxx

Hello,

Not aware if the issue started after I enabled CDN; All was initially configured and then began testing with GT Metrix.

URL for .htaccess file https://www.codepile.net/pile/q37MW1mY

Viewing Amazon Distribution Default behavior
(This Distribution is created in Amazon Lightsail; SSL and referenced in Route 53 DNS with A record “Alias to Cloudfront Distribution as per AWS engineers. https to https.
Cache Behavior
Cache wp-includes/*
Cache wp-content/*

Advanced cache settings:
Updates every day
Allow GET, HEAD, and OPTIONS methods
forward HTTP headers I specify
forward no cookies
forward all query strings
Last reset cache 11/18/2020 8:12AM

Let me know if I missed anything
Thanks