Poster: Extremely Parallel Resource Pre-Fetching for Energy Optimized Mobile Web Browsing Mohammad A. Hoque, Sasu Tarkoma
Tuikku Anttila
University of Helsinki, Finland
Aalto University, Finland
[email protected]
[email protected]
ABSTRACT Mobile web browsing is experienced slow because of the limited rendering capability of the mobile devices, wireless latency, and incremental rendering of the page or resource loading. The browser renders resources in between two consecutive resource downloads. However, during this period, the wireless interfaces consume energy doing nothing useful. In this work, we measure the performance of SPDY for mobile web browsing. We demonstrate that mobile devices waste energy by keeping the wireless network interface idle between consecutive resource downloads. We next show that by identifying the embedded resources in a web page and downloading those resources in parallel at the very beginning can reduce the small idle periods and thus energy consumption by 20-50%, depending on the wireless network type.
Categories and Subject Descriptors H.3.4 [Systems and Software]: Performance evaluation (efficiency and effectiveness); C.4 [Performance of Systems]: Measurement techniques
Keywords web browsing, parallel connection, energy consumption, SPDY.
1.
INTRODUCTION
Web browsers are among the important applications in mobile devices. Upon submitting an URL, the browser downloads the landing page. However, the landing pages are designed to be more interactive and resource oriented [5]. A typical such page can have ten to hundred resources from diverse domains, depending on the characteristics of the websites [1]. Therefore, the amount of total downloaded content may range few megabytes. The types of resources are mainly the Cascaded Style Sheets (CSS), JavaScripts, html files, and images.
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the Owner/Author. Copyright is held by the owner/author(s). MobiCom’15, September 07-11, 2015, Paris, France. ACM 978-1-4503-3619-2/15/09. http://dx.doi.org/10.1145/2789168.2795167.
Energy consumption for a web page loading comprises energy for downloading resources and for rendering the page. SPDY is a networking protocol that aims to reduce the networking latency by multiplexing a number of connections and compressing the headers [3]. On a mobile browser, network round-trip and resource loading times are the major causes of delay [8]. Therefore, multiplexing of connections results fewer round-trips that have a positive impact on the page load time. Modern browsers, such as Chrome and Firefox, already support this protocol. Google has additional infrastructure support, i.e. SPDY proxy which compresses web elements, specifically images [10]. Therefore, SPDY proxies are part of the web infrastructure [7]. The limitation of SPDY is head of line blocking. Problem with one connection will degrade the performance of the other multiplexed connections and thus overall performance degradation. Consequently, an UDP version of the protocol, called QUIC [2], is also in action in Android Lollipop devices. However, since the page rendering is a sequential process, SPDY and other protocols inherit the delay between two consecutive resource requests while rendering. In this work, we first study how SPDY performs on Android platform. We measured the page download time on Samsung Galaxy S3 4G when SPDY enabled and disabled in Chrome browser, and the energy consumption of the mobile device using WiFi, 3G (HSPA) and 4G (LTE) networks. We found that wireless interfaces can waste energy by remaining idle in between two consecutive resource downloads. To remedy this, we developed a local proxy in a smartphone, which downloads all the resources at the very beginning in parallel connections. Therefore, there is no head of line blocking issue. We show that such approach can optimize wireless network resource utilization and energy consumption significantly.
2.
MOBILE WEB BROWSING WITH SPDY
We selected six websites from the SPDY supported website list [4], and measured the page downloading time and energy consumption of Samsung Galaxy S3 4G when browsing with Chrome Beta via Wi-Fi, HSPA, and LTE. Fast Dormancy and CELL PCH was supported by the HSPA network and DRX was enabled in the LTE network. We accessed the desktop version of the websites in the smartphone.
2.1
Page Downloading Speed
Table 1 summarizes the download times for different website connections. The total number of resources for a page
Site
3G WiFi LTE 3G SPDY SPDY SPDY SPDY Proxy wordpress 6.5 4.0 4.3 4.8 webtide 7.5 3.9 4.3 cloudflare 7.8 3.8 5.5 twitter 6.1 3.3 3.5 facebook 6.8 3.9 3.4 4.4 youtube 7.2 3.8 4.2 4.0
WiFi SPDY Proxy 2.0
LTE SPDY Proxy 3.2
3.2 3.4
3.2 3.5
Server Server Server
Table 1: Average total time (S) required for downloading the front page and resources of websites with Chrome (SPDY and SPDY Proxy).
Browser
Many
while (X > 0) { X = bytesReceivedServer Thread (css, X) Thread (script, X) Thread (image, X) Thread (html, X) } Thread (type, X) { while (true){ resUrl = getNextUrl (X,type) downloadThread (resUrl) } }
Local Proxy
4
Current (mA)
Bytes
3
x 10
Mobile Device
2 1
0 0 1000
2
4
6
8
10
3.
500 0
2
4
Time (S)
6
8
10
Figure 1: Traffic pattern and current consumption for accessing the YouTube page via HSPA with SPDY proxy.
varied from 20 to 80. The downloading time varied greatly over a 3G connection, and also somewhat on the Wi-Fi and LTE connectivity. However, according to the measurements SPDY seems to have a positive effect on download time, especially in 3G network conditions. We measured that SPDY improves by a maximum of 20% for HSPA access compared with browsing without SPDY. With Wi-Fi, SPDY was observed to slow down and in a LTE network SPDY has a small effect in half of the cases, 5% at best. One reason for SPDY being slower on a Wi-Fi connection might be that on a faster network, multiple concurrent connections get data faster than a single one. This was also observed in [1]. Table 1 also reflects the combined effect of SPDY and compression to the images in the SPDY proxy on download times.
2.2
Figure 2: Pre-fetching web page resources at the local proxy in a mobile device.
Energy Consumption
While browsing the web pages, we captured traffic at the phone and measured the current consumption with the Monsoon Power Monitor. Figure 1 shows one such session. We can see that traffic is sporadic in nature and current consumption is high. Such sporadic download of the resources was also observed by Qian et al. [5]. Therefore, even though the actual data transfer for an individual resource takes a small amount of time, the interface remains active for a longer period. After the data transmission is over, current consumption reduces as the HSPA interface changes state from CELL DCH to IDLE or CELL PCH and DRX acts for LTE.
RESOURCES PRE-FETCHING
We noticed that SPDY reduces total number of TCP connections, improves page load times, specially in slower network conditions. In addition, compression at the proxy can reduce the downloading time. Although rendering JavaScripts and CSSs can be equally expensive as an image [6], the nature of traffic still is a challenge. In order to alleviate the effect of sporadic traffic on the energy consumption, we suggest to pre-fetch all the resources embedded in a web page, while downloading the page itself. Site wordpress cloudflare twitter facebook
3G 3.8 3.5 3.3 3.3
Wi-Fi 1.8 1.9 1.7 1.8
LTE 2.5 2.5 2.3 2.7
Table 2: Average total time (S) required for downloading the front page of the websites with resources using local proxy.
We developed a proxy for the Android phone and the mechanism is illustrated in Figure 2. The browser sends a request to the local proxy and the proxy retrieves the page on behalf of the browser. While receiving data for the page, the proxy scans the embedded URLs of four kinds of resources (CSS, JavaScript, image, and HTML page). It employs four separate threads; each for one type of resource. Each of these thread in turn generates multiple threads to download the actual resources depending on the number of resource URLs available of a particular type in the received data of the page. As a result, whenever the browser requests any resource while rendering, the proxy can serve locally. The downloading threads create separate TCP connections to retrieve the resources. Therefore, the idle period between two consecutive resource downloads is reduced. We accessed the HTTP version of the websites via this local proxy. Table 2 shows the required downloading time for all the resources and the webpage itself for four websites. We can see
that such aggressive pre-fetching can reduce the downloading time significantly. We have also observed improvements in energy consumption with this strategy of aggressive prefetching.
4.
DISCUSSION AND CONCLUSION
Some browsers may request and receive critical resources (CSS and JavaScript) at the very beginning of a page loading for fast rendering and keep the remaining resources in the queue. On the contrary, we aim to reduce the idle time between two consecutive resource downloads and DNS prelookup or caching can complement our mechanism. However, there are a number of challenges still required to be addressed. There can be hidden resources which are downloaded while rendering a downloaded resource and thus can jeopardize the pre-fetching effort. In addition, it is not guaranteed that all the downloaded resources will be utilized by the browser. Therefore, energy consumption or downloading could be further optimized if there would be a preprocessed list of resources for a webpage. HTML5 offers a mechanism namely AppCache with a cache manifest file for every page at the server in order to provide offline browsing support. Wang et al. [9] proposed a similar approach by constructing and caching a resource graph. However, these approaches face the above challenges for rapidly changing web sites and a solution is needed.
5.
REFERENCES
[1] J. Erman, V. Gopalakrishnan, R. Jana, and K. K. Ramakrishnan. Towards a spdy’ier mobile web? In Proceedings of the Ninth ACM Conference on Emerging Networking Experiments and Technologies, CoNEXT ’13, pages 303–314, New York, NY, USA, 2013. ACM. [2] Google and Chromium. Quick UDP Internet Connections. http://www.ietf.org/proceedings/88/ slides/slides-88-tsvarea-10.pdf. [3] Google and Chromium. Spdy: An experimental protocol for a faster web, white paper, June 2013. [4] Netcraft. Web server survey, May 2012. [5] F. Qian, S. Sen, and O. Spatscheck. Characterizing resource usage for mobile web browsing. In Proceedings of the 12th Annual International Conference on Mobile Systems, Applications, and Services, MobiSys ’14, pages 218–231, New York, NY, USA, 2014. ACM.
[6] N. Thiagarajan, G. Aggarwal, A. Nicoara, D. Boneh, and J. P. Singh. Who killed my battery?: analyzing mobile browser energy consumption. In Proceedings of the 21st international conference on World Wide Web, WWW ’12, pages 41–50, New York, NY, USA, 2012. ACM. [7] B. Thomas, R. Jurdak, and I. Atkinson. SPDYing up the web. Commun. ACM, 55(12):64–73, Dec. 2012. [8] Z. Wang, F. X. Lin, L. Zhong, and M. Chishtie. Why are web browsers slow on smartphones? In Proceedings of the 12th Workshop on Mobile Computing Systems and Applications, HotMobile ’11, pages 91–96, New York, NY, USA, 2011. ACM. [9] Z. Wang, F. X. Lin, L. Zhong, and M. Chishtie. How far can client-only solutions go for mobile browser speed? In Proceedings of the 21st International Conference on World Wide Web, WWW ’12, pages 31–40, New York, NY, USA, 2012. ACM. [10] M. Welsh and I. Grigorik. Data compression proxy, Mar 2013.
