{'fraction_non_alphanumeric': 0.02778026704901873, 'fraction_numerical': 0.006877856438748992, 'mean_word_length': 4.770782159017453, 'pattern_counts': {'":': 0, '<': 6, '<?xml version=': 0, '>': 4, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 1}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Understanding Quality of Experiences on Different Mobile Browsers: Measurements, Analysis, and Implications

The web browser is one of the major channels to access the Internet on mobile devices. Based on the smartphone usage logs from millions of real-world Android users, it is interesting to find that about 38% users have more than one browser on their devices. However, it is unclear whether the quality of browsing experiences are different when visiting the same webpage on different browsers. In this paper, we collect 3-week consecutive traces of 337 popular webpages on three popular mobile browsers: Chrome, Firefox, and Opera. We first use a list of metrics and conduct an empirical study to measure the differences of these metrics on different browsers. Then, we explore the variety of loading time and cache performance of different browsers when visiting the same webpage, which has a great impact on the browsing experience. Furthermore, we try to find which metrics have significant effect on the differences, investigating the possible causes. Finally, according to our findings, we give some recommendations to web developers, browser vendors, and end users.


Introduction
Web browsing is always the major requirement of Internet users. Recent reports show that the number of smartphone users worldwide has been over 2.6 billion, and the web traffic volume from mobile devices has exceeded that from desktop PCs. Compared to desktop PCs, web browsing on smartphones considers more on the quality of experiences (QoE): not only the look-and-feel and page loading time, but also the data traffic and energy consumption. Designing efficient mobile browser becomes a very significant strategy for browser vendors to grab the access channel of mobile web. Although it is argued that smartphone users prefer specific-purpose apps such as news reader and social network, more and more apps essentially integrate and customize browser engine for fetching and rendering content [6]. For example, the BBC news app integrates Android WebView (which is a browser component based on Chrome) to exhibit its news list and news content.
Besides the major browsers such as Google Chrome, Mozilla Firefox, Opera, and Safari, it is observed that over 100 browsers developed by small-and-medium vendors have been released on popular app stores such as Apple AppStore, Google Play, and so forth. For example, in China, numerous browsers on smartphones are emerging, like UCWeb browser, QQ browser, 360 browser [4]. Hence, smartphone users can have various alternatives to select browsers. Our previous study demonstrated that users holding different device models can have different preferences in choosing web browsers, i.e., the high-end users tend to choose Google Chrome while the low-end users tend to choose Opera and UC Web [17]. We can infer some possible reasons from the textual descriptions of browsers. For example, the UCWeb browser claims to employ cloud to compress the contents in advance before sending the data to the smartphones, and thus can save traffic for end-users who have very limited data plan [3]. Unfortunately, so far we have the absence of a systematic and comprehensive to demystify how these browsers differ from one another when fetching and rendering the same webpages. Two interesting but non-trivial questions need to be answered: • How long do different mobile browsers load the same webpage?
• How well does the cache performance vary in different browsers and thus affect data consumption for the same webpage accordingly?
Understanding the keys to these questions and their implications is vital on several aspects. With the increasing popularity and diversity of mobile devices for accessing the web, it is important for browser vendors to identify the aspects that can impact the quality of user experiences, so that they can fix potential defects and flaws and thus attract more users in the browser war. In addition, the mobile app developers can choose and integrate the adequate browser kernels into their apps for better browsing experiences. On the other hand, as web providers increasingly incorporate third-party services such as advertising, analytic, and Content Delivery Network (CDN) into their webpages, they need tools and techniques to evaluate the impacts of these services to users. Furthermore, beyond the perspective of any given users or web providers, understanding differences of mobile browsers is the first step toward solutions to webpage customization for varying client programs to achieve the right balance between performance, usability, and user interests.
This paper tries to bridge such a knowledge gap. We conduct a measurement study by employing three representatively popular mobile browsers: Chrome FireFox and Opera. We deploy the three browsers under the same smartphone emulator and made them request the same webpages under the same network environment. To avoid bias, our extensive measurement keeps on revisiting the homepages of 337 popular websites every 30 minutes, and continuously lasts for 3 weeks. To rigorously and comprehensively measure the differences among browsers, we devise a model with various metrics and apply statistical correlation analysis. The results demonstrate that a large percentile of webpages are significantly various on different browsers in terms of loading time and cache performance. Based on the findings, we suggest some implications to browser vendors, web developers, and end-users.
Although there have been numerous debates of browser war, to the best of our knowledge, we make the first study of comprehensively comparing the differences of various mobile browsers. More specifically, this paper makes the following contributions.
• We first report the diversity of choosing mobile browsers based on date usage logs collected from millions of smartphone users.
• We establish an automated data-collection platform to collect fine-grained traces of the same webpages accessed from different mobile browsers, under the same OS, hardware, and network environment. We collect request traces of homepages from 337 popular websites continuously for three week.
• We use various metrics to comprehensively characterize the differences among different browsers We reveal the statistically significant differences among representatively popular browsers in terms of loading time and data consumption when visiting the same webpage.
• We analyze the root causes leading to the differences among browsers. For example, some kernelrelated declarations in the CSS sheet, like -webkit -text-sizeadjust, -webkit-appearance, lead to special display effect in a certain browser. We then present some recommendations on how to improve the design of browsers and webpages. Meanwhile, end-users or app developers can take knowledge away from our findings to select the proper browser (or kernels) when browsing/designing specific webpages.
The remainder of this paper is organized as follows. Section 2 evidences that current smartphone users tend to install various mobile browsers from a collection of 5-month logs of over 4 million real-world Android users. Section 3 introduces our measurement methodology and the setup of our measurement platform. Section 4 describes our collected data. Section 5 and 6 compare the loading time and cache performance of the same webpage on different browsers, respectively. Section 7 provides some suggestions and recommendations to browser vendors, web developers, and end-users. Section 8 presents the related work that has been made in mobile web browsing. Section 9 ends up the paper with concluding remarks and future work.

Motivation
There are various kinds of browsers nowadays for mobile devices. Different browsers have different kernels, data persistence mechanisms and user interfaces. In this section, we use smartphone usage logs collected from millions of real-world Android users to present two interesting findings that illustrate the usage of mobile browsers. The data is from Wandoujia 1 , a free Android app marketplace in China. More details of the Wandoujia dataset can be referred in our previous work [17][21] [19], including network activity statistics, permission monitoring, content recommendation, etc. We filter out a subset of the whole dataset related to only those browser apps. The filtered dataset contains 4-month records of browser app installation from 4,775,536 users.

Diverse Choice of Browsers
We first demonstrate the diverse choice of browsers on smartphones by considering the screen size. For each of top 10 mobile browsers, we calculate the cumulative distribution function (CDF) of devices with different screen sizes that has install the browser. Figure 1 depicts the result. It is easy to find that the screen size of mobile devices has a impact on the user selection of browsers. The line of Opera Mini is to the most upper-left, meaning that users of Opera Mini tend to use devices of smaller screen. On the contrary, the line of Chrome is to the most bottom-right, meaning that Chrome tends to be installed on devices of larger screen.
The finding reveals the subtle differences among browsers. We speculate that it can be caused by discrepant display of browsers, which precipitate users to choose browsers based on their screen size.

Usage of Multiple Browsers
We then calculate how many browsers a single user has installed on his/her smartphone. Figure 2 shows the result. About 38% of users install more than one browser. There are even 1% of users installing four or more browsers.
It is interesting to explore reasons why users need multiple browsers on their mobile devices. A clear explanation may be that the functions of a webpage may vary across different browsers. The browser compatibility issue has always been argued since the birth of the browser. However, apart from functions, mobile browsing considers more on non-functional issues such as the time spent on loading a page, and network traffic used to load a webpage.

Methodology
In this section, we present how we study the quality of experience (QoE) of different mobile browsers.
Our study focus on the non-functional aspects of QoE, which is orthogonal to those of browser compatibilities. We assume that the root cause to the QoE differences lies in the variety of resources acquired via different browsers. Based on the assumption, we design and establish a platform to collect traces of resources from 337 popular websites, via three popular mobile browsers, and for a considerably long time. The collected data form the basis of our measurement study.

QoE Measurement
For web browsing on mobile devices, QoE not only focuses on the page load time like browsing on desktop PCs, but also emphasizes the data and energy consumption since mobile devices usually access the Internet by cellular data plan and are battery-powered. Therefore, we focus on the loading time and cache performance of different browsers in this paper because. While loading time directly influence the user-perceived QoE, cache performance determines the data consumption. Energy consumption is not easy to compare among browsers but it can be induced from the loading time and cache performance.
Basically, there are many factors that could influence the QoE of different browsers, such as how well the browser's engine perform, and whether web developers optimize their websites for different browsers. However, the process of browsing the web on a browser is actually fetching a series of resources from the network. Therefore, we assume that the fetched resources when browsing the web on different browsers is a good indicator to the QoE differences when studying the root causes related to different browsers.

Data Collection
To analyze the QoE of different browsers, we need to collect real access data. However, real user data is not comparable due to the individual browsing behaviours. In addition, since we focus on only the browsers, we should control the hardware, OS and network environment, and visit same webpages simultaneously on different browsers.

Webpages
We select the webpages to be studied from homepages of popular websites ranked by Alexa [1] top 500 list. For some problems, we filtered out some of the following webpages: • Unreachable webpages. Some webpages are not available because of server internal error or network problem.
• Duplicate webpages. Some webpages have different domain names but actually offer the same service. We keep only one of them.
Finally, we have a set of 337 webpages.

Design of data-collection platform
We design a data-collection platform that can control different browsers to simultaneously visit same webpages and record the network traffic during the process. Figure 3 shows the architecture of the platform. A visitor is a node that requests a set of webpage at a certain interval. The webpages are identified by a list of given URLs. A visitor is composed of three parts: a browser, an extension and a Charles web proxy [2]. We enable browsers' emulation mode and set the user agent to "Android 4.2". In this case, the servers will return mobile-version webpages. When browsers render the webpage, resources are requested either from the network or from the local cache. To study the cache performance, in some nodes, the cache policy is set to be prohibited in browser configuration in order to acquire the whole set of resources at each time point. In other nodes, we enable the cache to study the real browser behaviour.
The Charles web proxy is used to record all network traffic. Charles records all HTTP/HTTPS connections passing through it. Moreover, Charles offers a set of APIs for programmers to access its data, which helps us download and save.
Finally, we build extensions for browsers to automatically revisit a webpage. The extensions are a little bit different from each other because different browsers offer different interfaces for extensions. However, the control logics remain the same: all extensions are set to revisit a list of given URLs at a certain interval, then access data recorded in Charles and submit the response to the collector. To make sure that a webpage has been loaded completely before shifting to the next one, we set a threshold of one minute. That's to say, the next webpage will wait for at least one minute after the previous webpage being requested.
The collector is a PHP server receiving all data collected by visitors. The PHP server receives data from all visitors and record information to its local disk.
The central manager is used to control all the visitors. It sets the starting time of data collection in order to make all browsers start their work simultaneously. It can also stop or restart a certain browser to handle some exceptions during the collection.

Platform deployment
We deploy our platform on Aliyun virtual machines and make sure that all visitors visit the same webpage at the same time within the same hardware and network environment. Table 1 shows the deployment details. We choose three most popular mobile browsers: Chrome, Firefox and Opera, as the browsers to investigate. All the virtual machines are located in the same geographical location in Qingdao, China to avoid the CDN's influence. We carried out 24 groups of data collection at the same time: In 3 groups, we use Chrome, Firefox or Opera, to revisit a list of mobile webpages every 30 minutes, with the browser cache disabled. In the other 21 groups, the browser cache is enabled, and the revisiting intervals are 30 minutes, 6 hours, 12 hours, 1 day, 2 days, 4 days and 7 days. We control to make sure that all these 24 groups visit a certain webpage simultaneously. We keep track of all request and response traffic for three weeks. That is approximately 1000 visits for each webpage. The total size is 4.6 terabytes. After parsing saved files, we have a database of over ten million records.

Data Characterization
In this section, we first describe the data set of our experiment. Then we describe the factors and metrics we use to illustrate the webpage and explain the QoE difference on different browsers.

Factors and Metrics
We consider a list of factors that may be correlated with the QoE. In later section, we analyse the impacts of these factors and illustrate the major factors that cause QoE differences on different browsers. These metrics describe all the factors of the content of a webpage. Table 2 is the list the of metrics.
Firstly, we attempt to define several factors that potentially influence the loading time of a webpage. Scale of resources of a webpage includes the total number of resources and total size of resources. The resources in a webpage include all HTML, JavaScrpt, CSS, image, etc. after being rendered. The scale of resources can vary a lot among different browsers. A Browser has a unique identifier in the user-agent field of an HTTP request to identify its type and version. For example, requests sent by Chrome include Chrome /41.0.2272 in user-agent field. While requests sent by Firefox include Gecko/20100101 Firefox/36.0 in user-agent field. Thus, the servers may return different resources to different browsers, leading to different sizes and numbers of resources. Scale of resources lead to different loading time on different browsers because large number of resources tend to consume much more time. What's more, browsers may have their own strategies to parse and render a webpage. For example, the pre-fetching strategy may be suitable for webpages with large numbers of resources, because it saves the time for HTTP connection.
Distribution of MIME type resources messures the distribution of HTML, JavaScrpt, CSS, image and other resources in a webpage. It includes the size and number of HTML, JavaScrpt, CSS, image and other resources in a webpage. We concern about this factor because browsers may show different  Have impacts on cache performance.
capabilities of handling these resources. For example, a browser that has a faster JavaScript engine may have less loading time for webpages with a high proportion of JavaScript resources.
Dependence on third-party resources influences the loading time among browsers. We judge whether a resource is from a third-party website by its URL. If the URL contains the key word of a website's domain, then it is identified as the normal resource provided by the web developer. Otherwise, it is identified as a third-party resource provided by other developers. What's more, we are also interested in two kinds of third-party resources. The first one is the ads. The second one is the resources offered by the browser vender. We list the numbers of these resources, too. Browsers may show different preferences to third-party resources and even forbid some of the domains due to security reasons.
HTTPS secure mechanism offers extra security guarantee for users. However, HTTPS requires bidirectional encryption of communication and the capability of different browsers may be vary. The numbers of HTTPS resources is also what we should concern about. Then, we define several factors that potentially influence the cache performance.
Scale of resources has an impact on the total data traffic in one visit. However, in later analysis, we tend to use the proportion to the total traffic, which reduces the impact of this factor.
Distribution of MIME type resources not only has an impact on loading time, but also influences the data cosumption. Some specific types of resources, like JavaScript, are much more variable than the others. High percentage of those kinds of resources leads to more data consumption.
Redundant transmission consists of invalid resources with unexpected HTTP status code and duplicated resources. E.g., a resource responding with status 404 is invalid, and a resource having totally same URL with another one is duplicated. Redundant transmission may be caused by poor strategy of error handling. It is one of the reasons that cause more data consumption.
Explicit cache control of resources is an important factor we should concern. Cache policy influences the data consumption in an obvious ways. A webpage with larger percentage of resources that have explicitly set cache parameters is likely to consume less data in the long term.

Difference of Metrics on Different Browsers
Now we compare the resources of webpages using the factors and metrics we have defined. For each of these 337 webpages, we have a trace of over 1000 visits using Chrome, Firefox and Opera. We first analyze the statistical significance of the difference between two browsers, i.e., Chrome vs. Firefox, Firefox vs. Opera, Chrome vs. Opera, by applying Mann-Whitney U test at p-value=0.05. E.g., when we compare the total resource number of different browsers, we need to carry out three U tests. The first null hypothesis is that Chrome does not have significant different numbers of resources in a visit with Firefox, the second one is that Firefox does not have significant different numbers of resources in a visit with Opera and the third one is that Chrome does not have significant different numbers of resources in a visit with Opera. Thus, we can see whether a webpage have different total numbers of resources on any two of the browsers. Table 3 lists the percentage of webpages that show significant difference after U test for each metric. It is amazing that, most metrics, like the total scale of the website (measured by total number and total size), the distribution of different types of resources (measured by different MIME type resources) and dependence on third-party resources, show great difference among browsers. For example, up to 90% webpages have different scales among Chrome and Firefox.

Common Resources of Browsers
To have a better understanding of the differences, we classify all the resources into seven categories: the resources shared by all browsers (ALL), the resources shared by Chrome and Firefox but not Opera (CRFF), the resources shared by Firefox and Opera but not Chrome (FFOP), the resources shared by Opera and Chrome but not Firefox (OPCR), the resources fetched only by Chrome (CR), the resources fetched only by Firefox (FF) and the resources fetched only by Opera (OP). Now we take the comparison between the resources of these seven categories. We calculate the proportion of different kinds of resources. The common resources of all three browsers have a high proportion of image resources while have a low proportion of HTML resources. The distinct resources fetched by only one browser have a high proportion of HTML while have a low proportion of image. The results show that within all kinds of resources, HTML tends to be different among browsers while image tends to be the same.

Examples of Differences
To make it more intuitive and comprehensible, we list several common differences between the content of two browsers at a simultaneous visit (shown in Figure ??.
Numbers of resources in a webpage can be different. For example, when visiting Espn.go.com, Firefox is lack of lots of resources and doesn't show tool bar on the top. Ads make differences among browsers. In some cases, different browsers recommend different ads for users. In some cases, browsers don't show ads at the same time or at the same position on the screen.
Kernel related style sheet can be different between two browsers. In the visiting traces of baidu.com, we find that the document of Opera contains a declaration of extra css style, while Firefox doesn't. The reason is that this style declaration is related to the browser kernel. To improve readability on webpages designed for desktop browsers, mobile browsers with webkit kernel automatically increases the size of small text. For Firefox, it's non-standard. There are several attributes in this category: -webkit-text-sizeadjust, -webkit-appearance, -webkit-box-sizing and etc.
< style type = " text / css " class = " spa -index -style " > body { font -family : Arial , Helvetica , sans -serif ; -webkit -text -sizeadjust : none ;} input , button , textarea { -webkit -appearance : none ; -webkit -box -sizing : border -box ;} ... </ style > The special adjustment of style sheet is necessary. There are several other differences about the style sheet. E.g., not all browser engines are allowed to control the final size of the text using a percentage value (Webkit and Trident do allow it, Gecko doesn't). Thus, webpages using percentage value need different style sheets for different browsers. Extra webpages provided by browser vendors is a common difference. E.g, Opera provide a so called fraud check for current opening site. For any opened site, the browser sends a request to a page( sitecheck2. opera.com ) with the current link as the parameter. Consequently, all webpages rendered on Opera have this special request. Not only Opera, but also vendors of Chrome and Firefox provide their special services to the users, too. Extra webpages provided by browser vendors are totally different to users.

Loading Time Comparison
Loading time refers to the time before a website completely loaded and being capable of reacting to the next request of users. It is one of the major targets to improve the quality of user experience. Loading time doesn't include the propagation delays; because web providers and web users are distributed all around the world and the propagation delays may be vary. To measure the loading time of different websites, we focus on the time of resolving, analyzing rendering and display. In this section, we aim to compare the loading time of the same website on different browsers.

Comparison of Loading Time
After gathering a set of 337 websites' traces, we now have to measure the loading time of these websites on different browsers. Loading time is an important factor impacting human expectations, feelings, and satisfaction with respect to a particular product. We define the loading time as the time between the request time of the first resources and the response time of the last one. What's more, loading time of a website is defined as the median loading time in all visits The cumulative distribution function of loading time on different browsers show explicit difference between each other. We are surprising to find that, the actual loading time of Chrome is larger than the other two. There are also some difference between Firefox and Opera.

Website Classification
Generally speaking, there is a great deal of difference on different browsers when we consider the loading time of websites on different browsers. However, When we consider a certain website, the loading time of this website on these three browsers depend not only on the features on browsers, but also the features of the website itself. We are interested about the features of those websites that show better loading performance on a certain browser.
For each of these 337 webpages, we have a trace of over 1000 visits using Chrome, Firefox and Opera. We can judge whether a website has significant less loading time compared to the other two browsers. We first analyze the statistical significance of the difference between two browsers, i.e., Chrome vs. Firefox, Firefox vs. Opera, Chrome vs. Opera, by applying Mann-Whitney U test at p-value=0.05. E.g., when we compare Chrome vs. Firefox, we need to carry out two single side tests. The first null hypothesis is that Chrome doesn't show advantage over Firefox and the second one is that Firefox doesn't show advantage over Chrome. These two statistical tests are carried to justify that on which browser a webpage has less loading time. We find that a large quantity of the selected webpages has statistically significant differences (about A website is regarded as having less loading time on a certain browser when it significantly has shorter loading time than the other two browsers within all visits.
The numbers and proportions of each group are shown above. We are even more interested about another question: what kind of the webpages is suitable for a browser? In another word, why a webpage has significantly less loading time on a browser? We will answer this question in the next part.

Relationship between Metrics and Optimal Browser
Prior work has defined several metrics that describe the resource content on different browsers. In this section, we are interested in investigating how each factor of a website is related with its optimal browser. We have defined 3 sets, i.e., CR, FF and OP to represent the set of webpages that are particularly suitable for Chrome, Firefox and Opera. We now compare the values of each factor between CR and CR's complement, FF and FF's complement, OP and OP's complement.
We first analyze the statistical significance of the difference between the two sets by applying the U test at p-value=0.05. The null hypothesis is that webpages perform better on Chrome doesn't have significant different factors with the others. To show the effect size (ES) of the difference between the two sets, we compute Cliffs Delta (d). d is used to measure how often the values in one distribution are larger than the values in second distribution.
Tables below show the d value of all factors. Statistically significant difference should have large d value. We interpret the effect size values as small for d<0.1, medium for 0.1<= d<=0.15 and large for d>= 0.15.
Several metrics that have large cliffs d value are listed as follows: The webpage suitable for Chrome, i.e. CR, tends to have a large proportion of JavaScript resources. Its d value is 0.176 and is much more significant than Firefox and Opera. In another word, webpages that perform better on Chrome have a large proportion of JavaScript resources. It can be reasonable because a browser can improve the performance by accelerate the rendering and execution of JavaScript.
CR tends to have a lower percentage of image files while FF tends to have a higher one. It means that Chrome and Firefox may have different policies on image rendering. Typically, Firefox may be good at handling large quantities of images including png, jpeg and gif. CR and OP tend to have large proportion of text files including html and xml. FF has the lower one to the opposite. It reflects the ability difference of rendering DOM node of different browsers.
OP has a large percentage of third-party resources, which means Opera provides better approaches to third-party webpages.
FF has a small percentage of HTTPS resources while OP has a great one. HTTPS consists of communication over Hypertext Transfer Protocol within a connection encrypted by Transport Layer Security

Cache Performance Comparison
In this section, we first measure the cache performance on different browsers. Then we take a deeper discussion about the reasons that lead to the difference on cache performance.

Cache Performance Measurement
We use the cache hit rate to denote the cache performance. The hit rate is defined as the division of saved traffic and the total traffic in this visit. As we have collected the traces of both cached and uncached revisiting records, we simply get the hit rate from their division. What's more, hit rate of a website is defined as the median hit rage in all visits.
We show the median hit rate of all websites below.The x-axis is the revisiting interval, i.e, 30 minutes, 6 hours, 12 hours, 1 day, 2 days, 4 days, 1 week. The y-axis is the median hit rate of 337 websites. An obvious conclusion is that the median hit rate decreases as the revisiting time increases. What is more interesting is that the cache performance of Firefox is poorer than Chrome and Opera in almost all intervals, while Chrome and Opera are alomost the same.
We list the more detailed CDF plot of hit rate here. The x-axis is the median percentage of saved traffic of a website. The y-axis is the CDF. The revisiting interval from (a) to (g) is 30 minutes, 6 hours, 12 hours, 1 day, 2 days, 4 days, 1 week. The red line is Firefox, blue is Chrome and brown is Opera. It becomes more clear that the distribution of Firefox's hit rate is significantly smaller than the other two browsers. We try to find some causes to explain it.

Analysis of Uncached Resources
We get a breif idea about the total cache hit rate through the data analysis as metioned above. The Firefox shows poorer cache performance. To take a more in-depth analysis, we classified the resources by their MIME type. We show the median percentage of HTML, image and JavaScript resources in the uncached resources.  Figure 7: CDF of the percentage of saved traffic. The x-axis is the median percentage of saved traffic of a website. The y-axis is the CDF. The revisiting interval from (a) to (g) is 30 minutes, 6 hours, 12 hours, 1 day, 4 days, 1 week. The red line is Firefox, blue is Chrome and brown is Opera.
We find that Opera has higher proportion of HTML resources that cannot be cached. Chrome has higher proportion of image resources that cannot be cached. Firefox has higher proportion of JavaScript resources that cannot be cached.
Compared with HTML and image resources, JavaScript obviously are much more dynamic type. Large percentage of JavaScript explains why Firefox need to consume much more traffic data than others. We can see that, although firefox have more numbers of resources cannot be cached, it actually shows advantage in the numbers of etag/last-modified resources. It seems to be a little bit confusing, because with more resources using etag/last-modified policy, Firefox should save data consumption, rather than waste data consumption. In our deeper research, we find the root cause.
Although Firefox has more resources using etag or last-modified policy, it actually always skips the validation and directly fetches the resource from the server. Here is an instance to show the problem of Firefox. When a client revisits the wikipedia.org. It fetches a resource in every visit with the url of https:// bits.wikimedia.org/meta.wikimedia.org/load.php?debug=false&lang=en&modules=ext.gadget.wm-portal& only=styles&skin=vector&*. The resource is a css file and remains unchanged for a considerable time. The cache control policy of the resource is that public, max-age=300, s-maxage=300, which means that the browser should keep the resource for 300 seconds. What's more, as the resource uses etag and lastmodified, the revisits beyond 300 seconds should confirm whether the resource changes before fetching the whole resource.
Our experiment shows that, for Chrome and Opera, in an interval of 30 minutes, both browsers fetch the resource with the status code 304, which means both browsers fetch the resource from the local cache after validating the unchangeness of the content. While for firefox, it becomes complex and confusing. In some sitiations, Firefox fetches the resource with the status code 304. In other situations, Firefox fetches the resource with the status code 200, which means Firefox skips the validation and directly fetches the resource from the server. And this finally cause the poor cache performance of Firefox. Large percentage(>60%) of webpages have different proportion of HTML, image and JavaScript resources. As for CSS abd JSON, the percentage(<30%) of webpages is rather small.
Layouts and data of a webpage are more stable among different browsers while the structure and media objects may be more different.
Most webpages have similar metrics among Chrome and Opera than Firefox.
The kernel of Chrome and Opera is similar as they both use Blink while the kernel of Firefox is Gecko. However, although Chrome and Opera share the similar kernel, other internal logics, such as Javascript engine, may be different. Within all kinds of resources, HTML tends to be different among browsers while image tends to be the same. Behind the similar look-and-feel of webpage, the definition of layout can be various among browsers.
Firefox's cache performance is significantly poorer than Chrome and Opera. With the increase of revisiting interval, the gap between browsers become smaller.
For webpages that are revisited within a larger interval, there is no big difference on data consumption among different browsers. But for those frequently revisited webpages, it may be better to use Chrome or Opera. Firefox requests more resources using E-tag or last-modified policy, but it actually always skips the validation and directly fetches the resource from the server.
Browser vendors should pay attention to the implementation of E-tag and last-modified, which can lead to undesired data consumption. Opera has higher proportion of HTML resources that cannot be cached. Chrome has higher proportion of image resources that cannot be cached. Firefox has higher proportion of Javascript resources that cannot be cached.
Compared to HTML and image resources, Javascript can generate a lot of dynamic contents. Large percentage of Javascript involved in a webpage should be the reason why Firefox consume much more traffic data than others. Webpages with large proportion of Javascript and lower proportion of images have shorter loading time on Chrome. Webpages with large proportion of images perform better on Firefox. Webpages with more third-party resources perform better on Opera.
The developers should make best use of the benefits and bypass the disadvantages of a browser. What's more, users can use different browsers to visit different kinds of webpages to reduce the data traffic.
Webpages with large percentage of HTTPS tend to have less loading time on Opera, while have more loading time on Firefox.
Opera developers should pay attention to their implementation of HTTPS. For secure connections, it's better to use Firefox. Some kinds of MIME type resources, especially CSS and JSON, do not have much influence on the loading time among browsers.
The different logics of layouts on different browsers does not influence the loading time so that developer should consider more to ensure consistent look-and-feel.

Implication
In this paper, we take a detailed analysis on the differences between three browsers: Chrome, Firefox and Opera. There are some interesting and meaningful results. In this section, we list the results and their implications in Table 8.

Related Work
The cross-browser compatibility problem has gained a lot of research efforts since the birth of the Web browser. It is widely recognized as an important issue among Web developers but hardly ever addressed directly during the software development process [32,20][25] [14]. S. R. Choudhary and M. R. Prasad and A. Orso [10] find that, due to the increasing popularity of web applications, and the number of browsers and platforms on which such applications can be executed, cross-browser incompatibilities (XBIs) are becoming a serious concern for organizations that develop web-based software Choudhary et al. [11] proposed a technique for automatically detecting cross-browser issues and assisting their diagnosis. Given a page to be analyzed, the comparison is performed by combining a structural analysis of the information in the page's DOM and a visual analysis of the page's appearance, obtained through screen captures. Mesbah and Prasad [27] defined the cross-browser compatibility problem and proposed a systematic, fully-automated approach for cross-browser compatibility testing that can expose a substantial fraction of the cross-browser issues in modern dynamic Web applications. A navigation model is used to compare two Web applications based on trace equivalence and screen equivalence. To try to solve the cross-browser compatibility problem S. R. Choudhary [9] builds WEBDIFF, the first technique to apply concepts from computer vision and graph theory to identify cross-browser issues in web applications.
Research about the website characterization is an important research question. A lot of work have done to characterize and describe the factors of web related problem [17] [30] [31] [13] [15]. Fred Douglis, Anja Feldmann, Balachander Krishnamurthy and Jeffrey C. Mogul [12] take research about characteristics of Web resources, including access rate, age at time of reference, content type, resource size, and Internet top-level domain. Butkiewicz, Michael and Madhyastha, Harsha V. and Sekar, Vyas [8] identify a set of metrics to characterize the complexity of websites both at a content-level (e.g., number and size of images) and service-level (e.g., number of servers/origins).They find that the distributions of these metrics are largely independent of a website's popularity rank. However, some categories (e.g., News) are more complex than others. Those researches help to characterize the content of web pages by several interesting metrics.
The analysis of the mobile web performance is an important research question in the past years. Huang et al. [16]measured mobile Web browsing performance. Wang et al. [34] examined the issues specific to mobile Web browsers. Mobile HTTP Archive [5] records mobile Web performance information of about 5000 mobile websites. But its recording period is 15 days, and is too coarse-grained to analyze the cache performance. Qian et al. [29] perform the first network-wide study of the redundant transfers caused by inefficient Web caching on handsets. Niranjan Balasubramanian, Aruna Balasubramanian et al [7]. present a measurement study of the energy consumption characteristics of three widespread mobile networking technologies: 3G, GSM, and WiFi. Qian et al [13] take a first comprehensive examination of the resource usage of mobile Web browsing by focusing on two important types of resources: bandwidth and energy. Our previous work studied the performance of JavaScripts in mobile Web browsing [23], and the comparison between native apps and Web apps [24].
A lot of efforts have been invested to study the performance of mobile Web cache. Wang et al. [36] examined three client-only solutions to accelerate mobile browser speed: caching, prefetching, and speculative loading, by using Web usage data collected from 24 iPhone users over one year. They found that caching has very limited effectiveness: 60% of the requested resources are either expired or not in the cache. Zhang et al. [37] performed a comprehensive measurement study on Web caching functionality of 1300 top ranked Android apps, not just Web browsers. Results revealed that imperfect web caching is a common and serious problem for Android apps generating Web traffic. They also implemented a systemwide service called CacheKeeper to effectively reduce overhead caused by poor Web caching of mobile apps. Qian et al. [29] conducted a measurement study on Web caching in smartphones. By examining a one-day smartphone Web traffic dataset collected from a cellular carrier and a five-month Web access trace collected from 20 smartphone users, the study revealed that about 20% of the total Web traffic examined is redundant due to imperfect cache implementations. Our previous work et al. [26][22] studied the mobile Web cache performance. In our following work [22] [22], we optimize the cache performance.
Measurement of resource loading is also an important research question. Wang et al. [35] advocated that resource loading contributes most to the browser delay. Wang et al. [33] designed a lightweight in-browser profiler, called WProf, and studied the dependencies of activities when browsers load a webpage. Nejati et al. [28] extended WProf to WProf-M and studied the differences of page loading process between mobile and non-mobile browsers. Li et al. [18] designed WebProphet to capture dependencies among Web resources and to automate the prediction of user-perceived Web performance.
However, none of the work cast light on the differences from the perspective of browsers. Our work takes discussion about the mobile performance, i.e, cache and loading from the view of browsers.

Conclusions
In this paper, we conduct a comprehensive study on the quality of experiences among different mobile browsers. We design and establish an automated data-collection platform to collect resources from the same webpages when accessed from different browsers for a considerably long time. We choose Chrome, Firefox and Opera as our target browsers. We use several metrics to compare the differences of resources acquired from different browsers. Based on the resource characteristics, we further analyze the loading time and cache performance of different browsers, revealing the root causes. Our findings can benefit browser vendors, web developers as well as end-users.