Prateek Aggarwal

Deep Dive into WebPagetest Results using Wireshark

Blog Post created by Prateek Aggarwal Employee on Sep 27, 2016

Ever wondered what could be causing your webpages to load slowly? How to identify and Troubleshoot Web Performance issues?

Continuously monitoring the website for web performance is essential and this is exactly what we provide as a part of MDS (Managed Delivery Service) team.


Factors that affect website performance


Well, there can be a lot of factors which can result in slow performance of your website. Some of these factors include High DNS resolution time, High response time from the origin for the base page or for an embedded object which is coming from a 3rd party domain, objects blocking the critical rendering path of the website and Network congestion. All these factors can result in high page load time. The need arises for identifying and troubleshoot such issues.


Identifying and Troubleshooting Performance Issues


In order to measure the performance of website, running a test in is one of the most common way to find out how much time different objects such as HTML, CSS, Java scripts and images are taking to load. The benefit is that we can run this test from various locations and see how the website is performing from different geographical locations.

Another widely used tool is Wireshark. Wireshark is a packet sniffing tool which is extremely helpful in identifying network congestion or latency. It gives details on how the request and response looks like at each layer of the OSI model.

Now let’s say that performance of the website is extremely slow and running a webpage test, we see that for some objects there is high TTFB and for some other objects there is high content download times. High TTFB, download time values suggest that there is either high response time from the server or Network congestion in between. Also, high TTFB can sometimes be due to high DNS resolution time. Running a normal WPT will not give you the details such as IP addresses of the DNS server which is causing delays or also the IP addresses of the server to which the request is being forwarded to until and unless we pass the IP address in the HTTP response headers. We can also see objects that have high content download times in WPT but we will not be able to determine what is causing the high download times. Also, there can be a scenario that there is intermittent performance degrade for a website and running multiple tests in WPT shows objects having high download times in some tests and same objects showing very low download times in other test instances. Capturing a packet trace and analyzing it in Wireshark does show this information which can be more meaningful.

Also, allows us to take a tcpdump for every test that we run. This tcpdump is a packet capture which can be analyzed using Wireshark. By checking this option in the advance settings, WPT will also capture a packet trace. The good thing is that if we run more than 1 test, the tcpdump will be captured for all the tests.




Common issues which can be analyzed using Wireshark by taking a tcpdump


- High DNS lookup time


In case you run into issues where you are seeing high DNS lookup time in WPT causing overall page load time to increase, you can analyze the corresponding tcpdump in Wireshark to see which DNS server is causing latency.



In the above screenshot, you can see the DNS took approximately 0.9 seconds to respond back with the answer to DNS query.


Also, you can take a look at whether all the domains in the base HTML are being pre-fetched or not. DNS prefetching will help in reducing the time for DNS lookup and hence would improve overall page load time.




- High TTFB and content download times


In case you run into issues where you are seeing high TTFB or content download times in WPT causing overall page load time to increase, you can analyze the corresponding tcpdump in Wireshark to see if there are any TCP retransmissions or Duplicate acknowledgements indicating Network congestion. TCP retransmissions usually happen when an acknowledgement is not received for a particular segment within a specified time. The sender will assume the segment was lost in the network, and will retransmit the segment.



TCP retransmissions can be appear in the Network due to multiple reasons such as Duplex mismatch between the sender and the receiver. In most modern equipment auto negotiation works correctly. Retransmissions can also appear in network if there are large number of broadcasts. These can really cause high latency.

In order to avoid retransmissions in the Network, few best practices are to look for large number of broadcasts at the time of the issue, make use of selective acknowledgements (SACK) and Nagle’s Algorithm.