Hint Resource Preloading
Note: New feature as of 1.12.34.1.
Configuration
The 'Hint Resource Preloading' filter is enabled by specifying:
- Apache:
ModPagespeedEnableFilters hint_preload_subresources
- Nginx:
pagespeed EnableFilters hint_preload_subresources;
in the configuration file.
Description
'Hint Resource Preloading' uses resource preloading HTTP headers to inform browsers of CSS and JavaScript resources early in page processing, to permit them to fetch them earlier than would otherwise be possible.
Operation
The 'Hint Resource Preloading' filter operates by inserting HTTP headers based on content observed in the HTML page (and CSS loaded from it) on earlier visits; it does not alter the HTML.
For example, if the HTML document looks like this:
<link rel="stylesheet" type="text/css" href="styles/all_styles.css"> <img src="bigimage.jpeg"> <script src="script.js" type="text/javascript"></script>Where
all_styles.css
contains:
@import url("basic.css"); @import url("fancy.css"); @import url("print.css") print;
Then PageSpeed will add the following HTTP headers to the page:
link: </styles_all_styles.css>; rel=preload; as=style; nopush link: </basic.css>; rel=preload; as=style; nopush link: </fancy.css>; rel=preload; as=style; nopush link: </script.js>; rel=preload; as=script; nopush
Example
You can see the filter in action at www.modpagespeed.com
on this
example.
Limitations
This filter only discovers resources specified in the HTML.
Additionally it can follow one level of @import
inclusion from
<link>
ed stylesheets to find additional stylesheets to hint.
Resources loaded by scripts and further inside CSS will not be hinted for
preloading. The filter itself does not look inside <style>
blocks, but the default-enabled
inline_import_to_link filter can make some of their contents accessible.
The filter cannot understand complex media queries, so it will handle them conservatively, assuming the resource isn't needed.
When optimizations done by other filters expire, hints for optimizing those resources will not be generated (as it is unknown whether they'll get re-optimized at the point the HTTP headers are generated).
Risks
This filter is considered low risk. Since it only adds HTTP headers it is
extremely unlikely to affect page correctness, as HTTP headers are generally
invisible to web page operation, though a script using
XMLHttpRequest
to request a rewritten page would be able to
observe them.
However, the addition of extra headers can be counterproductive if the resources they hint are already easy to discover from the browser's parser, especially in HTTP/1, which lacks header compression.