Bandwidth optimizations

[Perun]

Great way to optimize bandwidth is rather obvious: compression!

Did you know that both PHP and ASP support compressed delivery of content to a browser?

Only thing you need is a browser that supports content compression. I bet all modern browsers fall into that category!

Will look in PHP documentation about this...

[Perun]

I've manually edited sample output of midnight_main.php and these are my results and observations:

• unnecessary whitespace should be removed wherever possible. Perfect code readability isn't necessity for players. Some kilobytes can be saved that way without too few whitespace.
  
• classes, names and ids are waaay to long. They should be shortened wherever possible.
  
• there are still some dead code (empty <td> tags, for example). It should be removed.
  
• server-side image creation should be used. Few kilobytes can be gained that way by simply removing all this image layering.
  
• there are some styles outside CSS lying in the page. These should be removed and placed into CSS file
  
• similar JavaScript code should be placed in one place, replaced with function wrappers and removed from event handlers like onclick
  
• there is no need for absolute URLs. Relative should be used wherever applicable
  
• tag attributes which can be placed inside CSS should be removed and placed inside their respective CSS classes wherever possible (align, width, etc.)
  

All this can reduce the file by almost 40%, if not more.

[Perun]

As I suspected, compression in PHP is quite simple to implement.

See outcontrol function group to learn more.

Output buffering (if not already used) should also provide some speed improvements.

[Ringthane]

you're crazy!

[sparrowhawk]

Doh! I knew about file compression from ages ago, and had completely forgotten about it.

I'll take a look at it again and run a few tests on FireFox and IE.

I'll get Bill to try it out on Linux browsers too.

[sparrowhawk]

Perun said:

I've manually edited sample output of midnight_main.php and these are my results and observations:

• unnecessary whitespace should be removed wherever possible. Perfect code readability isn't necessity for players. Some kilobytes can be saved that way without too few whitespace.
  

Yes, I've been looking at this. Goes against my principles, but needs must!

[/li][li]classes, names and ids are waaay to long. They should be shortened wherever possible.
[/quote]
Again, against my principles! One thing that I have found working in large dev teams is that people like to use variables called a, pr, fg, etc. Meaningless and it causes loads of headaches for maintenance 6 months down the line. But maybe in this scenario, if the compression doesn't work...

[/li][li]there are still some dead code (empty <td> tags, for example). It should be removed.
[/quote]
I'll take a look. This is usually due to allow some specific formatting, such as right aligning to a particular point on the page. But will check.

[/li][li]server-side image creation should be used. Few kilobytes can be gained that way by simply removing all this image layering.
[/li][li]there are some styles outside CSS lying in the page. These should be removed and placed into CSS file
[/quote]
I'll see whether I can do that. Many are done on the fly, dynamically generated. But I could almost certainly build some cascaded classes for each type.

[/li][li]similar JavaScript code should be placed in one place, replaced with function wrappers and removed from event handlers like onclick
[/quote]
Yes, I was thinking the same thing and have actually started doing this. Good call.

[/li][li]there is no need for absolute URLs. Relative should be used wherever applicable
[/quote]
I'm not using any, other than the xml declarations, which are not "active links".

[/li][li]tag attributes which can be placed inside CSS should be removed and placed inside their respective CSS classes wherever possible (align, width, etc.)
[/quote]
Agree with you 100%. Just have never got around to it

[/li][/ul]

Thanks for going through the code

[Perun]

Brrrr. I'm rereading my post and am finding that I sound as a high school professor. Didn't mean to. Have to work on my writing skills. This is not a dissertation! ;D

[Perun]

Ringthane said:

you're crazy!

Why?

[Old Shendemiar]

Short and as undescriptive names for every stile class will make the file smaller.

Maybe splitting un-php parts to separate includes might get those small bits cached?

[Perun]

Let's wait til Jean-Yves tries compression. I think with it the bandwidth problem will be solved.

Btw, I really don't know why JY insists on layered images. It still is exploitable by people with slower connections (like me! ;D) or with talent to look into html source.

Clipping problems would be gone, partially even size problems, especially with new gfx style.

[Ringthane]

YES! The best of both worlds! Yes! Cream pie anyone?

[sparrowhawk]

Chris has just switched on compression at the apache end. In the end it was a 2 line addition to the .htaccess file.

We're just testing at the moment and should get a feel for it tomorrow after the stats are run.

But I will aslo look at reducing the size of the html anyway, to make it as efficient as possible

[Perun]

Just remembered:

I tried new graphics set.

It looks very good, but is slow as hell. Incredibly slow. So I switched back to regular graphics.

Can you send me new set, JY? I'd like to test that GD code with it. Please?

[sparrowhawk]

Sure will do.

It will be very slow at first since your browser is cahing each of the terrain images, at each depth.

Once it's cached, it's just as fast (seems to be anyway, for me)

[Perun]

Tried new set with gdtest.

Size rises rapidly up to even 11 kB. This can maybe be reduced by going to 8 bit per pixel.

How's compression going?