[wp-hackers] Front End Performance in WordPress

[Joost de Valk]

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 

-- 
me *Joost de Valk*
Online Marketing, WordPress, SEO & Social Media Strategy
OrangeValley <http://www.orangevalley.nl> & Yoast <http://yoast.com>
E: joost at orangevalley.nl <mailto:joost at orangevalley.nl> - 
joost at yoast.com <mailto:joost at yoast.com>
T: +316-24-555-808 | @jdevalk <http://twitter.com/jdevalk> on Twitter