Hello,
I see a lot of room for improvement in Cemetech's server load and client loading speed. It loads relatively fast, but you could make it much faster with minimal effort. Here's a couple things you could try:
* You can compress your HTML output with this
* Your CSS has lots of comments in it, and it's separated over many lines. This CSS:

Code:

Could become this CSS with identical functionality and a much smaller size:

Code:

* You can also compress images, which is where you'll see the largest speed gain. I ran the home page through an image compressor and got the combined size of all images down to 75% of their original sizes. Puny PNG will be able to significantly reduce the size of PNG, GIF, and JPG files.
* Reduce the size of your javascript. toggle_display.js could be a lot smaller, for instance. It's first function could go from this:

Code:

to this:

Code:

You can use Javascript Compressor for this.

There's no real gain. The site is coded as such so it's easy to modify. It's easier to read lines of intended code with comments than one line of consolidated code.

Indented code is significantly easier to follow and debug, and thus you'll save time adding and editing functions/features over a consolidated line.

Personally, it helped me code C6M. Knowing what applied to what in the CSS helped me decide if it's something I should included in the mobile site; for the most part it's built from the ground up with influences from Cemetech6.

It might be worth, in the future, to have some sort of deployment pattern, though. So that code is as it is on the editing side, but then once you go to actually deploy the site it runs the CSS and JS through minifiers and such.

Along the lines of what merthsoft said, a lot of websites have a dev version full of comments and whitespace and such, and a release version that is minified. Google does this, for example.

That would be a great idea. Unfortunately, I don't maintain separate dev and production sites for something on this scale, even though it would be a best-practice. You were mentioning things about compressing images to save dozens of killobytes as well?

Silly me and my failure to read carefully. Thanks for that, I'll definitely give it a try. And I might as well go through and do some stripping of commented-out defunct code in my headers.

Good luck, hope it makes a nice difference.

Cheers, I hope so too. I've gone through and done a lot of optimization in SourceCoder as well, since I'm adding Prizm support.

Nice, Prizm support will be especially welcome for me.
Also, you could probably find a good use for ImageMagick and write a script to automatically compress all the images on the server.

"a lot smaller"? Not really. You are falling into the trap of confusing visual length with file size. Removing all those line breaks saves a whopping 14 bytes and has *zero impact on page load times*.

You are also wasting time "compressing" files that are cached anyway. Don't optimize what isn't the bottleneck.

There are other, far more impactful optimizations available. A big one is using things like sprites to avoid multiple image requests (ditto for combining CSS and JS files together). Number of requests is far more impactful than the size of any particular request.

Well, it may save 14 bytes for this function, but there is a lot of Javascript in Cemetech.net's source. It also won't be cached for first time visitors.

Because cemetech has tons of those, right?

Again, don't optimize what isn't a bottleneck.

That said, Kerm should definitely be using some of the minifiers out there, and have a dev/production separation (even if it isn't on a different server)