I recently switched to one of these wireless service providers with a sort of pay-as-you-go model, and so now I’m (trying to be?) thriftier when it comes to the data I consume. Earlier today, as we wrapped up our cultural heritage project pitch websites and learned about mapping tools, the option I was recently given on my phone by the Google Maps application to download my area for navigation offline prompted me to take a step back and think about my team’s project website in terms of design choices, especially with regard to the cost of accessing it.
Providing some context: for the cultural heritage project, we thought of a smartphone application repackaging the audio tour mp3s at Stockholm’s Vasa Museum, currently available on their website, in order to streamline visitors’ audio tour experience. Beyond thinking about the means by which end-users would get ahold of the application (i.e., by streaming the audio, downloading all mp3s at once, or downloading them one by one during a tour), we did not get too much into the details of implementation, but the project pitch site can serve as a kind of placeholder for thinking about the implementation of cultural heritage projects.
First, the networking section of the Google Chrome developer tools provided some useful information about our project site. At its root, our site weighed 6.4 MB, and took 5.26 seconds to load on my home wireless network. The images, alone, accounted for 6.3 of the 6.4 MB. The larger one of the two images (4.3 MB) is hosted with GitHub here in the U.S. and took 513 milliseconds for the browser to retrieve; the smaller one (2.0 MB) took tens times as long (5.14 seconds) to retrieve from its server in Stockholm. Then, using Xcode’s Network Link Conditioner to simulate full network throughput and a latency of 500 milliseconds (about the latency of a satellite connection), I found that our site took 40.58 seconds to fully load in a browser in those conditions.