FILLER

T H I N Δ I R


×
About

Background

Initially, the approach was to leverage existing functionality provided by the various cloud services used to backend Thin Air. This would include:

However, it became quickly apparant that, in addition to lack of flexibility, using these products comes with a performance penalty. In particular when accessing via a mobile device such as a smartphone over a lower bandwith / higher latency network such as 3G GPRS. The only solution to this problem was to provide a similar corresponding service. The first place to start is with the Photo Album function as it is the most commonly used and therefore has the potential for the largest Return On Investment of effort. To be clear, this only applies to the front end User Interface (UI); the backend storage for each of these services will still be used.

Summary

Creating a Thin Air Photo Album function resulted in the following overall application performance improvement as follows:

DOM
HTTP Data Content
Requests Transfer Loaded
89.29% 94.57% 84.29%

For reference, a 50% performance increase is the same as 2X faster or 2X less storage. Tests were done after clearing cached data in the browser.

In addition, a significant side benefit is that the Thin Air Photo Album works on browsers without Javascript - Google + does not.

Methodology

Similar to the changes made for overall Thin Air web site performance improvements, HTTP Requests are measured in number of requests and Data Transfered is measured in KB. DOM Content Loaded is measured in milliseconds (ms) and is therefore significantly affected by network performance. Measurements were taken by throttling the network via Google Chrome DevTools. The data on the left is for the Thin Air Album function with full network bandwidth accessed via WiFi while the data on the right was produced by artificially throttling the network back to GPRS (50 Kbps) speeds.

WiFi GPRS
G+ 2450 ms 90.00 s
TA 385 ms 1.25 s
84.29% 86.11%

Note this test did not include the download time for photos. It focused on the initial page view - the time it takes for something to display. Users will appreciate a reduction in inital page load time from over 1 minute to just over 1 second!

Notes

Performance direction and guidance can be found in the following excellent Google Web Developer resources:

In addition, Google Chrome DevTools were invaluable to capture performance data.

Number of HTTP Requests, data transfered in KB and DOMContentLoaded event timer in milliseconds were easily measured using a "before and after" approach. Other data, such as number of render-blocking JS & CSS resources and overall mobile/desktop speed and UI scores reported from Insights were captured and used to identify performance opportunities. The data shown was captured from DevTools.

Conclusion

Assessment of functionality provided by cloud vendors is challenging. Many things need to be considered such as time/effort saved, functionality provided and configuration flexibilty. In this particular case, it made sense to "Build vs Buy".

Hikes

Statistics

Favorites

YouTube

Garmin