[wp-hackers] Front End Performance in WordPress

[John Biddle]

Joost,

I agree that guidelines such as those I've recommended would not be 
enforced.  I don't think they should be.  But with an appropriate 
standard framework for implementing a set of front-end performance 
guidelines, those plugin developers who wanted to would see that they 
could do so in a standard way, and that WordPress was behind them in 
their effort to do so.  WP could publicize the framework, after it was 
created, and could include some sample tests to show the improvement 
that was possible.  These would not be definitive, as every blog is 
different, as is every client, but a representative sample, say a blog 
with 2. 5 & 10 typical plugins, on dial-in and cable modem clients.  
When users see that pages can go from loading in 4 seconds to 2 seconds 
they'll clamor for their favorite plugin developers to participate in 
the program.

I am suggesting that this be entirely voluntary on the part of plugin 
developers, and that each one that chooses to offer these enhancements 
have an option for the blogger to opt-in in order to get the front end 
mprovements.  If the blogger does not, then the plugin would continue to 
operate as it does now.  I realize that this creates extra work for 
plugin developers, and that many may choose not to do it.  However, if I 
am right about the performance improvements to be seen in the rel world 
environment, I believe tht many will do so, and more will be driven to 
by their downloaders.

I confess I do not understand your reference to Google and their 
non-standard approach to APIs.  I don't know anything about Friend 
connect.  Most of the changes I am suggesting will not require any 
cooperation from any third party, just the blogger and the plugin 
developer, once a standard framework has been published and blessed by 
WordPress.

John Biddle

Joost de Valk wrote:
> John,
>
> though I agree with you that it would be good to teach people about 
> this, but you'll never get any guidelines like that enforced... (and 
> sometimes there's just no other way because companies like Google f*ck 
> up stuff in how they do their API's, like with FriendConnect)
>
> Best,
> Joost
>
> John Biddle wrote:
>> 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/>*