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

When analyzing web page load times we can use tools such as Dynatrace, Firebug or PageSpeed. The following two screenshots show timeline views from dynaTrace AJAX Edition Premium. The timelines show all network downloads, rendering activities and JavaScript executions that happen when loading almost exactly the same page. The question is: Where does the huge difference come from?

Timeline without Third Party Content

Timeline with 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.

Screen shot of the page without and with highlighted Third Party Content
Screen shot of the page without and with highlighted Third Party Content

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 resources.

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.

URL Count
www.facebook.com 2
plusone.google.com 2
www.everestjs.net 2
pixel2823.everesttech.net 2
pixel.everesttech.net 2
metrics.tiscover.com 2
connect.facebook.net 1
apis.google.com 1
maps.google.com 1
api-read.facebook.com 1
secure.tiscover.com 1
www.googleadservices.com 1
googleads.g.doubleclick.net 1
ad-dc2.adtech.de 1
csi.gstatic.com 1
ad.yieldmanager.com 1
ssl.hurra.com 1

Problem 3: Not minified Resources

You are trying to reduce the download size of your page as much as possible. You have put a lot of effort into your CI process to automatically minify your JavaScript, CSS and Images and then you are forced to put for example ads on your pages. On our example page we can find an ad provider that does not minify JavaScript. The screen shot below shows part of the uncompressed JavaScript file.

Uncompressed JavaScript Code of Third Party Content Provider
Uncompressed JavaScript Code of Third Party Content Provider

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.

Timeline with slow Facebook request
Timeline with slow Facebook request

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.

Timeline with slow Facebook and Google+ requests
Timeline with slow Facebook and Google+ requests

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!

Conclusion

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!