Suggestions to improve your site speed on GWT?

[AlexB77]

I would like to post few questions that most definitely bothers most of us here and very much would like to listen to all of the suggestions and any advise that we can all hopefully can benefit from.

Here is what I have:

1. What would you suggest to do if your average site speed is lower than 80% of the sites.
1.1 Would you recommend to use CMS
1.2 Would you suggest any special techniques such as php includes for static pages or site menus , headers and footers.
1.3 Changing your server or optimizing an old server.

2. Proper internal linking and how it can affect your page speed.
3. Optimizing Images or using colored backgrounds instead, where appropriate.
4. Javascript on the page and your thoughts about how to defer parsing of JavaScript of an external scripts.

I can go on and on and on, but would be nice to have your opinion or your questions.

[freejung]

I've been doing a bit of work with speed optimization lately - I still have a lot of work to do on my hobby site, but my business site is pretty tight with regards to speed. Here's some thoughts:

1. speed it up! (sorry, couldn't resist)

1.1 I always recommend MODX, it rules. If you do use a CMS, make sure to implement some sort of caching. Wordpress, for example, has caching plugins. MODX of course does awesome caching by default. Cache everything you possibly can. If a resource absolutely has to be loaded uncached (because it's genuinely dynamic on the server side), I would recommend putting it at a separate URL from the main page and loading it with AJAX after the page loads.

1.2 No. Any server-side processing before page load will slow you down. Whenever possible, output static content and cache it. A good CMS (e.g. MODX) will take care of templating for you and cache the results.

1.3 That depends on whether that's what's slowing you down. Use one of the many web page test tools out there and see how long the initial response of the server takes. It is entirely possible that the server responds very fast and your slow speed is totally due to other factors.

2. I'm not clear how internal linking is relevant, perhaps this is something I don't know about.

3. Definitely optimize all of your images. There are free tools to do that. It can make a huge difference. More importantly implement CSS sprites wherever possible to reduce HTTP requests. If you have a lot of images, that's probably the single biggest win you can get. I've been thinking about writing a MODX addon to dynamically generate CSS sprites for all images on a page, I think that's by far the best thing I could do to improve my own speed at this point.

4. Load JavaScript asynchronously whenever possible. If you're using external scripts and your internal scripts depend on them, this can be difficult as you have to deal with dependencies. Rather than deal with that, I just put all of my scripts (including jquery, for example) in a single JS file and load that asynchronously, that seems to work very well. Make sure you combine, minify and gzip your JS (and your CSS for that matter).

Also, if you serve a lot of images and/or rich media, consider putting them on a CDN.

[freejung]

Oh, another thought: if you have social media buttons, other third party widgets, large elements below the fold, or anything else that loads slowly and doesn't have to be there when the page loads, use JS to add it to the page after the window onload event.

[AlexB77]

Thanks freejung,

I think this is good to start with, but would also wait for more answers.

2. I'm not clear how internal linking is relevant, perhaps this is something I don't know about.

I meant the use of php includes for internal linking.

Also I personally think that some of us would still prefer writing pages manually instead of implementing CMS in place.

I run 4 different sites 3 of which are written in dreamviewer, without use of any CMS, but simply with use of dreamviewer template.

[deadsea]

Instead of using sprites, has anybody experimented with data: uri scheme images to embed the image data directly in the html source code?

[en.wikipedia.org...]

I have a set of pages with a bunch of icon sized images on them. I think it might work pretty well for that if I did a fallback for IE 7.

[Sgt_Kickaxe]

My 2 cents to make a site load MUCH more quickly.

- Removal of all adsense, or at least all units with low CTR if you can't for financial reasons.
- Removal of 3rd party javascript based tracking such as Analytics.
- Removal of widgets and products such as the Google search box (again, 3rd party javascript).

Those three alone, if they were present before, will speed up the site by seconds, not milliseconds. Then continue with...

- Fewer, and more optimized, images within articles
- Less template bloat, no template images beyond perhaps a small logo
- Fewer widgets and gizmos and plugins, each takes time and ANY can jam a visitor.
- Optimize code, reduce size of htaccess, reduce size of html (minify it but also get rid of tables, on page css, etc.
- Condense, combine and reuse css into a single efficient css file.
- Activate gzip or similar compression sitewide, for images and content.
- Make sure your site returns proper headers and expires tags to make 2nd loads instant from browser cache with zero demand on server.

There's more but by now you're top 50%, assuming you're not using the cheapest of shared hosting. If you ARE using extremely cheap shared hosting your time to first byte will be slow leaving your site behind out of the gate, consider upgrading to a virtual dedicated server, at least.

[robzilla]

Instead of using sprites, has anybody experimented with data: uri scheme images to embed the image data directly in the html source code?

I've been using these for some time now -- not instead of sprites, however, but combined with them. Whether you should use the technique in your HTML source code really depends on the intended use of the images. Not sure if the images are indexed by Google, but I doubt it. It works very well within CSS files. The site on which I've implemented this most aggressively tends to stay below the 0.5 second line in GWT, despite the fact that it also loads Google Analytics.

Just make sure you gzip your HTML and/or CSS files, or you lose the benefits of image compression.

[deadsea]

Thanks, rob. I don't care if these images are indexed for image search or not. They are very small and used on many different sites. I had to enable mod-gzip a few years ago to avoid bandwidth overages, so I'm all set there. I think I'll give it a go.

Your css approach is worth considering. I could put all the images into the css file:
#image1 { background: #fff url(data:image/gif;base64,abc...
#image2 { background: #fff url(data:image/gif;base64,def...
Then I wouldn't have to worry about my server having to look up the images to embed them. I'll see how big that css file would end up being.

[robzilla]

On the site I mentioned, each and every graphical element, from the logo to dozens of icons, is contained within one of several sprites (you can't always get them all in one sprite unfortunately) and embedded into the CSS file with the base64 scheme. Total size is around 28KB, served compressed as 14KB. If I didn't have Google Analytics, each initial pageview would require just two HTTP requests, and just one(!) for every subsequent pageview (the CSS file is cached for a year).

Also, I'd recommend using PNG instead of GIF for better compression, among other benefits. See W3C [w3.org].

[deadsea]

I do use png, the site I found an example on uses gifs.

I think putting them all into one css file is to much. Its 98k (compressed down to 40k). I have about 200 icons and each page uses between 2 and 20 of them (with lots of different combinations). I'm going to try them out in the page source and see how that does.

[smithaa02]

Does GWT count non-content elements (javascript/images/flash) for load time?

We know load-time is important now for SEO, but is this load time for google bot to grab the html or load time for a user to download all the image and process the flash/javascript files?

[londrum]

are you on a shared server? i was and i was around 80-70% too, the same as you. i managed to knock off maybe 10-15%, using all the stuff listed above, but it wasn't until i moved to a dedicated server that i got it under 50%. you can knock off 30-40% with that alone.

... one other thing that hasn't been mentioned yet... you can also cache your database queries, as well as caching your page output

[deadsea]

Does GWT count non-content elements (javascript/images/flash) for load time?

Webmaster tools has two sections that show site performance:

• Crawl stats under diagnostics. This is the how googlebot perceives your site. It does not include external images, css, or javoscript. The graph for my largest site shows that googlebot currently spends about 200ms downloading each page on average.
  
• Site performance under labs. This shows how users with the google toolbar perceive your site. It includes any external resources that are downloaded with the page. The graph for my largest site is currently showing around 3s per page on average.
  

[freejung]

Also I personally think that some of us would still prefer writing pages manually instead of implementing CMS in place.

From a speed perspective, I don't see anything wrong with that. Static HTML files should load at least as fast as anything a CMS can do. The only way I know of to get the server response even faster is to implement memcached - that caches your static HTML in RAM.

If you're currently using static HTML and the code is not horribly bloated, serving the HTML is probably not what's slowing you down.

has anybody experimented with data: uri scheme images

That's a really interesting idea, I'll have to try it out. One thing I would watch out for with this, though, is that the initial page load occupies the entire connection -- nothing else can load until it's done -- so if you make it too big you might actually end up slowing yourself down vs. using sprites. Definitely worth a try though, it might work very well for all of the little images (corners and stuff) that tend to be part of templates.

you can also cache your database queries

Yep, MODX does that too, I'm not sure about other CMS. It's still faster to cache static output, but if you are using dynamic resources, caching the queries can be a good way to speed them up.

[freejung]

Oh, yeah...

Removal of ...

Very good points of course, I just assumed we were talking about how to speed up a site without changing its design or functionality. Obviously the fastest possible site will be straight static HTML with no images, javascript, or third party elements of any kind. The closer you can get to that, the faster your site will be. However, there's only so much functionality I'm willing to give up for speed.

[tedster]

While CSS sprites can do a lot by minimizing http requests, a lot of sites ignore a more basic speed gain with images - making sure that images are compressed as well as they can be in the first place. Many times today, the person creating the images has no attention on file size whatsoever.

The JPG format can very often be compressed to a 40% level with Photoshop's "Save for the web" option, and with no visible loss of quality on the monitor. And yet 80% levels (or even 100% levels!) are very common.

The GIF format can often work well with only 16 colors in the color table - 32 on the outside. And the PNG format - well, the biggest waste here is using a 24-bit format. Rarely a good idea for online images, and it can triple the file size over an 8-bit PNG.

Photoshop's "Save for the web" has some very powerful algorithms today - they really work visual magic. And if you use Photoshop's regular "Save", you are also wasting some file size by embedding XML data in the file that isn't needed online at all.

[deadsea]

I got the image data uri stuff implemented. It is drastically cutting down the number of requests to my server. I also moved a css file and a js file inline. Page generation speed increased from 500ms to 700ms. Page size increased from 50k to 80k (uncompressed).

Next week I should be able to see what effect it has on the WMT page speed data.

[freejung]

I also moved a css file and a js file inline.

I'm not sure that's a good idea. The problem is, it may save on HTTP requests for the first pageview, but on subsequent pageviews they'll have to download the same data over and over. Unless your average pageviews per visitor is close to 1, I would go ahead and leave CSS and JS in separate files.

[deadsea]

The average pageviews on my site is 1.2. I aim for a 100% bounce rate by giving the user everything they need on the landing page.

[freejung]

Oh. Well, in that case go for it.

[robzilla]

If by now there remains only 1 local HTTP request, you could even consider turning off Keep-Alive -- that is, if your server could use the breathing space.

I aim for a 100% bounce rate by giving the user everything they need on the landing page.

Don't forget to take into account the percentage of return visits. And check your browser statistics: BASE64-encoded images aren't supported by IE 6 & 7.

[g1smd]

Site speed stats haven't been updated since mid July on sites I look at. Is that normal? I thought it used to update a couple of times per month.

[deadsea]

For MSIE version less than 8, I'm using regular image hrefs, not the data ones.

I still have one local js script called from each page. It is dynamic js. My pages have a cache timeout of a week, but that JS is 3 hours, so I don't want to integrate it. Also, the server handles several other of my sites, so I don't want to mess with the config.

I am seeing MSIE 8 and 9 occasionally request /data:image/png;base64,... uris from my server. It makes me think that later versions of IE don't support it as well as advertised, or that a crawler is spoofing as it (likely).

[freejung]

Site speed stats haven't been updated since mid July on sites I look at.

Odd. Mine updated Sep. 26.

[g1smd]

What was the previous update date?

[rhornsby]

Cut the crap, literally cut the crap out of your website. Get rid of bloated CSS and HTML, optimize images, create a static website to call resources from, etc. Basically, follow all the recommendations on Google Site Speed.

[robzilla]

Odd. Mine updated Sep. 26.

Same here. The previous update was around September 18-20, judging from the graph. The statistics do get "stuck" on occasion, but so far that's never taken longer than, say, 2 or 3 weeks. Sometimes they're updated daily. It depends on the available data points, and it's probably a low-priority task in Google's system.

[memario]

If my site has for example 3 menus: "home" "online-shop" "contact"
And if there are images/icons etc. in online-shop and contact that are not shown in the home page, I don't put them in the sprite. I make home_sprite.png, online-shop_sprite.png and contact_sprite.png
I use DATA images only for those that can't be added to the sprite (like repeated 1px backgrounds). Mostly because that when converted to DATA img, the data symbols in most cases turns out bigger in KB size.
Not always but sprites in which elements are arranged side by side, making the sprite image horizontally longer, it turns out smaller on KB size then the vertically arranged ones (but the best is to keep the square shape if the elements in the sprite allows it).
I also compile my JS files in one major JS file.
My firebug Pagespeed gives me 98/100 and the 2 missing points comes from the google analytics js file, which has short freshness lifetime.

[Zivush]

My firebug Pagespeed gives me 98/100 and the 2 missing points comes from the google analytics js file, which has short freshness lifetime.

Do you use G analytics asynchronous tracking code?
see [googlecode.blogspot.com ]

[memario]

Yes, but its not a asynchronous problem, it's "Leverage browser caching":
The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources:
* [google-analytics.com...] (2 hours)