[wp-hackers] Front End Performance in WordPress

[John Biddle]

Austin & Otto,

I'm not sure we're talking about the same thing, re:expired headers.  
Many plugins have files that get included in posts and/or pages, graphic 
files of various favors, .css & .js files, etc.  It is rare in my 
experience that these files have expired headers.  Because they do not, 
even though they'll be in the cache for all pages after the first, there 
is still a round trip made to the server for each one of them to verify 
that the file in the cache is the most current one.  Though the 
turnaround time for these round trips is small, they add up quickly when 
there are many of them, as there often are.

I see two straight-forward ways to fix this, both of which would require 
the developer's voluntary cooperation (not a problem, as I said in my 
original email).  Also, each could easily be subject to an opt-in by the 
blogger.  The default should be to keep the behavior as it is today.  I 
don't claim these are the only ways, or the best ways, and I'm more than 
open to suggestions for improvements.

First, the plugin could come with an optionally included .htaccess file 
that would take care of the relevant files for that plugin.  It could 
include alternative files or instructions for non-Apache servers that 
offer similar capability.

Second, and strongly to be preferred IMHO, would be to have a single 
location, defined by the blogger, where these files would be kept.  Each 
plugin could create their own directory underneath that directory for 
their files to avoid files of the same name overwriting each other.  The 
whole structure could have a .htaccess file (or equivalent for other 
environments) to expire all files of the various graphics formats, .css 
& .js.  Other appropriate formats also could be added.  .css files are 
more problematic, since bloggers may wish to modify them to fit better 
with their theme.  They would want to do so before putting the file into 
the expired headers location, since if they did modifications after, not 
everyone would see them.  Since .css files may be affected by other 
rules, they may not be in the list of files to be included in the 
expired headers location.

As plugin developers upgrade their apps, they'll need to change the 
names of these static files for those that have changed, to avoid users 
loading an out of date version from their local cache.  The developer 
could use a version number or date to append onto the filename, and that 
portion would change appropriately.  The upgrade would delete the old 
after installing the new was successful.

I'm pretty sure that nothing like this exists currently, or at least if 
it does not very many plugin developers use it.

If the second approach is taken, and if that single location is located 
in a subdomain, then performance is boosted again because of the 
increase in parallelism made possible by the second domain.  Instead of 
2 files at a time being downloaded by the browser, now 4 files can be 
downloaded simultaneously.  For a blog with a number of plugins, these 
two improvements would be quite significant, for what seems to me to be 
a relatively small effort.  It would take time before a majority of 
plugin developers did this, but with WP standardizing on a technique and 
publicizing the potential benefits (they are quite real and quite 
significant) I think many would comply quickly.  The bloggers who care 
would then favor plugins which followed these front-end performance 
guidelines and that pressure would cause other developers to follow suit.

John Biddle

Austin Matzko wrote:
> On Mon, Mar 23, 2009 at 3:47 PM, Otto <otto at ottodestruct.com> wrote:
>   
>> On Mon, Mar 23, 2009 at 3:27 PM, John Biddle <john at poolstudent.com> wrote:
>>     
>>> *#13)  Configure ETags:  *I confess I don't really understand this one.
>>>       
>> http://en.wikipedia.org/wiki/HTTP_ETag
>>
>> WordPress already has these, as well as the Last-Modified headers.
>>     
>
> I think WordPress sends Last-Modified headers only for feeds.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>   


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