On 23 Jul 2015, at 22:30, Eli Handel
<elihandel(a)gmail.com> wrote:
Hi,
I just submitted my site to
https://developers.google.com/speed/pagespeed/insights/ and I
get:
Consider Fixing: Leverage browser caching: Setting an expiry date or a maximum age in
the HTTP headers for static resources instructs the browser to load previously
downloaded resources from local disk rather than over the network. Leverage browser
caching for the following cacheable resources:
http://www.xxx.com/w/load.php?debug=false&lang=en&modules=mediawiki…
(5 minutes)
http://www.xxx.com/w/load.php?debug=false&lang=en&modules=site&…
(5 minutes)
http://www.xxx.com/w/load.php?debug=false&lang=en&modules=site&…
(5 minutes)
http://www.xxx.com/w/load.php?debug=false&lang=en&modules=startup&a…
(5 minutes)
Hi Eli,
Automatic tools like these are useful to discover potential issues but they can sometimes
be out-of-context or disproportionate. In this case, these requests are being cached in
the browser just fine. Nothing to worry.
They are not re-downloaded by browsers every 5 minutes. Instead, once in 5 minutes the
browser does a quick check (aka "HTTP 304 Not Modified") to see if a new version
is available. Unless you upgraded MediaWiki again, there will not be a new version. The
server will not send the file. The browser will know that the version is still up-to-date
and uses the cache every time.
This may sound inefficient, but is intentionally designed this way so that articles can be
flexibly cached for very long.
Unless you have reason to believe this is causing your site to be slow, I wouldn't
worry about it. This warning is intended for MediaWiki developers and we're aware of
it. This is planned for the future but not a priority because it would have relatively low
impact. There are other more important performance issues that we know are causing things
to be slow.
Also note that browsers support SPDY nowadays, which means 304-checks like these can be
quite cheap. Perhaps even preferable, in which case there wouldn't be a warning.
-- Krinkle