Optimization tip for GFY (enhanced loading time)

[Ace of Babes]

This tip is originally from Google.

To make the pages load a lot faster all repeating images should be replaced by just 1 image + CSS code.

All smilies, all icons etc. should be on just one big image and the images should be placed with <div class="image_name"></div> code that will display the image as normally.

It will bring down the requests per page to the server from 50-100 to just 1-2. It will have a big impact on loading time at the user side and lessens the load on the server.

[rowan]

? how does that work? Do you specify a region of the big image to display?

[Michaelious]

sounds like a cool idea

[woj]

hmm, interesting, but does it actually work? I thought web browser caches the images, it's not like if the image is 50 times on a page it would download it 50 times....

[Azoy?]

hmm, interesting, but does it actually work? I thought web browser caches the images, it's not like if the image is 50 times on a page it would download it 50 times....

yeo that's what i thought.
it would work on initial view but afterwards it's all catched.

[Ace of Babes]

yeo that's what i thought.
it would work on initial view but afterwards it's all catched.

According to Google it is a big effort and its so easy to do and works in all browsers (the most basic CSS).

And not all browsers use caching that well or at all. It will save a lot of requests and requests add on loading time for the user.

The loading time experience will be enhanced the most.

The article is on google-code-updates @ blogspot

[Ace of Babes]

If you're a frequent visitor to code.google.com for product updates and reference materials for Google APIs you're working with, you might have noticed that the page loading time (or page rendering time depending on how you see it) has reduced in varying degrees in the past several weeks.

As you'll see below, we've made several changes to help reduce user-perceived latency. This is not an exhaustive list of all improvements we've made recently, but these are the major ones we've made.

As Steve Souders emphasizes as the "Performance Golden Rule" in his book High Performance Web Sites, "only 10-20&#37; of the end user response time is spent downloading the HTML document. The other 80-90% is spent downloading all the components in the page (p.5)".

We agree. That's why we focused our effort on reducing the number and size of downloads (HTTP requests) for the "components" throughout Google Code.

Combined and minimized JavaScript and CSS files used throughout the site

Downloading JavaScript and CSS files blocks rendering of the rest of the page. Thus, to reduce the number of HTTP requests made on the initial page load, we combined frequently-used JavaScript and CSS files into one file each. This technique has brought down 20 HTTP requests down to just 2. We also minimized the files by stripping out unnecessary whitespace and shortening function/variable names whenever possible.

Implemented CSS sprites for frequently-used images

There are 7 images prominently used throughout Google Code, including the Google Code logo, the googley balls at the bottom of every page, the plus and minus signs as well as the subscribe icon inside each blog gadget.

Although browsers usually download several images in parallel, we concatenated these images into one image so only one HTTP request would be made. Of course, concatenating several images into one required us to make several changes in HTML/CSS. For example, instead of having:

<img src="/images/plus.gif" />

We had to change it to:

<div style="background-image:url(/images/sprites.gif); background-position:-28px -246px; width:9px; height:9px">&amp;</div></span>

where sprites.gif is the concatenated image and background-position and width/height carefully calculated.

[Jon Clark - BANNED FOR LIFE]

I am sure gfy is already coded that way...

[GrouchyAdmin]

GFY already has enhanced loading time. It feels like it's on packet radio.

[Tempest]

I am sure gfy is already coded that way...

[Tempest]

Interesting idea. I already do the "whitespace" minimization on my CSS and javascript files and I tend to only ever use 1 of each instead of multiples...

The image thing is sort of cool... they've cut down from 7 connection and download requests to just the 1.. plus there's probably a bit of a size reduction as instead of having 7 image file headers there will be just 1. But before implementing it should be well thought out as you'll lose out on any SEO benifits from the alt tags of the images.

[TheDoc]

The amount of work it would take to do that within each unique post wouldn't be worth the effort. And shutting off images doesn't really speed gfy up much either.

The only way VB is going to speed up is to re-write the hundreds of stupid calls they have.

[Michaelious]

There must be some way of speeding it up though

[rowan]

Time to try sprites on a thumb TGP?

[GrouchyAdmin]

Time to try sprites on a thumb TGP?

Bitblt will totally change the industry.

[Tempest]

The amount of work it would take to do that within each unique post wouldn't be worth the effort. And shutting off images doesn't really speed gfy up much either.

A couple people turning off images isn't going to be noticeable.. BUT If they took all the common graphics that appear on every page/post and did that trick, that would be a LOT less server connection requests since it would effect everyone.

[nosey]

interesting

[rowan]

Gotta fix the backend before you shave 8.3&#37; off your load time by fiddling with images

[Ace of Babes]

Interesting idea. I already do the "whitespace" minimization on my CSS and javascript files and I tend to only ever use 1 of each instead of multiples...

The image thing is sort of cool... they've cut down from 7 connection and download requests to just the 1.. plus there's probably a bit of a size reduction as instead of having 7 image file headers there will be just 1. But before implementing it should be well thought out as you'll lose out on any SEO benifits from the alt tags of the images.

That's not true, you could use the text inside the div and position it out of sight using text-indent:-9999px; so that you will be able to describe the content of the image.

CSS designers almost all work that way, so I am sure it will be alowed by Google. Google also reads the <noscript> parts of your website.

[SayWhut]

Is 56k coming back in fashion or summat?????

[raven1083]

thanks for that great tip.

[testpie]

If you're a frequent visitor to code.google.com for product updates and reference materials for Google APIs you're working with, you might have noticed that the page loading time (or page rendering time depending on how you see it) has reduced in varying degrees in the past several weeks.

As you'll see below, we've made several changes to help reduce user-perceived latency. This is not an exhaustive list of all improvements we've made recently, but these are the major ones we've made.

As Steve Souders emphasizes as the "Performance Golden Rule" in his book High Performance Web Sites, "only 10-20% of the end user response time is spent downloading the HTML document. The other 80-90% is spent downloading all the components in the page (p.5)".

We agree. That's why we focused our effort on reducing the number and size of downloads (HTTP requests) for the "components" throughout Google Code.

Combined and minimized JavaScript and CSS files used throughout the site

Downloading JavaScript and CSS files blocks rendering of the rest of the page. Thus, to reduce the number of HTTP requests made on the initial page load, we combined frequently-used JavaScript and CSS files into one file each. This technique has brought down 20 HTTP requests down to just 2. We also minimized the files by stripping out unnecessary whitespace and shortening function/variable names whenever possible.

Implemented CSS sprites for frequently-used images

There are 7 images prominently used throughout Google Code, including the Google Code logo, the googley balls at the bottom of every page, the plus and minus signs as well as the subscribe icon inside each blog gadget.

Although browsers usually download several images in parallel, we concatenated these images into one image so only one HTTP request would be made. Of course, concatenating several images into one required us to make several changes in HTML/CSS. For example, instead of having:

<img src="/images/plus.gif" />

We had to change it to:

<div style="background-image:url(/images/sprites.gif); background-position:-28px -246px; width:9px; height:9px">&amp;</div></span>

where sprites.gif is the concatenated image and background-position and width/height carefully calculated.

Firstly, I wouldn't advocate that approach because of the problem of interoperability between different browsers of displaying elements in a relative way - from previous experience, having to work around IE's stupid box model was hellish enough, so why would I want to, as a designer, introduce more pain for myself?

As well as that, surely this concatenated image is simply going to be the size of all the sprites added together - but what if everyone only wants to use one sprite at, say, 130 bytes per sprite? For instance, your site has a total of 100 x 130 byte sprites for the user to choose from, making this concatenated image around 13 KB. Now, say 100 people load a thread page with 5 posts in, with each post having just 1 sprite - so each pageload, in sprite terms, causes 5 x 13 bytes = 65 bytes per user of bandwidth, which with 100 people's pageloads, causes around 6.34 KB of sprite bandwidth in total - verses one pageload from one user with the concatenated sprite causing over double that amount of 13 KB; 100 users pageloads with the concatenated sprite image would cause bandwidth to rocket to 100 x 13 = 1.26 MB.

As the above was just a small example, I'm sure it's easy enough to see how this idea scales poorly when more than 100 pageloads are concerned. Not to mention, of course, you said that most browsers don't cache properly; so why would they magically not cache the 130 byte sprite, but suddenly decide to cache the 13 KB concatenated sprite? They wouldn't - so each consequent pageload by the same user would require yet another request for a 13 KB image, which is going to be slower than a few requests for a 130 byte image.

And now to wait to be proven wrong - as always in life.

[morningstar]

Thanks for sharing that idea..

[Ace of Babes]

Firstly, I wouldn't advocate that approach because of the problem of interoperability between different browsers of displaying elements in a relative way - from previous experience, having to work around IE's stupid box model was hellish enough, so why would I want to, as a designer, introduce more pain for myself?

As well as that, surely this concatenated image is simply going to be the size of all the sprites added together - but what if everyone only wants to use one sprite at, say, 130 bytes per sprite? For instance, your site has a total of 100 x 130 byte sprites for the user to choose from, making this concatenated image around 13 KB. Now, say 100 people load a thread page with 5 posts in, with each post having just 1 sprite - so each pageload, in sprite terms, causes 5 x 13 bytes = 65 bytes per user of bandwidth, which with 100 people's pageloads, causes around 6.34 KB of sprite bandwidth in total - verses one pageload from one user with the concatenated sprite causing over double that amount of 13 KB; 100 users pageloads with the concatenated sprite image would cause bandwidth to rocket to 100 x 13 = 1.26 MB.

As the above was just a small example, I'm sure it's easy enough to see how this idea scales poorly when more than 100 pageloads are concerned. Not to mention, of course, you said that most browsers don't cache properly; so why would they magically not cache the 130 byte sprite, but suddenly decide to cache the 13 KB concatenated sprite? They wouldn't - so each consequent pageload by the same user would require yet another request for a 13 KB image, which is going to be slower than a few requests for a 130 byte image.

And now to wait to be proven wrong - as always in life.

This is pure plain CSS, nothing special. It has been possible in all browsers since the existence of CSS.

display:inline;width:100px;height:100px;background :...

That's it.

[Ace of Babes]

The amount of work it would take to do that within each unique post wouldn't be worth the effort. And shutting off images doesn't really speed gfy up much either.

The only way VB is going to speed up is to re-write the hundreds of stupid calls they have.

vBulletin uses templates so it will be easy. It would also be possible to write a simple PHP class for it in vBulletin plugins so you could specify the images in AdminCP and then replace the default image locations automaticly (saves a lot of work and easyer to manage).

[TheDoc]

vBulletin uses templates so it will be easy. It would also be possible to write a simple PHP class for it in vBulletin plugins so you could specify the images in AdminCP and then replace the default image locations automaticly (saves a lot of work and easyer to manage).

It's not easy if you have to write a simple php classes so the unique posts will display the icons the post templates.

That also won't work evenly in all browsers and it really won't speed anything up since the image calls isn't what slows gfy down.

[MattO]

There are messageboards using vB with shitloads more activity/users that run a lot faster than GFY and with lots of extra features, too.

[Fap]

i think if gfy gets rid of postingit will speed up too