13 replies to this topic

[iamlost]

Ian Lurie, of (among other things) Conversation Marketing, wrote a very useful list on Search Engine Land for those wondering how to go about speeding up their websites, 29 Ways To Speed Up Your Website, 31-March-2011.
Note: for those who ask 'why bother?' he has a companion post on his blog with the question answering title: Fast pages convert 2x better, 31-March-2011.
His list (without elaboration - go read it, go print it out, GO!)

1. Put your images on a separate domain.

2. Or, just put your images on Flickr and use them as your separate domain.

3. Compress images using the right file type.

4. Resize images before you upload them.

5. Learn to write decent code.

6. Put your CSS in separate .css files, not embedded in each page.

7. Split up your CSS.

8. Learn to use CSS.

9. Put your javascript in .js files. Don’t put it embedded in each page.

10. Split up your javascript, same as you split up your CSS.

11. Defer javascript loading whenever possible.

12. Chuck the Flash. If you must use Flash, then use it only in small nuggets on the page.

13. Set up GZIP compression on your web server.

14. Minify everything: HTML, javascript and CSS. Save a non-minified copy of everything for editing purposes. way down.

15. Minimize redirects.

16. Fix canonicalization issues. ‘Fix’ does not mean ‘use rel=canonical’.

17. Invest in decent hosting.

18. Set up caching on your server.

19. Go static.

20. If you’re working in .NET, learn to compress the VIEWSTATE variable.

21. Correctly configure your server’s memory management.

22. Put your database on a separate server.

23. Learn to use JOINs.

24. Learn to use stored procedures.

25. Don’t use SSL unless you have to.

26. If you’re on Apache, load only the modules you need.

27. If you’re on Apache, learn to use AllowOverride, when you really need DNS lookup, and other tips like FastCGI.

28. If you’re on Internet Information Server (IIS), learn performance logging. Then learn your way through the fun, fun, world of IIS tuning.

29. Learn to use a server accelerator like Squid, or to use Apache or nginx as a caching proxy.

DO NOT blindly follow the above - treat it as a resource to research and UNDERSTAND why, where, and when certain actions might be appropriate for your circumstance.

To compliment and extend Ian's list:
* Best Practices for Speeding Up Your Web Site, 35 best practices in 7 categories from Yahoo! Developer Network.

To help pinpoint areas to improve:
* Yahoo! YSlow Firefox add-on for FireBug tool.

* Google Page Speed, the Web Performance Tool and Apache module.

[jonbey]

I spent some time running various tools to find ways of speeding my site up last year and one of the issues raised was to reduce DNS lookups. So images and databases on another server mean it would slow? Also, assuming that you follow step 17 first and get a faster server, why would using a seperate server for your database help?

And, if you minify, cache and static, then the database location, speed, size etc. all becomes meaningless doesn't it?

[iamlost]

Whether or not certain list points are necessary depends on site traffic volume per time period, graphics bandwidth, database call complexity/quantity, etc. As I mentioned: DO NOT follow list blindly. Many (perhaps most) sites do not require separate servers for images, databases, etc. - especially if they are on a dedicated server.

From the YDN link:

Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times. My guideline is to split these components across at least two but no more than four hostnames. This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.

BUT: that may or may not be applicable in any given situation. There is NO one size fits all solution.

Hypothetical example:
You have a site on a basic shared server. The traffic volume is slowing things down but it is cheaper to offload the image calls to Flickr than to upgrade to a dedicated server.

[FromScratch]

Here's a wrench

At what point does speed not make a difference with user interactivity? I mean do average users really notice the difference in miliseconds? Just a thought.

[iamlost]

I don't have links readily available but as the web has become 'normal' and broadband has become 'normal' people have become less tolerant of load time:
---1999: Zona found that 33% of visitors left if a page took more than 8-seconds to load.
---2006: Akamai found that 33% of visitors left if page took more than 4-seconds to load.
---2009: Akamai found that 40% of visitors left if page took more than 3-seconds to load.
Puts a new twist on bounce rate

---2006: Google found that offering 30-results per page (instead of 10) only added half a second to load time but caused a 20% traffic and ad revenue drop.

---2007: Amazon found that every 100-milliseconds of additional load time decreased sales by 1%. By linear extrapolation (not necessarily a correct assumption) that is a 10% sales loss for every additional second of load time.

There are lots of similar studies over the past 15+ years. Plus those investigating the psychological effects of slow response times on visitors.

Edited by iamlost, 02 April 2011 - 08:34 PM.

[A.N.Onym]

It's long been advised not to split up, but to combine CSS and JS files into less files to reduce the amount of HTTP requests. So you really need to know what you are doing, if you need to split them up. And yes, learn why you need to do it before doing it.

Edited by A.N.Onym, 03 April 2011 - 12:15 AM.

[AbleReach]

Yuri, does it depend on the css or js file? For instance, if you have something that will only load on the home page, why not make it separate? I feel the same way about print stylesheets.

It's interesting how some of what we do is based on hard facts, and some is based on how we interpret those facts.

On a separate note, these hard facts came my way via Twitter:
Google Page Speed Ratings One Year Later: News Sites Range from Up 27% to Down 73%

Last year in 25 Major News Sites Ranked by Page Speed I ran the Page Speed tool on the home page of a selection of online news sites including newspapers, magazines, TV sites, wire services and other news organizations.

Today I checked each of those home pages again and ranked the sites by improvement.

He's using Google's Page Speed rankings. Have you noticed that the Page Speed rank may not reflect the actual loading time? It scans for possible improvements. If Google is dipping another toe into influencing how sites are built, this time it's related to staying on top of best practices instead of ::shudder::: toolbar PR.

[A.N.Onym]

Yes, most likely, I'd put individual JS/CSS files for individual pages, if no other pages required them - that's obvious

The same could probably be related to legacy .htaccess files that may sit in one subfolder and redirect your old URLs, rather than putting that huge redirection code in the main .htaccess file (as convenient as it can be ).

Ironically, my own site uses plenty of JS that needs to be either deterred or put on separate pages.

Edited by A.N.Onym, 15 November 2011 - 04:46 AM.

[fullscale4me]

I too have gone through some speed testing. One area I found was social media icons being called in their widgets scripts. Hosting the script and the referenced icons really sped up some pages.

The other area I addressed was caching of images, css and javascript. On one site with a high amount of returning visitors (nightclub with bands on weekends) this saved a boatload of bandwidth (~25%).

[jonbey]

Yeah what slows me down is mostly:

Google Adsense
Social Media widgets
Some images
Words

My site is a lot slower than average but I am hoping that it is fast enough. My content loads before the sidebars and other stuff, so even though it can record 6-10 seconds to load some pages I think (hope) that for the average user it is OK as they see the words.

Feel free to shout "SLOW COACH" if my main site (Mutley) is too slow though!

[glyn]

Cheers,
Copy and paste straight into my database of useful tips

[A.N.Onym]

Joe, I think the current tolerable load delay is 3 seconds or less. Then again, your homepage does load pretty quickly, in about 2-3 seconds.

The size of text is comparatively small to the size of various JS widgets that load elsewhere. Text and HTML can load fast enough with static file caching. Do you use static file caching?

[jonbey]

I use caching on my WP blogs. I think that there is more I can do though, but not sure how / need to test. My server offers some sort of compression by always a bit worried about flicking switches on the server as I am never sure what these do!

[iamlost]

...always a bit worried about flicking switches on the server as I am never sure what these do!

One great reason to have a small test site. Puts the fun back into 'I wonder what happens if...'