speed

You are currently browsing articles tagged speed.

Yahoo’s excellent Exceptional Performance series recommends optimizing images in several lossless ways:

* stripping meta data from JPEGs

* optimizing JPEG compression

* converting certain GIFs to indexed PNGs

* stripping the un-used colours from indexed images

Smush.it offers an API that performs these optimizations (except for stripping JPEG meta data) automatically, and this plugin seamlessly integrates Smush.it with WordPress.

via WordPress › WP Smush.it « WordPress Plugins.

  • Share/Bookmark

Tags: , , , , , , , , ,

WordPress is one of the most popular blogging platforms in the world.  It’s fast, easy to use, easy to extend, and great at helping you hunker down and create great content.  WordPress works out of the box on many different hardware and software configurations, with different url schemes, database setups, plugins, themes, et cetera.  As a result, it has to make quite a few tradeoffs when it comes to performance.

So, you have your WordPress set up with the look and feel that you want, but how do you make it faster?

There are three primary things that make your site slow: lots of requests (too many external javascripts and stylesheets, as well as images), lots of data to send, and complexity of the page (tons of flash, really complicated javascript, etc.)

Here are five often overlooked but extremely useful tips you can use to speed up your WordPress blog dramatically, along with page load time benchmarks on a rather plain installation.

  1. Minify and combine your CSS and JavaScript
    Combining your stylesheets and javascripts into at most one external file will cut down on the amount of connections the browser has to make in order to retrieve your page. This will result in dramatic speedups! Additionally, YUI Compressor can reduce the output size of your CSS and JavaScript considerably, and should be a mandatory process in getting your blog ready for handling a digging.
  2. Move CSS, Javascript, and Images to a CDN
    A content delivery network will deliver your javascript, stylesheets, images, and whatever other content you have, to your users far faster than your site can. It works by putting lots of machines all over the world, and directing your users (transparently) to the machine closest to your user.Amazon CloudFront is great for this, using Amazon S3 as the storage behind it: it’s fast, cheap, and (relatively) painless to set up.When setting up a CDN, make sure to follow the next item, and additionally set a far future expires header. An Expires header that is set more than 48 hours in the future will prevent most browsers from bothering to request a file again to see if it is modified, and will make your site appear fast as greased lightning to repeat visitors!
  3. gzip your CSS, JavaScript, and html
    While you are moving your CSS and JavaScript to a content delivery network, you should check to see what is required to send those files encoded with gzip – it reduces the size of the content transferred over the wire dramatically. Note that many people will mention that some browsers do not support this, so caveat emptor: if you are expecting users of 4.x browsers (eg. Netscape Navigator 4.x, Internet Explorer 4.x), you may want to check to see what files will work correctly when sent gzipped to these browsers. To enable gzipping of WordPress’ output, you can use a plugin like Gzippy.
  4. Check for duplicate javascript:
    Multiple copies of prototype, jquery, etc. cut into both page load time and processing time.  Try to stick to plugins that all use the same library, and try to do everything you can to not add any extra javascript at all.  Remember that
  5. Avoid excessive use of any external content.
    Most blog readers come to a blog for the content, and do not pay attention to or use items that come from external pages.  If the flash/javascript/foobar is integral to the post’s content, put it after the jump so that it does not slow rendering of your index page for those who do not want to see that item.  Particularly of note as of the time of this writing are:

    • MyBlogLog – loads a huge flash element from minimally responsive servers
    • Odiogo – their wordpress plugin loads a snippet of javascript in the head of the document, which blocks rendering of your page until their server has responded, in addition to excessive use of inline javascript in places that are obtrusive to users who don’t want to use text to speech.
  • Share/Bookmark

Tags: , , , , , , , , , , , , , , , , , , , ,

Johannes S hacked the living daylights out of some import scripts and has an up-to-date php-src git mirror.

This is really awesome not only because I absolutely love Git, but because it makes it a LOT easier to get work done.

Example*:

mjc@325i:~/scratch$ time (curl -O http://snaps.php.net/php5.3-200812031930.tar.bz2 ; tar xjf php5.3-200812031930.tar.bz2 )
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10.1M 100 10.1M 0 0 551k 0 0:00:18 0:00:18 --:--:-- 570k
real 0m32.450s
user 0m4.844s
sys 0m0.820s

cvs:

mjc@325i:~/scratch$ time cvs -Q -d :pserver:cvsread@cvs.php.net:/repository checkout -r PHP_5_3 php5

real 0m56.865s
user 0m4.828s
sys 0m4.308s

git, nearly the same workflow (requiring no extra thinking other than to learn the syntax):

mjc@325i:~/scratch$ time (git clone src/mysqlnd/php-src php-src; cd php-src; git checkout -b php-5.3 origin/PHP_5_3)
Initialized empty Git repository in /home/mjc/scratch/php-src/.git/
0 blocks
Checking out files: 100% (10636/10636), done.
Branch php-5.3 set up to track remote branch refs/remotes/origin/PHP_5_3.
Switched to a new branch "php-5.3"

real 0m8.655s
user 0m1.616s
sys 0m1.992s

* this test performed on an Amazon EC2 small instance, bandwidth may vary, but it is significantly faster than my local connection and disk drive.

Additionally, even with an empty cache, and the fact that git clone is copying the ENTIRE history, git clone was only four times slower than a primed cache cp of the CVS checkout!

mjc@325i:~/scratch$ time cp -r php5 php5_some-other-work

real 0m1.802s
user 0m0.064s
sys 0m0.704s

Note, though, that if I were to use the standard git workflow, the real time savings start to show.

To test this, first lets see how big the project is, and double it:

mjc@325i:~/scratch/php-src$ git checkout origin/PHP_5_3
Note: moving to "origin/PHP_5_3" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b
HEAD is now at 0986ce9... fix possible invalid read
mjc@325i:~/scratch/php-src$ du -hc .cvsignore .gdbinit * | grep total
101M total
mjc@325i:~/scratch/php-src$ mkdir foo; cp -r .cvsignore .gdbinit * foo; du -hc .cvsignore .gdbinit * | grep total
cp: cannot copy a directory, `foo', into itself, `foo/foo'
cp: cannot copy a directory, `foo', into itself, `foo/foo'
cp: cannot copy a directory, `foo', into itself, `foo/foo'
207M total

Now, lets commit those changes and then switch to php6

mjc@325i:~/scratch/php-src$ time (git add foo && git commit -qam 'double the size of the repo, this is a big diff' && git checkout master)
Previous HEAD position was de6576c... double the size of the repo, this is a big diff
Switched to branch "master"
real 0m9.907s
user 0m3.376s
sys 0m0.900s

twice the size, and barely 1 second slower, most of which is spent committing the changes.

Is this enough of a real-world, but marginally excessive example, or what?

Also – the whole revision history for php is in .git – and it clocks in at (as of this writing) 119MB (only 18MB more than the actual checked-out source) with 54,304 commits.

Feel free to let me know in the comments if I missed anything.

  • Share/Bookmark

Tags: , , , , , , , , , , , , , ,

Bad Behavior has blocked 247 access attempts in the last 7 days.

Blog performance enhanced by PHP Speedy Blog performance enhanced by PHP Speedy