I think that'd actually be slower if it means you have to do the drawing on JavaScript (vs. the browser's native rendering engine). As a rule of thumb, anything on an interpreted JS engine (not Chrome or FF3.5) runs about 1000 times slower than the equivalent C.
The way I'd do it is create a bunch of large tiles (like the size of Google Maps) and pre-draw all the sprites onto a single tile. Put those tiles into a single container div that is bigger than its container, positioned absolutely, and clipped with overflow:hidden. When the world scrolls, simply change the positioning of the container. If it scrolls far enough that you need to render another tile, drop the one off-screen and pre-render its replacement on the other side, so if the user scrolls even more, the images are waiting for them. Much like how G!Maps does it.
This offloads the graphics work onto the C++ rendering engine, which has been tuned for this sort of stuff. Doing it in JS is just asking for trouble.
That might only work for the map though. I wouldn't want to have to download a pre-rendered tile every time that I moved a unit. It would make more sense to just pre-render the map tiles, and possibly the city tiles. Then the units would still have to be downloaded to the client and drawn on top of the map.
The same goes for changes that occur to the map (at least changes within the current view). Map tile improvements would be a pain if you had to download a section of the map just to update a single tile. It would probably make sense to have the sprites on-hand to update the currently viewed map section, and have it automatically added to future pre-rendered tile updates. This way you wouldn't have to download the map you already have to see the improvement, but when you downloaded future sections (or even come back to the current section) it will be part of the pre-rendered section.
All of this is disregarding whether or not there is a mode to show the map without improvements on it (IIRC, there was an option like this in Civ2). Then you might have to change these design decisions to accommodate that unless you're ok with the user needed to re-download all map sections whenever that options is flipped on/off.
Oh, by pre-rendering, I meant using DHTML, not images. Each tile is a div. On the div, you draw a bunch of absolutely-positioned divs (sprites) with transparent PNGs for backgrounds. The sprites themselves are layered, i.e. you'd draw a bunch of divs with background images for terrain, then you'd draw resources at a higher z-index, then you'd draw cities, then you'd draw units, etc.
The reason for pre-rendering DHTML-based tiles is because a.) you have to worry about download times for the sprite images, though hopefully you can pay this once and have them cached forever and b.) it takes a fair bit of CPU to create lots of DOM elements and move them to the correct positions. Less than blitting an image to canvas, but more than just changing the top and left of a container div.
The way I'd do it is create a bunch of large tiles (like the size of Google Maps) and pre-draw all the sprites onto a single tile. Put those tiles into a single container div that is bigger than its container, positioned absolutely, and clipped with overflow:hidden. When the world scrolls, simply change the positioning of the container. If it scrolls far enough that you need to render another tile, drop the one off-screen and pre-render its replacement on the other side, so if the user scrolls even more, the images are waiting for them. Much like how G!Maps does it.
This offloads the graphics work onto the C++ rendering engine, which has been tuned for this sort of stuff. Doing it in JS is just asking for trouble.