I've noticed the site is somewhat slow compared to TOS at times.  Including loading the player, taking turns, etc. 

I'm wondering aloud here I guess.  While I appreciate and enjoy the 1MB limit on file sizes I think we may be able to cut down significantly on bandwidth usage and therefore speed up the site as a whole by using proper file types, compression and transparency techniques.

As an example I will use my Wargate SG-1 map that's as yet unreleased.  I made the board completely in photoshop.  When I save the board layer as a PNG-24 with full transparency it is a hefty 1.16MB.  If I take that PNG-24 image and using Adobe Fireworks and save it as a PNG-8 using Alpha Transparency the file size goes all the way down to 402KB.

Something as simple as saving in the right format and using the correct transparency setting with practically no loss to image quality saves over 700KB of space.

I can only imagine what effect this might have on the bandwidth usage and overall speed of the site if all the maps on the site were similarly formatted.

This of course doesn't take into account anything that tom may be doing on the backend to compress images.  Maybe a weigh in here?

Anyway, discuss!

I and many map-makers here use paint.net.  I don't know what other users of paint.net do, but every one of my uploaded files is 8 bit PNG.  It's just a habit I got into when I made maps on ToS. My guess is a lot of map-makers here make PNG-8 maps.

And that may be the case. If so then the site is just slow.

Though I would be curious to see just how many maps are in PNG8 and how many are not.

This is more of a "hey this is how I do it is anyone else doing the same?" type of thing..

I confess that I simply save in PNG, and as long as it's under 1mb I've been satisfied (closes is my Holy Land at 988kb) :). I've noticed the delays/lag but I honestly haven't been able to identify if the slowness is really a product of board file size or if the number of territories/borders/continents play a bigger role, or if it's just site slowness at times. I really think I've seen the slowness on boards with lower file size which is why I'm not completing convinced it's file size.

If someone does have compelling evidence or tom definitely says file size is playing a significant factor then I'll be more than happy to go back through my boards and attempt to decrease the size (without losing quality). But I would like to see an increase in performance :).

Part of the slowness is because the maps can be multiple layers, and the board images (as well as the XML data that go with them) are generated every time via PHP. This means your browser is not caching any of the images.

Ultimately though I think the database is the bottleneck most of the time. I have nothing to base this on other than tom stating at various times that he's added an index here and there in response to previous slowness complaints, and also my various pokings around within the site seem to indicate that almost all content requires a database hit to serve up.

Please note I'm not complaining, I'd rather have working with occasional slowness than fast busted-ass.

Here's what you have to consider. Every visitor to the site is loading maps, taking turns, viewing boards, etc. Every time they load a map it uses up the available bandwidth to the web server(s) that WG is running on. That is a finite amount of bandwidth. Lag/delays would manifest as everything from loading the page to taking turns to everything if the finite amount of bandwidth were being used up.

As another example I just took a quick look at the new Titans of Italy board. The board image for it is almost 800KB and it's saved as PNG24. I copied it and saved it into PNG8 and it went down to 167KB. The quality in that particular case took a minor hit. Some of the smoothing took a hit between territories, however I think it's a small price to pay for speed.

Although the database may be the bottleneck you have to think it would ultimately run faster overall if the images being dynamically served up were smaller right?

I'm not saying by any means to lower the 1MB limit. I like it.. But if on most maps we could cut the size by half or more and not lose any image quality i think it might help.

There's  definitely a correlation between # of borders and download time..  Try loading this puppy, which only has a few thousand fog lifting borders in addition to the regular borders.

http://www.wargear.net/games/player/24731

Yeah there's something with number of borders/continents for sure.

Viper wrote:

I'm not saying by any means to lower the 1MB limit. I like it.. But if on most maps we could cut the size by half or more and not lose any image quality i think it might help.

I have to say that this was one brilliant move at ToS even though you guys always mocked it. The actual limit was much higher than the documented limit, which for the most part meant that the only people that knew how big a file you could actually use were mostly people who were already knowledgeable/responsible enough not to use the full size if they didn't have to.

I'm actually not seeing many performance issues in the server logs at the moment - it seems to be holding up well. However I'd certainly expect the larger boards to take longer to load - that one in M57's post has 5000+ borders so the total size for the board XML is 1.3MB.

The board XML file has to be encoded on the server, sent over the net to the browser and then decoded in the Player which all takes time.

Board images themselves should be cached by the browser as they are not marked as non-cached files. Incidentally the hosting package I have for WarGear has a huge monthly bandwidth limit which we are not even close to hitting. As 11s says, the site is basically database constrained for speed and for that read CPU power and memory.

Perhaps there should be hard limits to protect server performance and also the perception of the site as being responsive - but I'd rather Designers moderated themselves.

Edit: Hold the phone... I have just enable gzip compression of XML files on the server, that 1.3MB file shrank to 56kB (!) So there's still the compute time at each end but the data transmission amount has been slashed.

Agree with slowness, and with the reasons why.