[wp-hackers] Front End Performance in WordPress
john at poolstudent.com
Tue Mar 24 03:31:26 GMT 2009
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.
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.
>> 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
*Pool Student's Blog <http://www.poolstudent.com/>*
More information about the wp-hackers