# On leveraging browser-level measurements for network troubleshooting

Sanaa Ghandi, Chadi Barakat, Yassine Hadjadj-Aoul

► To cite this version:

Sanaa Ghandi, Chadi Barakat, Yassine Hadjadj-Aoul. On leveraging browser-level measurements for network troubleshooting. MEDITCOM 2025 - Fifth IEEE International Mediterranean Conference on Communications and Networking, Jul 2025, Nice, France. pp.1-6, 10.1109/medit-com64437.2025.11104452 . hal-05086467

HAL Id: hal-05086467

https://inria.hal.science/hal-05086467v1

Submitted on 27 May 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
On leveraging browser-level measurements for
network troubleshooting

Sanaa Ghandi

Inria, Université Côte d'Azur

France

Chadi Barakat

Inria, Université Côte d'Azur

France

Yassine Hadjadj-Aoul

Univ Rennes, Inria, CNRS, IRISA

France

*Abstract*—Despite advances in network technologies, slow web browsing remains a persistent issue, and its troubleshooting continues to be challenging. To address this challenge, our work presents a lightweight passive measurement solution that relies on web performance data readily available within the browser, such as the connect time, the response time, and the page load time, to infer network performance, detect anomalies, and troubleshoot their origins. Through controlled network experiments with manually injected anomalies, including multiple concurrent performance issues, and leveraging a dataset of more than 43,000 webpages and tens of thousands of network scenarios, we develop a predictive model using machine learning that is capable of estimating network performance metrics with acceptable accuracy. By solely relying on users' daily web activity, our solution can continuously monitor network performance, identify anomalies, and provide actionable insights, without overloading the network with measurement probes, thus making network troubleshooting accessible and non-intrusive for everyday users.

*Index Terms*—Passive measurements, web browsing, network performance prediction, machine learning.

# I. INTRODUCTION

Assessing network quality is crucial for effective network management and for ensuring a satisfactory user experience. To predict and understand the quality of service (QoS) perceived by end users, operators often rely on time-evolving measurements that reflect the overall network performance and related metrics. There are two main approaches for gathering these measurements [1]. The first approach relies on active measurements, where packet probes are sent through the network to collect real-time feedback. A typical example is the iPerf3 tool [2]. While this approach provides direct and instant data, it has two significant drawbacks: the cost of deploying probes and the risk of flooding the network with monitoring traffic, which can introduce biases into the measurements (e.g., increased packet losses). The second approach utilizes passive measurements that are periodically taken at different points of the network without actively injecting traffic. The passive approach can be applied at different levels, starting from the physical level where the signal and noise powers are measured to the application level where logs are collected, passing by the network interface card where tools like Tcpdump and Wireshark [3] collect and store copies of packets that are seen either in the outgoing direction or the incoming direction.

This work has been supported by the French government, through the UCA-JEDI Investments in the Future project managed by the National Research Agency (ANR) with the reference number ANR-15-IDEX-01.

The work presented here falls within the passive measurement approach. Specifically, one type of passive measurement that is widely available, inexpensive to collect, and strongly correlated with network QoS is web browsing performance. Upon each page visit, web browsers provide via internal APIs, such as the Navigation and Resource Timings API [4], a set of measurements that can be passively read by any web extension or web script to shed light on the timing of the different events that compose the rendering process of the web page. For instance, one can get access to the timing of events like the connection to the server, the DNS resolution for the IP address of the server, the download of the page's objects, and the rendering of these objects on the screen of the user. Previous studies (e.g., [5], [6]) have shown a clear link between browsing metrics and underlying network performance. Given that web browsing constitutes a significant portion of total web traffic, and given the popularity of the web in the Internet, our hypothesis is that these measurements carry signatures of network performance, so we aim here to study their capacity to measure the network and troubleshoot it in case of service degradation. We are mainly motivated by the high cost of active monitoring solutions and the lack of a universal solution to troubleshoot network performance issues.

The goal of this work is to leverage web browsing metrics to infer network quality of service directly from within the browser, without relying on active measurements. We follow a data-driven controlled-experimentation approach backed by machine learning. We operate within a controlled network environment to simulate various network conditions. Once a network scenario is configured, locally downloaded web pages are served via a server and opened in a browser. Web browsing metrics are then collected using a browser extension, providing insights into network performance. Differently from our previous works on the topic [5], [7], [8], we combine here three novel aspects: (i) a rich list of tens of thousands of web pages to visit, proposed in [9], that includes both landing and internal web pages and that is deemed to better represent the web content nowadays, (ii) several network degradations at a time, including WiFi degradation, WAN degradation and CPU issues, and (iii) end-to-end network performance measurements. Up to now our earlier work was only limited to either single anomaly at a time, or simple network scenarios not including both WiFi or WAN; hence the need for end-to-end performance measurements to capture the total view of the
network as seen by the end user. To add to that, the number of experiments in the current study is two orders of magnitude higher than the ones we conducted in our previous studies. Over this rich dataset that we make available in [10] together with the code of the experiments, we carry out an evaluation of the correlation between the web performance metrics, showing that only a subset of them presents a strong correlation with the total web experience. We then train machine learning algorithms to predict end-to-end and in-network performance metrics to show that metrics like the WAN delay and the upload speed can be better predicted than the others (with percentage errors lower than 10%) while other metrics such as the download speed, the CPU load, the fading level and the WiFi load-level show prediction percentage errors of around 50%. We believe our models form the basis for a light-weight monitoring solution that can run in an extension of the browser of end users and shed light on the quality of service provided by the network upon each page visit without the need to probe the network for this information or run dedicated tools.

The paper is organized as follows. The second section focuses on the analysis of web pages, starting with a presentation of the dataset used in this study. The third section outlines the experimental setup, including the definition of network scenarios, the ground truth, and the extension we used to collect the browsing data. The following section describes the methodology, presenting a first analysis of the data and explaining the models used and the evaluation criteria. The fifth section summarizes the results for the different models. Finally, the last section provides the conclusion and suggests potential directions for future research.

## II. VISITED WEB PAGES

We utilize a large dataset of webpages, including both landing and internal pages. This dataset is based on the Hispar list, which dates back to 2020 and contains the 100k most visited landing and internal webpages on the web [9]. We build an updated version of the Hispar list, as many of the original websites are no longer accessible. In total, 43k web pages are included in our study, comprising 23k landing pages and 20k internal pages. These pages are downloaded and stored locally using `wget` [11], then replicated on our platform to be served to our web client with the help of an Nginx server [12].

We perform clustering on the web pages to make sure that each experimented scenario includes representative pages. The clustering was designed to separate the web pages based on their structure and size, as these factors can significantly impact web page rendering. The seven features used for clustering are therefore the total size of the page, the DOM depth, the number of images, paragraphs, lists, links and scripts. We perform a t-SNE projection of the obtained clusters, as can be seen in Figure 1. Then we perform a hierarchical clustering using the Ward linkage method on the t-SNE result and establish 4 clusters that we color differently in Figure 1. We choose the Ward linkage and cut the Ward dendrogram at a distance of 110, as this provided well-balanced clusters in terms of population and good inter-cluster separation.

<figure><img src="image_2.png" /><figcaption>Fig. 1. T-SNE projection of the data with perplexity parameter set to 120.</figcaption></figure>

## III. THE EXPERIMENTAL SETUP

We build a setup that allows us to automatically generate and control virtual network scenarios using Mininet [13] and its Mininet-WiFi variant [14]. We browse the locally replicated web pages, collect ground truth metrics on network performance using iPerf3 and ping (download speed, upload speed, Round-Trip Time, etc), and gather passive browser metrics through a browser extension, including webpage loading times, device data, and network-related information.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Mininet-WiFi topology.</figcaption></figure>

### A. Network scenarios and ground truth

We choose the Mininet-WiFi framework [14] for our experimentation to have a fully controlled environment with tunable network conditions, including both WiFi and WAN elements, together with virtual machines to host our client and web server. We implement the topology depicted in Figure 2: an Nginx web server deployed on a Mininet host serves the pages downloaded locally to a client running a Chrome browser on another Mininet host. The latter is connected to the Nginx server via a WiFi access point followed by an emulated wired link representing the WAN network part.

For the client and server hosts, we control CPU availability. This allows us to study how computational constraints, combined with network conditions, influence the performance of web page loading. On the wired link between the server and the access point, we vary three parameters in the download direction (from server to client): delay, packet loss, and bandwidth. For the access point, we control two parameters. The first parameter is the fading range, which represents the strength of the WiFi signal and thus controls the quality of the connection. The second parameter is the medium availability of the WiFi, which models the amount of WiFi resources available to our web client, assuming the rest of the WiFi resources being consumed by other interfering traffic. For this, we
introduce a second client connected to the access point. When medium availability is at its highest, the second client remains idle, generating no additional traffic. As medium availability decreases, the second client generates increasing local UDP traffic with the iPerf tool, hence simulating interference on the WiFi network. The level of traffic is adjusted dynamically to reflect different levels of medium availability. We note here that the WiFi we emulate is based on the 802.11g technology, thus has a maximum physical bitrate equal to 54 Mbps.

Below are the different values used for each parameter:

* Server CPU availability (%): 100, 70, 40, 10.

* Client CPU availability (%): 100, 70, 40, 10.

* Wired link delay (ms): 0, 10, 50, 100, 400.

* Wired link loss (%): 0, 0.1, 0.5, 1, 5, 10, 20.

* Wired link bandwidth (Mbits/s): 100, 50, 10, 5, 2, 1.

* WiFi fading range: 1, 2, 4.

* WiFi medium availability (%): 100, 70, 30, 15.

With these parameters, we generate the network scenarios by exhaustively combining all possible values of each parameter. This allows us to explore a wide range of network scenarios, resulting in a total of 40,320 unique configurations. Each scenario is assigned a specific ID, which allows for easy identification and tracking throughout the experimentation process. By generating such a comprehensive grid of scenarios, we can simulate various network conditions, including cases where multiple anomalies occur simultaneously, enabling detailed analysis of compound effects on network performance.

For each combination of parameters that defines a scenario, we configure the corresponding Mininet Wi-Fi topology. Once the topology is set up, we collect ground-truth measurements using *iPerf* and *ping*. Specifically, we measure the TCP bandwidth to the server in both the uplink and downlink directions, and assess the average round-trip time (RTT) and the packet loss rate using *ping*. Then we move on to web traffic generation. For each scenario and to ensure both a reference baseline and traffic diversity between scenarios, we load four fixed web pages that represent the different clusters, along with four variant web pages, each randomly sampled from each of the clusters. The process is repeated for all scenarios.

## B. Browser Extension Metrics

For each page visited, we use a Chrome browser equipped with an extension that collects various metrics from three distinct APIs. The first API is the Performance API [4], which provides rendering metrics, such as: page load time (load), time to first byte (ttfb), redirect time, DNS resolution time, connection time, request time, response time, DOM load time, DOM parsing time, DOM script execution time, content loaded time, DOM subresource loading time, and overall load time. The second API is the Chrome API [15], which provides detailed information about the device's CPU and memory. It reports data such as the CPU name, the architecture, the number of processors, as well as various CPU usage statistics, including idle, kernel, total, and user usage. Additionally, it provides system memory and available memory metrics. The third API used is the Network Information API [16],

which offers network-related data such as browser estimation of the round-trip time (RTT), connection type, protocol, and downlink speed. Most often, these values are very approximate and high-level estimations of the corresponding metrics.

Once the page is opened in the Chrome browser, an automatic click is made on the extension button, and the collected web performance metrics are saved into a MongoDB database together with the ground truth. After the four fixed and four variant web pages are loaded in series, we move to a new network scenario, repeat the iPerf and ping tests, and browse again the same reference four pages and four new ones randomly selected. We continue like this until all 40,320 scenarios are experimented with.

## IV. DATA ANALYSIS METHODOLOGY

Our aim is to assess the capacity to predict network performance directly and solely from passive measurements available in the browser during web page loading and related to device performance issues. For this, we follow a data-driven approach where we solve a regression problem. The inputs are the passive measurements collected with our web extension and the outputs are both the ground-truth end-to-end performance metrics obtained with *iPerf* and *ping* and the parameters of the anomalies we injected into *Mininet*. We will consider several models: XGBoost, Support Vector Machine (SVM) and Convolutional Neural Networks (CNN).

### A. Analysis of web measurements

Figure 3 presents the Pearson correlation matrix for the previously mentioned extension metrics, including an approximation of the Speed Index that we derived from the loading metrics of the Performance API (referred to as *rumsiricprox* in the figure). The Speed Index (which we will denote *RUMSI* hereafter) is a key web performance metric that evaluates how quickly the content of a page becomes visually complete during loading, focusing on the user experience and only considering the visible part of the page [17]. From this matrix we can observe that the metrics with the highest correlation to the rest are the Speed Index and the Page Load Time. Conversely, the metrics related to CPU usage provided by the Chrome API, exhibit low correlation with the other metrics, but still show strong inter-correlation among themselves.

Figure 4 shows the Speed Index (RUMSI) distribution over all experiments. The figure reveals that most web pages load within 50 seconds. However, only half of the pages achieve a Speed Index below 3 seconds, indicating that the other half can be safely considered as corresponding to abnormal scenarios with long loading times <fnref n="1" />. Our dataset thus presents a well-balanced distribution between normal and abnormal scenarios [10]. This balance guarantees robust model learning, where anomalies are neither neglected due to their rarity, nor submerged by the majority normal class.

To quantify how effectively a feature can differentiate between normal and abnormal scenarios, we introduce the

<footnote n="1">¹Inline with Google recommendation at https://developer.chrome.com/docs/lighthouse/performance/speed-index</footnote>
<figure><img src="image_4.png" /><figcaption>Fig. 3. The Pearson correlation matrix of the extension metrics.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Fig. 4. The Speed Index distribution.</figcaption></figure>

concept of separation power. The separation power of a feature quantifies its ability to distinguish between normal and abnormal scenarios by studying the density distributions of this feature under the two types of scenarios, *P* and *Q*. A feature with high separation power is when the two distributions differ, it is of low separation power when the two distributions look similar. A common formula for the separation power is the following $SP = 1 - \int \min\{P(x), Q(x)\} dx$, where *SP* is a real number between 0 and 1, with *SP* = 0 indicating complete overlap (the feature cannot separate the scenarios between normal and abnormal) and *SP* = 1 indicating no overlap (the feature can perfectly separate the scenarios).

Figure 5 presents the separation power for each feature. Page load time achieves the highest separation power, exceeding 90%, indicating that it is a strong indicator for distinguishing between normal and abnormal scenarios. Following this, features such as request time, response time, DOM time, and DOM parsing time show moderate separation power, with values of *SP* ranging from 40% to 60%. Content load time and DOM subresources come next, with separation power values between 30% and 40%. Finally, features like ttfb, connect time, DOM scripts, load time, and DNS time exhibit the lowest separation power, all scoring below 10%. These results can be explained by the fact that features with good separation power, such as the request time, the response time, and the DOM time,

<figure><img src="image_6.png" /><figcaption>Fig. 5. The separation power of the loading metrics.</figcaption></figure>

are closely tied to network conditions. During these phases, essential elements required for constructing the DOM tree are downloaded from the server. When the network is degraded for any reason, these metrics are the first to suffer, stretch, and impact the total web experience of the user. In contrast, features like load time and DOM scripts are more dependent on computational resources, as they relate to executing scripts and rendering the web page from the DOM tree.

<figure><img src="image_7.png" /><figcaption>Fig. 6. The distribution of the iPerf TCP bandwidth in uplink and downlink.</figcaption></figure>

Figure 6 represents the cumulative distribution of iPerf TCP bandwidth in the uplink (left) and downlink (right) for both normal (red) and abnormal (blue) web pages. In the downlink case, the blue line has a steeper slope, indicating that most values are small and saturate around 10 Mbps, suggesting limited bandwidth for anomalous web pages. In contrast, the red line increases more gradually, and spans up to approximately 25 Mbps, which is an indication of a higher download bandwidth for normal web pages. The same observation holds for the uplink case (left figure) but this time with larger iPerf values for both normal and abnormal scenarios, as bandwidth limitation is only applied in the download direction, with only the WiFi limiting performance in the upload direction.

Figure 7 shows the cumulative distributions for packet loss (left) and round-trip time (right) for both normal (Speed Index $\le$ 3, red) and abnormal (Speed Index > 3, blue) web pages. The plots clearly distinguish the two cases. For
<figure><img src="image_8.png" /><figcaption>Fig. 7. The distributions of round-trip time and packet loss rate.</figcaption></figure>

packet loss, the anomalous pages suffer from a higher loss rate, evidenced by the slower rise of the distribution, indicating that the values are more spread out and concentrated at higher levels. In contrast, the normal group shows a lower loss rate, with the distribution rising more sharply. A similar trend is observed for the round-trip time. The abnormal group with high Speed Index exhibits significantly higher network delays while the normal group with short Speed Index maintains lower and more consistent delay values.

## V. REGRESSION ANALYSIS

We study in this section the capacity of regression techniques to predict the end-to-end performance of the network and the parameters we set in Miniet-WiFi to emulate anomalies. We aim for a prediction using only web browsing measurements passively collected with our extension.

### A. The models

XGBoost, Support Vector Machine (SVM) and Convolutional Neural Networks (CNN) are widely used machine learning models for regression tasks. XGBoost (Extreme Gradient Boosting) is a powerful gradient boosting algorithm that builds trees sequentially, with each new tree correcting errors made by the previous ones, making it highly effective for complex datasets. It is known for its speed and high performance in various predictive tasks. SVM, on the other hand, is a regression model that works by finding the optimal hyperplane that best separates the data, thus providing accurate predictions even in high-dimensional spaces. Convolutional Neural Networks (CNNs) are deep learning models designed to automatically learn spatial hierarchies of features from grid-like data, such as images, through convolutional layers, pooling, and activation functions. They excel in detecting complex patterns and structures at various levels of abstraction, without the need for manual feature extraction, making them highly scalable and effective on large datasets.

### B. Evaluation Criteria

To assess the accuracy of the predictions and their alignment with the ground truth, we use the Normalized Absolute Mean Error (NMAE). This metric is defined as $NMAE = (\frac{1}{n} \sum_{i=1}^{n} |y_i - \hat{y}_i|)/\bar{y}$, where n is the total number of observations, $\hat{y}_i$ the ground-truth values for metric y, $\bar{y}$ its predicted

values and $\bar{y}$ its mean value. The NMAE provides a normalized measure of prediction error, making it easier to interpret across different metrics with different scales.

### C. Results

We train the models using 5-fold cross-validation to ensure robust evaluation and mitigate overfitting. For SVM, the optimal parameters include $C = 1$, which controls the regularization strength, and $\epsilon = 0.1$, defining the margin of tolerance for errors in the predictions. The radial basis function (RBF) kernel is chosen to enable the model to capture non-linear relationships in the data. For XGBoost, the best configuration includes $n\_estimators = 500$, specifying the number of boosting iterations; $max\_depth = 20$, which regulates the depth of each decision tree to capture complex patterns; $learning\_rate = 0.01$, determining the step size for each iteration to ensure smooth convergence; and $subsample = 0.8$, limiting the fraction of training samples used in each tree to enhance generalization and reduce overfitting. For CNN, the optimal parameters are $learning\_rate = 0.001$, controlling the step size for the gradient descent optimizer; $dropout\_rate = 0.0$, indicating no dropout is applied to avoid unnecessary regularization; $batch\_size = 16$, defining the number of samples in each training batch; $epochs = 50$, setting the number of full passes through the dataset; $hidden\_layers = 4$, specifying four hidden layers in the architecture; $units\_per\_layer = 128$, fixing the number of neurons in each hidden layer; and $activation = ReLU$, defining the activation function used to introduce non-linearity into the network. These parameters demonstrated the best performance on the dataset across all models.

Figure 8 illustrates the prediction accuracy of the models across various metrics. XGBoost consistently outperforms SVM and CNN on most metrics, with the exception of the fading range, where SVM demonstrates slightly better performance. Notably, XGBoost achieves the highest prediction accuracy on the upload bandwidth and delay metrics. The average round-trip time (Avg RTT) is also well predicted, with an average NMAE of 19.93% for XGBoost compared to 26.83% for SVM and 21.56% for CNN. A significant performance gap is observed for the downlink bandwidth metric, where XGBoost achieves an NMAE of 43.58%, markedly better than the 70.40% recorded for SVM and 54.53% for CNN. All models exhibit, however, notably poor performance on the packet loss rate measured via ping, with NMAE values reaching 127.25% for XGBoost, 113.51% for SVM and 127.5% for CNN. For the remaining metrics, XGBoost demonstrates an error range between 43% and 66%, while SVM and CNN show a broader range, from 44% to 83%.

Figure 9 presents the NMAE of the uplink bandwidth for the XGBoost and SVM models (the two best models among the three cited above). The results indicate that the NMAE decreases as the bandwidth values increase, thus demonstrating that predictions improve for higher bandwidth ranges. For values of bandwidth between 28 and 35 Mbps, XGBoost achieves an NMAE below 5%, while SVM maintains an
<figure><img src="image_9.png" /><figcaption>Fig. 8. The NMAE of the different metrics for the three models, XGBoost, SVM and CNN.</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Fig. 9. The NMAE of the TCP uplink and downlink bandwidth per interval.</figcaption></figure>

error below 10%. Conversely, both models exhibit higher errors for bandwidth values between 0 and 7 Mbps, indicating slightly lower predictive accuracy at smaller bandwidths. The same Figure 9 shows on the right-hand side the performance of XGBoost and SVM for the downlink case. Prediction errors are larger, as more factors impact bandwidth in the download direction in our experiments, making its prediction a more difficult task. Here again, XGBoost shows a consistent improvement in performance as the bandwidth increases, but this error does not get below 30%. In contrast, SVM exhibits an initial drop in performance after the first interval, followed by an upward trend as the bandwidth increases.

## VI. CONCLUSION

We present a data-driven method for leveraging browser-level measurements to predict network conditions. Our experimental setup is implemented using Mininet-WiFi and an Nginx server delivering the locally downloaded web pages. We perform regression on the browser measurements to infer the network-related performance metrics. We evaluate three models: XGBoost, SVM, and CNN. The XGBoost model achieves the best performance in predicting most metrics, particularly excelling in the prediction of the uplink bandwidth, delay, and average round-trip time. In future work, we will investigate further the troubleshooting problem through a classification problem. The goal will be to expand the used approach and classify the origins of network related anomalies.

## REFERENCES

[1] V. Mohan, Y. J. Reddy, K. Kalpana et al., "Active and passive network measurements: a survey," *International Journal of Computer Science and Information Technologies*, vol. 2, no. 4, pp. 1372–1385, 2011.

[2] "iperf - the ultimate speed test tool for tcp, udp and sctp." [Online]. Available: https://iperf.fr/iperf-download.php

[3] P. Goyal and A. Goyal, "Comparative study of two most popular packet sniffing tools-tcpdump and wireshark," in *International Conference on Computational Intelligence and Communication Networks*, 2017.

[4] "Navigation and resource timings." [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/Performance/Navigation_and_resource_timings

[5] I. Taibi, Y. Hadjadj-Aoul, and C. Barakat, "When deep learning meets web measurements to infer network performance," in *IEEE Annual Consumer Communications & Networking Conference (CCNC)*, 2020.

[6] A. S. Asrese, S. J. Eravuchira, V. Bajpai, P. Sarolahti, and J. Ott, "Measuring web latency and rendering performance: Method, tools, and longitudinal dataset," *IEEE Transactions on Network and Service Management*, vol. 16, no. 2, pp. 535–549, 2019.

[7] I. Taibi, Y. Hadjadj-Aoul, and C. Barakat, "Leveraging web browsing performance data for network monitoring: a data-driven approach," in *GLOBECOM 2022 - 2022 IEEE Global Communications Conference*, 2022, pp. 6121–6126.

[8] N. Kirimi, C. Barakat, and Y. Hadjadj-Aoul, "Passive network monitoring and troubleshooting from within the browser: a data-driven approach," in *International Wireless Communications and Mobile Computing (IWCMC)*, 2024.

[9] W. Aqeel, B. Chandrasekaran, A. Feldmann, and B. M. Maggs, "On landing and internal web pages: The strange case of jekyll and hyde in web performance measurement," in *Proceedings of the ACM Internet Measurement Conference*, ser. IMC '20. New York, NY, USA: Association for Computing Machinery, 2020, p. 680–695. [Online]. Available: https://doi.org/10.1145/3419394.3423626

[10] "Experimentation code and dataset." [Online]. Available: https://github.com/Sanaa-del/wemon

[11] "Wget." [Online]. Available: https://www.gnu.org/software/wget/

[12] "Nginx: the high-performance web server and reverse proxy." [Online]. Available: https://nginx.org/en/

[13] "An instant virtual network on your laptop (or other pc)." [Online]. Available: http://mininet.org/

[14] R. R. Fontes, S. Afzal, S. H. B. Brito, M. A. S. Santos, and C. E. Rothenberg, "Mininet-wifi: Emulating software-defined wireless networks," in *2015 11th International Conference on Network and Service Management (CNSM)*, 2015, pp. 384–389.

[15] "Api reference - chrome for developers." [Online]. Available: https://developer.chrome.com/docs/extensions/reference/api

[16] "Network information api." [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/API/Network_Information_API

[17] T. Hoffeld, F. Metzger, and D. Rossi, "Speed index: Relating the industrial standard for user perceived web performance to web qoe," in *2018 Tenth International Conference on Quality of Multimedia Experience (QoMEX)*, 2018, pp. 1–6.