[wp-hackers] Front End Performance in WordPress

[John Biddle]

This is my first post to the list, so if I've done something wrong I 
apologize in advance.  It's a long one, but I hoe it will spur a great 
discussion.

WordPress performance is talked about all the time, but much of the 
discussion seems to be on the performance of the back end, while the 
bulk of the improvement opportunity is in the front end.  Steve Souders 
excellent book High Performance Web Sites, published by O'Reilly lists 
14 rules that if followed can boost front end performance on websites 
substantially.  Most do not require any significant or complex efforts.  
However, most are difficult to impossible for a technically proficient, 
let alone an average blogger, to implement in WordPress.

I used Steve's rules to optimize my site before I went to WordPress and 
they worked extremely well.  My site performed spectacularly.  Once I 
moved to WP, the speed dropped greatly.  WP is doing more, I'm ok with 
some of the slowdown, but most of the performance drag is due to poorly 
optimized code from the perspective of the front end.

Much of the improvement potential is in changing the way some things are 
done in plugins.  I know plugins are written independent of Automattic 
and WordPress, but it seems to me that if there were guidelines on how 
plugins could be written to maximize performance, and if WP had a 
structure supporting same, that plugin developers would do it 
voluntarily, sine they believe in WP and genuinely want the best end 
result for the end user. 

I don't claim to be a great developer, and I am relatively new to 
WordPress, but I think these will at least make the ideas clear.  
Implementation I gladly leave to much more capable hands.  The numbers 
refer to the rules in Steve Souders book High Performance Web Sites.

*#1)  Make Fewer HTTP requests:  *More than a few WP plugins have 
multiple Javascript files.  Best practice would be to combine these into 
one.  Average round trip to the server is between 0.1 and 0.2 seconds, 
so picking up a few begins to make a difference.

Combining JS files from multiple plugins and core WP would save 
additional round trips, but becomes more difficult to manage.  People 
will have different opinions on the tradeoff between ease of management 
and performance.  I'm not suggesting that performance always wins, I'm 
just saying that there is a lot of performance improvement potential to 
be mined here and in the other rules that clever development might turn 
into gold.

Another place to save is in plugin-specific CSS files.  A large number 
of plugins have these, some more than one.  Combining these into 
STYLE.CSS in the theme saves more round trips.  This one is more 
problematic, since as a plugin is improved, additional lines added to 
the plugin specific css file would need to be added to STYLE.CSS.  I 
think this is manageable, since it probably doesn't happen often. 

If a plugin is deactivated, the plugin specific css code in STYLE.CSS 
should be purged.  I suppose this could be automated is all plugin 
specific css code began and ended with unique values, but this is 
probably too much trouble.  Bloggers could run a plugin for a little 
while and decide if they like it, use the current behavior, then switch 
to high performance behavior if they choose to keep the plugin active.

When a theme is replaced for a new on, the changes would have to be 
redone, but with the right process this should be automatic.

Social Bookmark plugins and others with multiple small graphics should 
be strongly encouraged to use sprites for said graphics.  Every one is 
another round trip, even when in the cache (more later). 

*#2)  Use a Content Delivery Network:  *This doesn't have to be a paid 
service type CDN to get the benefit, just a subdomain, free to most 
bloggers.

If WP had a standard way for a blogger to store his/her CDN subdomain 
(and optionally directory, one for each plugin) then if the blogger 
checked a box in the setup of a plugin, that plugin would know to use 
install and use the copy of static files in the CDN.  The plugin 
developer would be in charge of determining which files were static.

*#3)  Add an Expires Header:  *By doing this, the round trip to the 
server to determine if the file in cache is current is eliminated.  It 
greatly enhances the value of having things in the cache.  Especially in 
a blog, where so many things are the same from page to page, this 
savings can be quite significant.  By providing a standardized .htaccess 
file for bloggers on an Apache server (and other comparable 
documentation for other common servers that support this), WP greatly 
improves the value of the pseudo CDM described above, since the files in 
it will be those that aren't changing.  Since plugin developers are in 
control of what goes into the pseudo CDN (if the blogger has chosen to 
use one) they are in a position to introduce a new version of a file 
they though wouldn't change by issuing it with a new name.  WP could 
suggest a standard approach to this, like using a version number or a 
date at the end of the filename.

*#4)  Gzip Components:  *WP already supports Gzip, great.  However, by 
providing a structure and standard mechanism, more files could be 
Gzipped for those choosing to do so.  JS and CSS files fall into this 
category, again, optional.

*#5)  Put Style sheets at the Top:* This is already enhanced by the work 
in #1 to combine CSS files into STYLE.CSS.

*#6  Put Scripts at the Bottom:  *Some scripts do this now, but if WP 
encouraged the community to offer this as an option, more would do so, 
and many bloggers would take them up on it, and gain performance because 
of it.  Sometimes this doesn't work, and moving the Javascript up can't 
be helped, but all plugins shouldn't avoid this because a few would have 
problems.

*#7  Avoid CSS Expressions:  NA*

*#8  Make Javascript and CSS External:  *This is already done by most, 
but it certainly wouldn't hurt to make a point of how much t helps.

*#9  Reduce DNS Lookups:  *Some plugins rely on JS code from 3^rd 
parties, like Google, and go get that code repeatedly from those sites.  
I suggest making it optional for the blogger to choose to keep that 3^rd 
party code on his/her own server.  This avoids DNS lookups and may 
improve download performance as well.  The JS file for Google Analytics 
is a case in point. JS libraries are another.

*#10)  Minify Javascript:  *Plugin developers should be strongly 
encouraged to minify their JS files.  They are in the best position to 
verify that they work after processing.  WordPress could help by either 
recommending a preferred product to use or even making it easier and 
providing it.  Many do this but all should.  Some still won't but so what.

*#11)  Avoid Redirects:  NA*

*#12)  Remove Duplicate Scripts: * This is partially solved by 
implementing #3, and can be enhanced further through the use of script 
management.  See Souder's book, High Performance Web Sites, page 87.

*#13)  Configure ETags:  *I confess I don't really understand this one.

*#14)  Make Ajax Cacheable:  *Probably not relevant at this time.


John Biddle
-- 
*Pool Student's Blog <http://www.poolstudent.com/>*