The Web for Under-Powered Mobile Devices: Lessons learned from Google Glass
The Web for Under-Powered Mobile Devices: Lessons learned from Google Glass
|UNSW & NICTA|
|Mohamed Ali Kaafar|
Web Browser, Performance, Google Glass
Over the past two decades, the web has changed significantly, evolving from basic webpages with hyperlinks to a substantially more complex ecosystem with dynamic webpages and dynamic content delivery models. While the web ecosystem has become complex, the devices accessing the web are becoming smaller, moving from desktop to tablets to smartphone and now wearables. The trade-off between ever increasing web complexity and gradual miniaturization of devices having limited processing capabilities and power posits an interesting question: How does the current web ecosystem impact the performance of underpowered devices? In this paper, we address this question by considering a popular smartglass: Google Glass.
Based on our experiments, the important results are:
WebP image format is more energy efficient than JPEG and PNG on Glass. For example, using WebP instead of JPEG on m.wikihow.com results in 45 % savings in power consumption and 50 % lower webpage load time.
The cost of accessing a website using HTTPS on Glass when compared to a smartphone increases with increasing number of web objects, webpage size and the number of servers accessed through the webpage. For instance, Glass power consumption is 27 % lower than smartphone for webpages with less than 64 web objects. However, the power consumption on Glass becomes 17 % higher to that of smartphone when loading webpages having more than 64 web objects.
Seven out of the 50 studied websites are optimized for content delivery to Glass. For example, m.espn.go.com optimize by serving images according to the Glass screen dimensions.
The rest of the paper is organised as follows. Section 2 discusses related work. Section 3 explains experimental setup. Performance results are discussed in Section 4. Section 5 concludes the paper.
Prior works have investigated the performance of web browser on desktop and smartphones from different perspectives such as caching, protocols and webpage content [6, 2], webpage complexity  and energy . In contrast, our major focus is, (a) to find out the web browsing performance issues on an underpowered device such as Glass and, (b) how today’s webpage complexity and design contribute to such issues.
Thiagarajan et al.  created a system to exclusively measure smartphone browser energy for popular websites based on their content. In contrast, our work measures browser performance along multiple metrics taking into account webpage complexity, webpage content and different application protocols. Qian et al.  suggested factors including protocol overhead, webpage content and caching affect resource utilization for mobile web browsing. We measured the impact of similar factors on Glass and smartphone browsers.
The experimental setup consists of a Google Glass, a Nexus 5 smartphone (Chrome browser 42.0) and a laptop. We also repeated the same set of experiments with Sasmung Galaxy S4 and Nexus 5X, and observed performance difference trends between Glass and the two smartphones to be similar to Nexus 5. For brevity, we only report results for Nexus 5. The laptop runs Mac OS X, has 8 GB of RAM and 2.6 GHz processor. Our experiments can be broadly divided into two categories: accessing real webpages on the Internet from Glass and smartphone, and accessing synthetic webpages hosted on a local Apache web server running on a laptop from Glass using WiFi. The synthetic webpages are created for two scenarios: (a) Hosting landing pages of websites that are considered for studying the impact of various web components on browser, and (b) Image format comparison experiments. Hosting webpages on a local server provides a way to control webpage content according to experimental needs. More details are presented in Section 4.2.1 and 4.2.3. Overall goals of our experiments is to study the impact of webpage complexity, individual web components and accessing webpages using different application layer protocols on the performance of Glass and smartphone browser and compare them.
We created an application for both Glass and smartphone, which invokes the browser with the website url to be accessed as an input. Browser cache is emptied before each experiment. We also developed a profiler app for both the devices. Profiler runs in the background and collects the following performance metrics every second and writes them to a file with timing information for later analysis:
Power consumption is obtained by multiplying the current and voltage readings obtained from current_now and voltage_now files present at /sys/class/power_supply/battery.
Glass device temperature is obtained by reading /sys/devices/platform/notle_pcb_sensor.0/
Downloaded bytes is obtained by using getUidRxBytes function from Android framework .
Webpage load time is measured from the time of first DNS request (start time) to the time when browser receives the last web object (end time). The profiler extracts the start and end time from the browser logs.
All the experiments are repeated six times and the results reported are averages unless stated otherwise. Each experiment is first performed on Glass and then on smartphone. The battery of the devices is fully charged. Glass is always allowed to cool down to around 37 °C before commencing experimentation. While taking measurements, only profiler, app to invoke the browser and the browser are running on the devices.
Figure \thefigure: Comparison of Web Browsing Performance
Our first experiment studies how the complexity of webpages affects the performance of Glass in comparison to a smartphone. The top categories of websites being accessed from Glass are media, entertainment, sports, news, informational and technology . We picked 50 popular websites (mentioned in Appendix) from Alexa Top 500 under the aforementioned categories. We found seven websites to be optimized for content delivery on Glass and are hence discussed separately in Section 4.4.
Figure \thefigure: Glass Browser Performance for Synthetic Landing Webpage of Websites
To conduct our experiments, we created a copy of the website landing pages on a local Apache web server (version 2.2.29). The local HTML copy allows us to systematically add or remove web components. The local server only contains a copy of website landing HTML page. All the web objects embedded inside the webpage are still served by the original servers. We chose to do so because modern websites are complex and have dynamic content, which makes it impractical to store each and every web object embedded inside the landing page on the local server.
We measured the energy consumption of PNG, JPEG and WebP image formats on Glass. A JPEG image of size 500 KB is chosen for the experiments. This JPEG image is then converted to smaller JPEG images and similar PNG and WebP images using cwebp . Each image is then embedded in a webpage (that contains only the image) on local Apache web server. Figure The Web for Under-Powered Mobile Devices: Lessons learned from Google Glass shows the results. The x-axis shows firstly the JPEG image size. The two numbers inside the bracket represent the corresponding size for PNG and WebP image. Study by Josh et al.  showed that depending on the quality comparison algorithm, the compression ratio between JPG and WebP image files can be less than or greater than one while maintaining the same quality of image at a particular JPEG level. On contrary, we do not exclusively focus on comparing the quality of the image. We choose a particular JPEG file size which is converted to a WebP image with a quality factor of 75 %.
Figure \thefigure: Comparison of HTTP vs HTTPS Performance
Our results suggest that the performance gap between JPEG and WebP increases with increasing image file size because at higher image sizes, WebP gives a better compression ratio that results in smaller WebP files and hence is the most energy efficient format. Hence, webpages can be embedded with WebP format instead of PNG or JPEG to achieve lower power consumption on under powered devices. As an example, converting all JPEG and PNG images to WebP provides savings of 20 % in power consumption and 33 % lower webpage load time for ted.com. Similar conversion on m.wikihow.com gives 45 % savings in power and 50 % lower webpage load time.
We measured the performance of HTTPS versus HTTP on Glass and compare it to a smartphone. Webpage load time is measured while accessing a website using HTTP and HTTPS and power consumption, temperature variation and downloaded bytes is calculated for the duration of the webpage load time. 18 out of 50 websites supported both HTTP and HTTPS. However, we could only compare results for 13 websites because two website loads less content on HTTPS than HTTP and three websites have been optimized for Glass. Similar to Section 4.1, relative performance (Glass/Smartphone) ratio is used to represent the results.
We did a correlation analysis similar to Section 4.1 and then binned websites based on the common highest correlated factor to depict the relative performance. The result is shown in Figure The Web for Under-Powered Mobile Devices: Lessons learned from Google Glass. Figure (a) shows that the number of web objects as the common factor among the top three factors for the three performance metrics: relative total power consumption, relative webpage load time, and temperature variation on Glass.
Figure (b)-(d) shows that the relative performance of Glass compared to a smartphone deteriorates with increasing number of web objects on a webpage. For the webpages with smaller number of web objects (<64), Glass webpage load time is 27 % higher than smartphone. However, Glass power consumption is 27 % lower than smartphone due to the lower rate of power consumption. With increased number of web objects (>64), we see 69 % higher webpage load time and 17 % higher power consumption on Glass compared to a smartphone. The cost of HTTPS can be attributed to the extra time to maintain and create HTTPS connections which increases with increasing number of web objects and the number of servers to contact. More time also leads to more power consumption and higher temperature on Glass.
Seven websites: m.espn.go.com, m.wikipedia.com, m.wikihow.com, goodreads.com, telegraph.co.uk, m.youtube.com, and mobile.bloomberg.com provide tailored content to Glass. The general methodology employed by these tailored websites is to deliver less content to Glass than smartphone. Next, we discuss specific features discovered by analyzing tcpdumps.
m.espn.go.com and m.wikipedia.com optimize by delivering the images to Glass browser according to the device screen dimensions which results in 50 % and 70 % reduction in image content download respectively. Considering the number of images on m.espn.go.com (35) and m.wikipedia.com (26), the reduction is considerable. Glass screen dimension (427*240) is smaller than Nexus 5 (640*360). Upon receiving request from any device, the server identifies the device type and its display properties, which is then used to send appropriate sized content to the device. Accessing m.wikipedia.com and m.wikihow.com on Glass fetches less php scripts than smartphone, resulting in savings of (450 kB). goodreads.com does not fetch a particular CSS on Glass which is required only for smartphone and hence saves 700 kB of traffic. telegraph.co.uk optimize by not showing ads on Glass and thereby avoiding 1 MB of ad related scripts.
m.youtube.com and mobile.bloomberg.com have a different version of website for Glass and smartphone. Note that different version mean accessing m.youtube.com or mobile.bloomberg.com fetches a different HTML file for the landing page. m.youtube.com serves 50 % (700 kB) lesser and mobile.bloomberg.com serves 60 % (1.5 MB) lesser content to Glass than smartphone version of the website.
In general, the browsing performance on Glass is worse than a smartphone primarily because the same content is being delivered to Glass and smartphone regardless of the device type. Glass is an underpowered mobile device with smaller processing power and smaller battery than smartphones. The following suggestions might be beneficial for efficient browsing on underpowered devices:
Efficient image formats: WebP instead of JPEG or PNG can be used on webpages to save power and lower the webpage load time.
Cloud assisted solutions: An underpowered device can have a light weight browser using cloud based acceleration rather than a full fledged browser as Glass possess. Another way is using a data compression proxy on the cloud, thereby reducing network bandwidth, power consumption and webpage load time.
New protocols: SPDY can be used in place of HTTPS to improve browser performance.
-  CMO. http://www.cmo.com/articles/2014/2/4/digital_video_viewin.html, 2014.
-  Feng et al. Characterizing resource usage for mobile web browsing. In Proc. ACM MobiSys, pages 218–231, 2014.
-  Mendoza et al. What is wrecking your data plan? a measurement study of mobile web overhead. In Proc. IEEE INFOCOM, pages 2740–2748, 2015.
-  Michael et al. Understanding website complexity: Measurements, metrics, and implications. In Proc. ACM IMC, pages 313–328, 2011.
-  Narendran et al. Who killed my battery?: Analyzing mobile browser energy consumption. In Proc. ACM WWW, pages 41–50, 2012.
-  Xiao et al. Demystifying page load performance with wprof. In Proc. USENIX NSDI, pages 473–485, 2013.
-  Google. http://www.chromium.org/spdy/spdy-whitepaper, 2015.
-  Google. https://developer.android.com/sdk, 2015.
-  Google. https://developers.google.com/speed/webp/docs/cwebp, 2015.
-  Josh. http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/, 2013.
-  Mozilla. http://dromaeo.com/, 2015.
-  SunSpider. https://www.webkit.org/perf/sunspider/sunspider.html, 2015.
Table \thetable: Websites Used In Measurements