Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Site Health test to verify that static assets are served with far-future expires #323

Open
westonruter opened this issue May 3, 2022 · 5 comments · May be fixed by #1727
Open

Add Site Health test to verify that static assets are served with far-future expires #323

westonruter opened this issue May 3, 2022 · 5 comments · May be fixed by #1727
Labels
Needs Dev Anything that requires development (e.g. a pull request) [Plugin] Performance Lab Issue relates to work in the Performance Lab Plugin only [Type] Enhancement A suggestion for improvement of an existing feature

Comments

@westonruter
Copy link
Member

westonruter commented May 3, 2022

Feature Description

In order to leverage the browser cache effectively, page assets like images, scripts, and stylesheets should all be served with far-future expires. A Site Health test could be added which checks for the necessary asset response headers (i.e. Cache-Control and/or Expires) and warns when they are not present. The call to action would be to fix the web server configuration, potentially prompting the user to contact their host.

@mxbclang mxbclang added the [Type] Enhancement A suggestion for improvement of an existing feature label May 5, 2022
@manuelRod
Copy link
Contributor

manuelRod commented May 9, 2022

That makes sense, should we define the cache headers list and what we consider far-future expire?

@westonruter
Copy link
Member Author

I think the headers would be Cache-Control with max-age and/or an Expires. As for the time that should be considered future, I recall generally 1 year as being normal for this. But 1 week would probably work just as well. In any case, the threshold should be filterable.

Also, there could be some cases where an author needs for an asset to not have a far-future expiration date. In that case, there could be a filter to exclude it from the test.

Lastly, in addition to far-future expiration, the test could also check for ETag and Last-Modified and if no far-future expiration is present, do a secondary request to the same asset URL with If-None-Match and If-Modified-Since, respectively. If those return with 304 Not Modified then that could pass the test as well, although not as good as far-future expiration.

@joemcgill joemcgill added the [Plugin] Performance Lab Issue relates to work in the Performance Lab Plugin only label Nov 27, 2024
@mukeshpanchal27 mukeshpanchal27 added the Needs Dev Anything that requires development (e.g. a pull request) label Nov 27, 2024
@joemcgill
Copy link
Member

@westonruter out of curiosity, do you think this is something that a site admin could take direct action on?

@westonruter

This comment has been minimized.

@westonruter
Copy link
Member Author

Good question. Maybe not directly. They'd have to ask their host to fix the static asset response headers. But I do know that some plugins can modify .htaccess files to add the required rules, assuming they're on Apache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Dev Anything that requires development (e.g. a pull request) [Plugin] Performance Lab Issue relates to work in the Performance Lab Plugin only [Type] Enhancement A suggestion for improvement of an existing feature
Projects
None yet
6 participants