5 Ways to Speed Up Your Site
Throughout the blogosphere I’m always seeing these blogs, that while they look great, are horribly slow and overburdened. Over the past few months I have become somewhat of a website optimization specialist, bringing my own site from an over 250kB homepage to its current 34kB. I will help you achieve some of the same success with a few, powerful tips. Most of these are common sense, but I can’t stress their importance enough. I will concentrate on the website and not the server in this article, as there are too many things to discuss when it comes to server optimization.
1) Reduce Overall Latency by Reducing HTTP Requests
Every HTTP request, or loading each item on your website, has an average round-trip latency of 0.2 seconds. So if your site is loading 20 items, regardless of whether they are stylesheets, images or scripts, that equates to 4 seconds in latency alone (on your average broadband connection). If you have a portion on your site with many images within it, such as your footer, you can reduce the number of HTTP requests with image maps. I discussed that in more depth at the end of this article. If you are using K2, you can get rid on one extra HTTP request by using one stylesheet, style.css, and no schemes (integrate what was in your scheme in the main stylesheet).
Don’t Rely on Other Sites!
If you have several components on your site loading from other websites, they are slowing you down. A bunch of HTTP requests from the same server is bad enough, but having HTTP requests from different servers has increased latency and can be critical to your site’s loading time if their server is down. For example, when the Yahoo! ads server was acting weird one day my site seemingly hesitated to load as it waited on the Yahoo! server before loading the rest of my content. Hence, I don’t run Yahoo! ads anymore. I don’t trust anyone else’s server and neither should you. The only thing on this site served on another is the FeedBurner counter.
2) Properly Save Your Images
One huge mistake people do is save their image in Photoshop the regular way. Photoshop has a “save for web” feature for a reason, use it. But that’s not enough. You must experiment with different settings and file formats. I’ve found that my header/footers fare well as either PNGs or GIFs. One major contributor to image size is the palette or number of colors used in the image. Gradients are pure evil when it comes to image size. Just changing the way my header text was formatted and replacing the gradient with a color overlay (or just reducing the opacity of the gradient) saved a few kilobytes. However, if you must keep your gradient you can experiment with the websnap feature which removes similar colors from the palette. But if you get carried away, it can make your image look horrible. Spend sometime in Photoshop, saving image for web with different settings. Once you have honed this skill, you can shave off many kilobytes throughout your site. Also, if you use the FeedBurner counter chicklet you can save roughly 2.1kB by opting to use the non-animated, static version.
3) Compression
Along with reducing HTTP requests comes decreasing the size of each request. We covered this case when it comes to images, but what about other aspects of the site? You can save a good deal of space by compressing the CSS, JS and PHP used on your site. Ordinarily compressing PHP wouldn’t do anything since it’s a server-side scripting language, but when it’s used to structure your site or blog, as it commonly is, compressing the PHP in the form of removing all whitespace can help out. If you run WordPress, you can save 20kB or more by enabling WP Admin » Options » Reading » WordPress should compress articles (gzip) if browsers ask for them. Keep in mind, however, that if you receive mass traffic one day you might want to disable that setting if your webhost gets easily ruffled with high CPU usage.
The problem with compressing any of your files is that it makes editing them a pain. That’s why I try to keep two versions of the same file, a compressed version and an uncompressed version. As for PHP compression, I generally go through the files by hand and remove any whitespace. When it comes to CSS, I usually do the same thing but have found CSS Tweak to be helpful when dealing with larger files. But do keep in mind that if you compress your main style.css for WordPress with default CSS Tweak settings, it will remove the comments at the top that setup the theme. Be sure to add that piece back after you’ve compressed it or WordPress won’t recognize your theme. When it comes to compressing JavaScript, this site has you covered. However, use the “crunch” feature as I’ve received weird results using “compress.”
Alternatively, you can check out my method of CSS compression utilizing PHP.
4) Avoid JavaScript Where Possible
In addition to adding HTTP requests and size to the site, the execution of the JavaScript (depends on what it does) can slow your site. Things like Live Search, Live Comments, Live Archives are tied to large JS files that like to keep your readers’ browsers busy. The less the better.
5) Strip Extraneous PHP/MySQL Calls
This step is probably only worth pursuing once you have completely exhausted the other tips. The K2 theme my site is vaguely based upon originally comes with support for many plugins and features, many of which I don’t use. By going through each file and removing the PHP calls for plugins I’m not using or features I don’t need, I can take some of the load off of the server. When it comes time to hit the frontpage of Digg or Slashdot, your server will more than thank you. Some aspects of this can be exemplified by hardcoding items where feasible. Things in code that don’t change in your installation such as the name of your blog or your feed or stylesheet location, can be hardcoded. In K2 these items rely on a WordPress PHP tag such as bloginfo. It’s hard to explain what sorts of things you can strip from your website’s PHP framework, but be on the lookout for things you don’t use on your site. For example, in the K2 comments file there is a PHP if else that looks to see if live comments are enabled and utilize them if so. Since I don’t use live comments, I can completely remove the if part and write it so that regular comments are always used.
Also, using too many WordPress plugins can be a bad thing, especially if those plugins are dependent on many MySQL commands which generally take much, much longer to execute than PHP and can slow a whole page down.
Miscellaneous Thoughts
Even if you don’t call on a piece of CSS that has an image, it is still loaded - so you might want to rethink using that one CSS selector that hardly gets called. When it comes to using a pre-made theme for your CMS, it’s a good idea to go through the CSS and look for things that aren’t used. For example, with K2 there was a bit of CSS defined for styling sub-pages. I don’t have any sub-pages so I removed that piece of CSS.
If your site is maintained using a CMS of some sort, you likely have several plugins, if not dozens, running behind the scenes. Going along with the theme of things, you will want to deactivate any plugins that aren’t mission critical. They use server resources and add to the PHP processing load.
As far as CSS compression on Wordpress goes, I use a great plugin called CSS Compress. You don’t need to touch your CSS file at all - it runs a PHP script which automatically outputs a whitespace-and-comment-free version of your stylesheet in the WordPress header file. Works a charm.
Regarding Tip 2, i’d recommend using Adobe ImageReady to optimize your images. There you can actually visually compare the original and the optimized version in terms of pixelation and file size to get the perfect compromise.
Oh, and by the way whenever you are creating a gradient one little tip i tend to use is set the CSS image to repeat across the X axis, and then create an image with an appropriate height but set the width to just 1 pixel. That way you are still getting the same gradient effect, but the image size is severly compressed.
I was talking about gradients within any image at all as they add many colors to the palette and increase image size, but it is also good to know how to use CSS to use small, repeating images.
Very nice list - I’ve been trying to speed up my site a lot, because my server seems to get slower and slower, and this article has helped.
RE: Michael
Photoshop does the exact same thing, you can do 2 up or 4 up when saving for web from photoshop. Image ready just brings it all together to output to html (which is heinous at times). For basic optimization, Photoshop works just fine.
As for the CSS - thats a given, same goes for rollover images. Personally, I HATE image maps. I would rather use 4 images, and then use css for the rollovers (using the blinds technique), versus an image map. Much easier, and much more accessible.
Other than that, some pretty basic stuff to speed up your site. My personal opinion is you can go to polar opposites. You can be overprogrammed and performance goes down, or you can be static - which in some cases is much more work, but the performance is excellent. There are MANY techniques out there to handle things like digg and slashdot. A cache server/repository, load balancing, gzip compression on content, opcode cache for PHP, etc. The list goes on. Truth is, its hard to have the performance working just from the page level. I think you get better control at the server level when working with optimization.
Thanks for the good article.
Ah yes, when the traffic gets hard, I usually enable the WP-Cache plugin.
The whole point of using image maps is to avoid those 3 extra image requests and just have one request to save on latency.
I completely understand the purpose of using image maps. This is why I gave the example that you can go extreme one way or another. Using image maps would be the quickest and easiest way. Using inline CSS would be quicker than linking to an external CSS file - but it defeats the purpose of pulling the CSS out of the presentation layer for updating. There are many things that could be done to speed things up, I just dont think all of them are beneficial. Why use images at all? you could just use text?
From a usability/accessibility perspective, I would much rather have an OL navigation with image rollovers/text than I would use an image map. Check the pages without images. Check the pages in a screen reader. Its a blur on accessibility, thats for sure.
So - I understand the point, I just dont think all things are beneficial and you can get carried away to make things lightning fast. This is why I would rather do most of the optimization on the server end with caching (images, html, css, database queries, etc) and other tricks then removing functional things.
I agree that much more performance can be gained by optimizing the server, however many bloggers remain on the cheaper shared servers where they do not have full-access to the server’s workings. I also forgot to mention one of the reasons why cutting down on the PHP calls helps so much, it’s because when you cut down a PHP call to see if a plugin is activated or something, that is generally associated with a database call which is the slowest of them all. You can cut down on database calls by reducing the number of plugins used as well.
RE: Paul
I definitely agree with the database calls. The least that should be done is turning on query caching (on EXACT queries). This is why I like to build custom systems. Many other out of the box pieces you have turn on / off certain features in a config file. Regardless of if it is on or off, the check must be made somewhere in the code. Not that conditional checks should be eliminated, but If I dont really NEED the feature at all - then why even worry about it. It is also one of the main reasons I dont do all of my config inside of a database table. Yes, its nice - but other options are out there (ini file, xml file, regular php file, etc) that do the same thing. Database just makes it easier for CMS’s and users who are not web developers and do not want to mess with the filesystem.
So - I dont want it to seem as though im disagreeing with you, because thats not the case at all. I just want others to explore different areas that are possible to maximize your speed as well. BUT, you are correct, for those on a smaller host/isp - the methods above would work.
Peace,
Nate
I’m not sure I understand the references to PHP in section 3. You seem to have several different ideas in this section. Running a whitespace stripper on Javascript files does help since every byte removed is a byte not sent to the client (along those lines: the Dojo javascript compressor actually can do safe rewriting of variable names to produce unreadable but signifigantly smaller files. (http://dojotoolkit.org/docs/compressor_system.html)). Removing whitespace from a php file, however, doesn’t reduce the size of the response, it merely reduces the size of the file the php parser has to load. This is a fairly small amount of overhead (all on the server) and if an opcode cache is running, it is a step that only has to be performed once as any subsequent loads will use the cached “compiled” version.
You mention that you can save a good deal of “space”, and if this refers to disk space I suppose it’s somewhat true. It doesn’t, however, reduce the size of the HTTP response so it’s really a different case than compressing css and javascript.
Finally you mention gzip compression, and this is a completely separate issue. I’m not familiar with WordPress, but many browsers accept gzip encoding nowadays. Essentially, instead of sending them the actual text, you send the text zipped. This means that the response is much smaller and so the page loads faster at the price of increased cpu usage by both the server and client (in practice a fairly minimal expense). This is not the same thing as storing text files on the server gzipped (although perhaps that’s what the Wordpress option does?). PHP also is capable of dynamically compressing it’s output by enabling the gzip output buffer in your code or setting a flag in your php.ini or .htaccess file (see http://php.net/zlib) and this can be a little processor intensive but will speed up page loads considerably for anyone using a modern browser.
Instead of trying to reduce the number of HTTP calls to improve speed, why not use HTTP caching instead?
take the stylesheet example. If you tell the client to cache the stylesheets, then they will request all three (6, 9 or whatever) only once. If you merge them all into one big stylesheet, and don’t allow caching, then the client is forced to download the one big stylesheet over, and over and over. The same goes with images and even Javascript. While you can’t do much about the client-side processing of Javascript, you can at least ensure that they only request it once or twice.
This solution is even better, it allows you to keep your CSS/Javascript in multiple files, which is easy for maintainability. As another benefit, if you do change a file the clients need only download the file that changed; not a massive monolithic CSS/JS file.
Food for thought.
Metapundit, I see where you’re coming from when it comes to removing whitespace in PHP, but with my theme for example, removing the whitespace affected the XHTML output it structured, therefore helping the file size.
>>Metapundit, I see where you’re coming from when it comes to removing whitespace in PHP, but with my theme for example, removing the whitespace affected the XHTML output it structured, therefore helping the file size.
Ah, and hence the response size would be smaller. Really, you’re removing whitespace from html, it just happens to be embedded in a .php file. I personally tend to separate my html and code using templates just so I can make sure my html is compact w/o degrading the readability of my code.
Slightly O/T, but if you did for some reason want to save disk space on php files, you could run them through “php -w” which strips whitespace and comments. With a large codebase that’s been commented for automatically generated api documentation this might generate substantial savings (see PEAR, for example, which tends to have more comments than code). This still doesn’t really affect the load time of your page, however.
Optimizing php and databases seems to be a little out of the scope of what most people using a wordpress installation on shared hosting can get into. Just following #1 and #2 would help most people.
Precisely. You hit it right on the nose. Thanks a lot for some of the info its insightful.
Dave
(metapundit said: Optimizing php and databases seems to be a little out of the scope of what most people using a wordpress installation on shared hosting can get into. Just following #1 and #2 would help most people.)
I agree- image formatting and being smart with the number of files you use are easy to implement- the other stuff is just WAY too nitpicky and complicated for most people.
well written though. :)
Paul,
Thankyou for taking the time to write this. Until I saw this article, It’d never crossed my mind to clean up the Wordpress/K2 code .. stupid brain ..
I’ve already begun, but in getting into some of the K2 stuff, the “cleaning up” morphed into “just add this little bit of coolness, and oh .. this one, and maybe another plugin .. oooohhhhh, i could write something ..”
Heh heh, you get the picture.
Cheers and Thanks again,
“The only thing on this site served on another is the FeedBurner counter.”
And multiple requests to the gravatar.com server right? ;-)
Hi Paul,
Nice article….
But even after tweaking, is there a method to find how much your site speed is restricted by the kind of hosting and by the type of publishing software you use ?
I found a web site analyzer to track the load time of the web page
http://www.websiteoptimization.com/services/analyze/
Pretty nice.. and gives detailed information.
Of late my blog at http://www.venukb.com/blog has become very slow. One reason is the amount of images I use in the blog (this is what i found by using the above website optimizer)
However I believe I am still constrained by wordpress ( I believe the DB queries in WP are not optimized) and also by my shared hosting. Definitely the hosting is not the one which can be tweaked, but I hope I can see some focus by WP developers on DB Query optimization.
Anyway thanks for the nice article, I am working on some of the points you have mentioned..
I liked this article very much. I have tried this way to speed up some of my sites and got success. You really pointed 5 nice ways. I have also added your blog to my favourite blog list (in my blog). This is because I got helpful things from here.
MA Razzaque Rupom
Output Caching is still the best way to speed up a site.
Having just somehow stumbled back onto this article, I’m just wondering does disabling Livesearch and AJAX commenting in K2 reduce load times? Aren’t the JS files still being loaded? I use a lot of graphics on my blog but that’s got to do with my content and I’m trying to reduce the massive load time by trimming down in other areas especially JS files.
Dont forget about caching non-dynamic files (js, css, images, favicon.ico, etc.)
There is a really nice article about doing this at http://www.askapache.com/2006/htaccess/speed-up-sites-with-htaccess-caching.html
Thanks………Let me try on my site to increase speed…if any qus i will get back to you
great tip with the images on photoshop
Awesome! I hope this post gets spread around the net, we would all benefit by implementing faster blogs and websites. Thanks!
You will also like reading about the 14 Top Methods for faster, speedier sites
Sorry for the typo in your name in my article, fixed now :)
I’m unable to speed up my site plzzzzzzzzzz help thanx !!!
If the center of attention of your site is text and if you have two or more columns and the text is in one of the column program CSS to display the text column first. The leftmost column doesn’t have to display first. The way it doesn’t really matter how long the rest of the site takes to load; the reader will be preoccupied with your content (if your content is interesting to the vistor).
One thing not mentioned is memory preasure on a webserver. Most servers host 100’s of websites & if yours is not one of the most popular then your code will not be in memory.
A popular method to get around this is to ping your web site. This will keep the site in the servers memory and keep your site responsive. I use a free service called Site Stalker (http://sitestalker.prestigedevgroup.com). They also collect stats on how often your site has outages and average response times.
This is a great way to measure improvement as your work on speeding up you site!
Very nice tips! If you are interested, I also wrote an article series on how to speed up a website using a cool Firefox add-on called YSlow. It will analyze many elements of your page including external Javascript calls, DNS calls, etc and give you a score. Very helpful for blogs.