Possible to make filters run in optimised sequence

[GoogleCodeExporter]

Based on a few tests, I believe that there might be a case for a new setting 
(default to off for backwards compatibility), that enforces an order on the 
filters.

The order in which filters are applied currently seems unclear; I get different 
results from turning on filters and putting them in different orders in the 
config file. If these filters ran in an optimal sequence, they would provide 
more optimisation, however, this might mean that operations become blocking. It 
also wasn't clear what order of filters affected what.

Taking the example of scenario of CSS optimisations, this is the ideal order of 
operation:

inline_import_to_link - brings the imports into the document as a link
outline_css - brings css into a file
rewrite_images - self-explanatory
sprite_images - optimises background images as sprites
rewrite_css - self explanatory
combine_css - brings the CSS into an aggregated file
add_head - self-explanatory
combine_heads - self-explanatory
move_css_to_head - self-explanatory
move_css_above_scripts - self-explanatory
insert_dns_fetch - self-explanatory

Given these as sequential operations, the resultant optimisation is greater, 
because of the flow:

1. imported CSS is now a link, as is outline_css (although these could be 
paralleled)
2. images referenced in CSS/HTML are optimised
3. optimised images now used for spriting
4. CSS is optimised
5. CSS from all sources (import and outline in step 1, as well as CSS present 
in <link>) now aggregated into a single file
6. head now added and combined if necessary
7. aggregated link added to head, and above scripts
8. dns-prefetch now can scan and now see the domain shard references.

However, these are clearly blocking operations, so I understand reticence to do 
this.

To mock up what I wanted to achieve, I created several vhosts in Apache, each 
mod_proxying to another, and each running separate filtering on the output. 
Performance, as you can imagine, was not production-worthy, though I believe 
the bottleneck was caused by proxying rather than the sequential nature of the 
tasks, and that I couldn't use ModPagespeedLoadFromFile on anything other than 
the rearmost virtual host. However, the resultant HTML and CSS was much better, 
which, when I put Varnish in front of it, resulted in significant savings.

Irregardless if the example itself needs tweaking, I  would say that it is my 
belief that few could argue that having these filters run on the output of the 
previous filter would make for better optimisation of output. However, whether 
or not the performance of the system as a whole would be worth the penalty is 
not something I'm really an expert at, hence me posting here.

Original issue reported on code.google.com by shri...@gmail.com on 26 Jun 2013 at 11:46

[GoogleCodeExporter]

We already do have a fixed order of filters, and filters optimizing each 
other's output (for many things it's actually a partial order in a dependency 
graph).

In some cases it's purposefully different from what you list, though. For 
example we always run combine_css before rewrite_css as that produces much 
smaller URLs (but javascript optimization always runs before its combiner 
because we won't be able to optimize the JS combiner output).

Original comment by morlov...@google.com on 26 Jun 2013 at 1:37

[GoogleCodeExporter]

Actually, after posting this, I've been doing more experimentation and was 
coming to this conclusion. However, I've been trawling trying to find the order 
of precedence/dependencies through the documentation. Do you have a link?

Original comment by shri...@gmail.com on 26 Jun 2013 at 1:41

[GoogleCodeExporter]

Only a code one. Basically the order of filters is based on how 
RewriteDriver::AddFilters adds them.

Original comment by morlov...@google.com on 26 Jun 2013 at 1:52

[GoogleCodeExporter]

Actually the order is supposed to be accurate in 
https://developers.google.com/speed/pagespeed/module/config_filters

Note the text "The order of the directives in the configuration file is not 
important: the rewriters are run in the pre-defined order presented in the 
table:"

However, there is no mechanical enforcement of this as we add filters & update 
doc, so it's possible we blew it.

Original comment by jmara...@google.com on 26 Jun 2013 at 2:05

[GoogleCodeExporter]

I'm terribly sorry, I missed that line entirely.

Original comment by shri...@gmail.com on 26 Jun 2013 at 2:10

[GoogleCodeExporter]

Original comment by sligocki@google.com on 26 Jun 2013 at 3:30

• Changed state: Closed