You do not agree with that? Have you ever looked at the details of your page load time and analyzed what really impacts Page Load Time? Let me show you with a real life example and let me explain that in most cases you only control 1/3 of the time required to load a page as the rest is consumed by 3rd party content that you do not have under control.
Be Aware of Third Party Content
The two screenshots below show these two pages as rendered by the browser. From your own application perspective it is the exact same page – the only difference is the additional third party content. The screenshot on the left side refers to the first timeline, the screenshot on the right to the second Timeline. To make the differences easier to see I have marked them with red boxes.
The left screenshot shows the page with content delivered by your application. That’s all the business relevant content you want to deliver to your users, e.g.: information about travel offers. Over Time this page got enriched with 3rd party content such as Tracking Pixels, Ads, Facebook Connect, Twitter and Google Maps. These Third Party Components make the difference between the two page loads. Everyone can easily see that this “enrichment” has an impact on page load performance and therefore affects User Experience. Watch the video below to see how users experience the rendering of the page.
The super-fast page that finishes the download of all necessary resources after a little over two seconds is slowed down by eight seconds. Table 1 shows 5 KPIs (Key Performance Indicators) that represent the impact of the Third Party Content.
|# of Domains||# of Resources||Total Bytes||DNS [ms]||Connect [ms]|
|With Third Party Content||26||176||2856 Kb||1286,82||1176,09|
|Without Third Party Content||2||59||897 Kb||0,91||22,25|
4 Typical Problems with 3rd Party Content
Let me explain 4 typical problems that come with adding 3rd party content and why this impacts page load time.
Problem 1: Number of Resources
With every new Third Party “Feature” we are adding new resources that have to be downloaded by the browser. In this example the number of resources increased by 117. Let’s compare it with the SpeedOfTheWeb baseline for the shopping industry. The best shopping page loads at least 72 resources. If we would stick with our original page we would be the leader in this category with just 59 reources.
In addition to 117 roundtrips to download these resources it also means that the total download size of the page grows significantly. To download the extra ~2 Mb from the servers of the Third Party Content Provider your customer will need extra time. Depending on the bandwidth and latency the download time can vary and if you think of downloading the data via a mobile connection, it really can be time consuming.
Problem 2: Connection usage
Domain Sharding is a good way to enable older browsers to download resources in parallel. Looking at current modern web sites, domain sharding is often used too aggressive. But, how can you do too much domain sharding? Table 2 shows us all the domains from which we only download on or two resources. There are 17 domains for downloading 23 resources – domain sharding at it’s best!
And what about connection management overhead? For each domain we have to make a DNS look up so that we know to which server to connect. The setup of a connection also needs time. Our example needed 1286 ms for DNS lookup and another 1176 ms for establishing the connections to the server. As almost every domain refers to Third Party Content you have no control over them and you cannot reduce them.
Problem 3: Not minified Resources
I have put the whole file content into a compressor tool and the size can be reduced by 20%. And again you cannot do anything about it.
Problem 4: Awareness of bad response times of Third Party Content Provider
Within your datacenter you monitor the response times for incoming requests. In case the performance of the response time is decreasing you will be alerted. Within your data center you have the awareness that you know when something is going wrong and you can do something about it. But what about Third Party Content? Do Facebook, Google, etc. send you alerts if they are experiencing bad performance? You will now say that these big providers will never have bad response times, but take a look at the following two examples.
This timeline shows us a very long running resource request. You will never see this 10698 ms lasting request in your datacenter monitoring environment as the resources is provided by Facebook one of the Third Party Content providers of this page.
The second example shows the timeline of a different page but with the same problem. On this page not only Facebook is slow but also Google+. The slow requests have durations from 1.6 sec to 3.5 sec. and have a big impact the experience of your user. The problem with the user experience is that the bad experience is not related to the Third Party Content Provider but to YOU!
What we have seen is that Third Party Content has a big impact on User Experience. You cannot rely on big 3rd party providers to always deliver high performance. You should be aware of the problems that can occur if you put Third Party Content on your page and you really have to take action. In this blog I have highlighted several issues you are facing with Third Party Content. What should be done to prevent these types of problems will be discussed in my next blog -Third Party Content Management!