Klaus Enzenhofer About the Author

Klaus is a Senior Strategist in the Center of Excellence at CompuwareAPM. Klaus influences the strategic direction and development of application performance management solutions.. He has deep experience gleaned from years of developing and running large scale web and mobile applications for online businesses.

You only control 1/3 of your Page Load Performance!

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

 

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!

Comments

  1. Cool study. 3rd party content is a big hindrance to fast websites. It’s often hard to determine how much of a hindrance because of the complex way resources interact during page loading.

    I decided to use the Critical Path Explorer to test this. CPE was announced at Velocity Europe this week by the Page Speed team. It’s not released yet but you can get a developer preview here: https://developers.google.com/pagespeed/?velocity=1

    Looking at the critical path it shows that adserver.com has six resources on the critical path that account for ~1350 ms. But tiscover.com has four resources on the critical path that account for ~2800 ms.

    This would indicate that 2/3 of critical path time is in tiscover’s hands. But CPE is still in preview mode – so the results should be taken with a grain of salt. It would be interesting to examine this further. Perhaps you could run the no-3rd-party-content version of the page through CPE and see what is on the critical path.

    • Hi,

      Thanks for your feedback. I have tested CPE with the URL I used for my blog and adtech consumes 70 to 80% of the time till the DOM Content event. Link to image
      And here the same page without 3rd party content
      Tiscover-critical-path-without-Third-Party-Content.png

      Tiscover already did some work to make their page faster since I have recorded the session for the big timeline. The last 3rd party widget that has impact on the OnLoad event is their ad provider.

      Why does CPE stop on the DOM Content Event? Wouldn’t it be nice to see how long it takes till everything gets loaded?

  2. Thomas Wolkenstein says:

    2.8 MB third party content sounds a lot compared to 0.8 MB own content. But in this case I don’t think the user experience is impacted very much by slow third party content since the own content is rendered after 2 seconds as you can see in the video.

    Correct me if I am wrong but I dont’t think the users mind if the adds take a couple of extra seconds to load.

  3. Hi Thomas,
    The user will notice especially ads as the have impact on the first impression time. Another thing the user will notice is that the content shift-Your user starts reading the text and then all of the sudden the banner ad on the top shifts the whole content down by xx pixel and the user has to re orientate.

  4. Martin.Beo says:

    That’s why ad-block-plus is favourized in firefox ;)

    I had to deal with some pages, where you have to be quick with loading. I just turned off all the ads just to get better times. It was like: I can breath again :)

  5. Depending on 3rd party content for a predictable, performant page load is a mistake! Pages which interleave 3rd party content with site / 1st party content, are left at the mercy of the poorest performing content – the 3rd (and 4th) party content.

    Approaches to mitigate the impact of unreliable 3rd party content on both the user and measurements by other interested parties include deferring 3rd party content until after the onload event. This often represents a trade-off between increased user engagement with 1st party page content, and decreased yield for 3rd party business lines.

    Interested to see the approaches you’ll outline in your “Third Party Content Management” post.

  6. I think its basically a design flaw rather than loading issue.
    If you want to load third party stuff , load it inline, so that browser makes only one call and that should be call which spreads your information.Loading inline, or loading the scripts via same domain makes more sense in these cases.

    Then there are cases where I feel people dont utilize the browser inbulit resources properly, good example for this would be google captchas vs captcha made locally via JS or someother scriptin g language which browser supports.With google captchas you make a call for every refresh and for locally bulit, captchas , there is no call at all.See the gain here.
    Then there are many such things which I have noticed in web community which I feel is terribly bad for performance,blocking of Input file type by browsers is one such example.

  7. great article
    looking forward to the next post”Third Party Content Management!”

  8. The follow up is available! Thrid Party Content Management

Comments

*


+ five = 13