Skip to content

Instantly share code, notes, and snippets.

@andrewk
Created February 10, 2014 03:16
Show Gist options
  • Save andrewk/8909787 to your computer and use it in GitHub Desktop.
Save andrewk/8909787 to your computer and use it in GitHub Desktop.
Notes on emergency.vic.gov.au/map performance for country users

Firstly thank you. FireReady and the emergency.vic site are an incredible resource, especially yesterday sitting here in the Macedon Ranges watching events unfold in Gisborne and considering when and where we might evacuate. So to everyone involved, thank you and congratulations on delivering a rock-solid resource.

A couple of notes on the site and why I pointed people to the text version...

Cold Cache Tests

While the server response has remained fast, that's only the start of the loading as the JS fires and brings in all the map tiles etc. Right now over my iinet ADSL1 connection 1.2km from the centre of Kyneton (Telstra infastructure), the page response has finished in 786ms, but the page takes 15.07 seconds to finish loading resources, the last of which are all the map tiles. Most of these map tiles are pre-loads by Google, with all the tiles in view finishing within 7 seconds. 90 requests in total. The memory heap for this page was 43.8mb (Chrome 32, OSX)

For the text version, reponse loaded in 1.24 seconds, with 16 requests. On a purely server-centric comparison the map version is fast, but that's not how it feels to a user, as all those map tiles create distinct jankiness in interaction and are blockers initially. This page uses only 13.7mb of RAM.

Amazon have demonstrated that milliseconds cost customer spend, and for users of an emergency site who are quite possibly panicked (as my wife was yesterday), those milliseconds last an age. Plus there's the country stereotype of old computers (not so true of Tree Changers), terribly slow internet (YEP!), etc.

Possible Improvements

The only obvious thing I could see to improve user experience would be to cookie the LONG/LAT and zoom level of the last area viewed. This would get them right where they want to be looking without mouse interaction or wasted requests/bandwidth loading extraneous map tiles. Doing this would greatly minimise the time between hitting the URL and achieving what they likely set out to accomplish.

A little unfortunate to see 7kb of uncompressed CSS in the page (easily minifies to 5kb, btw), but as you pointed out page load is not an issue.

I would have liked to investigate why there is a setInterval in the site's JS with such a rapid fire rate and whether the functionality would be better served by requestAnimationFrame, but I'm at home sick with a sick baby to look after. Definitely check that out next time there's JS work to be done on the site...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment