Hint Resource Preloading

Note: New feature as of


The 'Hint Resource Preloading' filter is enabled by specifying:

ModPagespeedEnableFilters hint_preload_subresources
pagespeed EnableFilters hint_preload_subresources;

in the configuration file.


'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.


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


You can see the filter in action at www.modpagespeed.com on this example.


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).


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.