Third Party Content Management applied: Four steps to gain control of your Page Load Performance!

Today’s web sites are often cluttered up with third party content that slows down page load and rendering times, hampering user experience. In my first blog post, I’ve presented how third party content impacts your website’s performance and identified common problems with its integration. Today I want to share the experience I have made as a developer and consultant with the management of Third Party Content. In the following, I will show you Best Practices for integrating Third Party Content and for convincing your business that they will benefit from establishing Third Party Management.

First the bad news: as a developer, you have to get the commitment for establishing Third Party Management and changing the integration of Third Party Content from the highest business management level possible – best is CEO level. Otherwise you will run into problems to implement improvements. The good news is that, from my experience, this is not an unachievable goal – you just have to bring the problems up the right way with hard facts. Let’s start our journey towards implementing third party content management from two possible starting points I have seen in the past: The first one is triggered if someone from the business has a bad user experience and wants to find out who is responsible for the slow pages. The second one is that you as the developer know that your page is slow. No matter where you are starting the first step you should make is to get exact hard facts.

Step 1: Detailed Third Party Content impact analysis

For a developer this is nothing really difficult. The only thing we have to do is to use the Web Performance Optimization Tool of our choice and take a look at the page load timing. What we get is a picture like the screenshot below. We as developers immediately recognize that we have a problem – but for the business this is a diagram that needs a lot of explanation.

Timeline with Third Party Content
Timeline with Third Party Content

As we want to convince them we should make it easier to understand for them. Something that from my experience works fine, is to take the time and implement a URL-Parameter that turns off all the Third Party Content for a webpage. Then we can capture a second timeline from the same page without the Third Party requests. Everybody can now easily see that there are huge differences:

Timeline without Third Party Content
Timeline without Third Party Content

We can present these timelines to the business as well but we still have to explain what all the boxes, timings, etc. mean. We should invest some more minutes and create a table like the one below, where we compare some main Key Performance Indicators (KPI).

KPI Page with TPC Page without TPC Difference
First Impression Time
Onload Time
Total Load Time
JavaScript Time
Number of Domains
Number of Resources
Total Pagesize

As a single page is not representative we prepare similar tables for the 5 most important pages. Which pages these are depends on your website. Landing pages, product pages and pages on the “money path” are potentially interesting. Our Web Analytics Tool can help us to find the most interesting pages.

Step 2: Inform business about the impact

During step 1 we have found out that the impact is significant, we have collected facts and we still think we have to improve the performance of our application. Now it is time to present the results of the first step to the business. From my experience the best way to do this is a face to face meeting with the high level business executives. CEO, CTO and other business unit executives are the appropriate attendees.

The presentation we give during this meeting should cover the following three major topics:

  • Case Study facts from other companies
  • The hard facts we have collected
  • Recommendations for improvements

Google, Bing, Amazon, etc. have done some case studies that show the impact of slow pages to the revenue and the users’ interaction with the website. Amazon for example found out that a 100 ms slower page reduces the revenue by 1%. I have attached an example presentation to this blog which should provide some guidance for our presentation and contains some more examples.

After this general information we can show the hard facts about our system and as business now is aware of the relation between performance and revenue they normally listen carefully. Now we are no longer talking about time but money.

At the end of our presentation we make some recommendations how we can improve the integration of Third Party Content. Don’t be shy – no Third Party Content plugin is untouchable at this point. Some of the recommendations can only be decided by the business and not by the development. Our goals for this meeting are that we have the commitment to proceed, that we get support from the executives when discussing the implementation alternatives, and that we have a follow up meeting with the same attendees to show improvements. What would be nice is the consent of the executives to the recommended improvements but from my experience they commit seldom.

Step 3 Check Third Party Content implementation alternatives

Now as we have the commitments, we can start thinking about integration alternatives. If we stick to the standard implementation the provider recommends, we won’t be able to make any improvements. We have to be creative and always have to try to create win-win situations! Here in this blog I want to talk about 4 Best Practices I have encountered the past.

Best Practice 1: Remove it

Every developer will now say “Ok, that’s easy”, and every business man will say “That’s not possible because we need it!” But do you really need it? Let’s take a closer look at social media plugins, tracking pixels and ads.

A lot of websites have integrated Social Media Plugins like Twitter or Facebook. They are very popular these days and a lot of webpages have integrated such plugins. Have you ever checked how often your users really use one of the plugins? A customer of ours had integrated five plugins. After 6 months they checked how often each of them was used. They found out that only one was used by other people than the QA-department which checked that all of them are working after each release. With a little investigation they found out that four of the five plugins could be removed as nobody simply used it.

What about Tracking Pixel? I have seen a lot of pages out there that have not only integrated one tracking pixel but five, seven or even more. Again, the question is: do we really need all of them? It does not matter who we ask, we will always get a good explanation why a special pixel is needed but stick to the goal of reducing it down to one pixel. Find out which one can deliver most or even all of the data that each department needs and remove all the others. Problems we might run into will be user privileges and business objectives that are defined for teams and individuals on specific statistics. It costs you some efforts to handle this but at the end things will get easier as we have only one source for our numbers and we will stop discussing about which statistics delivers the correct values and from which statistics to take the numbers as there is only one left. Once at a customer we have removed 5 Tracking Pixels with a single blow. As this led to incredible performance improvements, their marketing department made an announcement to let customers know they care about their experience. This is a textbook example for creating a win-win-situation as mentioned above.

Another Third Party Content that is a candidate for removal are banner ads. Businessmen will now say this guy is crazy to make such a recommendation, but if your main business is not earning money with displaying ads then it might be worth to take a look at. Taking the numbers from Amazon that 100 ms additional page load time are reducing the revenue by one percent and thinking of the example page where ads consume round about 1000 ms of page load time – 10 times as much. This would mean that we lose 10 * 1% = -10% of our revenue just because of ads. The question now is: “Are you really earning 10% or more of your total revenue with ads?”. If not you should consider removing ads from your page.

Best Practice 2: Move loading of resources back after the Onload-event

As we now have removed all unnecessary Third Party Content , we still have some left. For the User Experience, apart from the total load time, the first impression and the Onload-time are the most important timings. To improve these timings we can implement lazy loading where parts of the page are loaded after the Onload event via JavaScript several libraries are available that help you implementing this. There are two things you should be aware of: the first thing is that you are just moving the starting point for the download of the resources so you are not reducing the download size of your page or the number of requests. The second thing is that lacy loading only works when JavaScript is available in the users’ browser. So you have to make sure that your page is useable without JavaScript. Candidates for moving the download starting point back are plugins that only work if JavaScript is available or are not vital to the usage of the page. Ads, Social Media Plugins, Maps, etc. are in most cases such candidates.

Best Practice 3: Load on user click

This is an interesting option if you want to integrate a social media plugin. The standard implementation for example of such a plugin looks like the picture below. It consists of a button to trigger the like/tweet action and the number of likes / tweets.

Twitter Facebook button integration example
Twitter Facebook button integration example

To improve this, the question that has to be answered is-Do the users really need to know how often the page was tweeted, liked, etc.? If the answer is no we can save several requests and download volume. All we have to do is deliver a link that looks like the action button and if the user clicks on the link we can open a popup window or an overlay where the user can perform the necessary actions.

Best Practice 4: Maps vs. static Maps

This practice focuses on the integration of maps like Google Maps or Bing Maps on our page. What can be seen all around the Web are map integrations where the maps are very small and only used to give the user a hint, where the point of interest is located. To show the user this hint, several JavaScript-files and images have to be downloaded. In most cases the user does not need to zoom or reposition the map and as the map is small it is also hard to use. Why not using the static map implementation Bing Maps and Google Maps are offering? To figure out the advantages of the static implementation I have created two html-pages which show the same map, one uses the standard implementation and the other the static implementation. Find the source files here.

After capturing the timings we get the following results:

KPI Standard Google Maps Static Google Maps Difference in %
First Impression Time 493 ms 324 ms -34%
Onload Time 473 ms 368ms -22%
Total Load Time 1801 ms 700 ms -61%
JavaScript Time 563 ms 0 ms -100%
Number of Domains 6 1 -83%
Number of Resources 43 2 -95%
Total Pagesize 636 Kb 77 Kb -88%

When we take a closer look at the KPIs we can see that every KPI for the Static Google Map implementation is better. Especially when we look at the timings KPIs we can see that the first impression and the Onload time are improving by 34% and 22%. The total load time decreases by 1 sec which is 61% less and this has really a big impact on the users experience.

Some people will argue that this approach is not applicable as they want to offer the map controls to their customers. But remember Best Practice 3 – Load on user click: As soon as the user states his intention of interacting with the map by clicking on it, we can offer him a bigger and easier-to-use map by opening a popup, overlay or a new page. The only thing the development has to do is to surround the static image with a link tag.

Step 4: Monitor the Performance of your Web application/Third Party Content

As we need to show improvements in our follow-up meeting with business executives, it is important to monitor how the performance of our website evolves over the time. There are three things that should be monitored by business, operations and development:

  1. Third Party Content usage by customers and generated business value –Business Monitoring
  2. The impact of new added Third Party Content– Development Monitoring
  3. The performance of Third Party Content in the client browser – Operations Monitoring

Business Monitoring:

An essential part of the business monitoring should be a check whether the requested Third Party features contributes to business value. Is the feature used by the customer or does it help us to increase our revenue? We have to ask this question again and again – not only once at the beginning of the development, but every time when business, development and operations meet to discuss web application performance. If we ever can state: No, the feature is not adding value – remove it as soon as possible!

Operations Monitoring:

There are only a few tools that help us to monitor the impact of Third Party Content to our users. What we need is either a synthetic monitoring system like Gomez and Keynote provide, or a monitoring tool that really sits in our users’ browser and collects the data there like Dynatrace UEM.

Synthetic monitoring tools allow us to monitor the performance from specified locations all over the world. The only downside is that we are not getting data from our real users. With Dynatrace UEM we can monitor the Third Party Content performance of all our users wherever they are situated and we get the real experienced timings. The screenshot below shows a dashboard from Dynatrace UEM that contains all the important data from the operations point of view. The pie chart and the table below indicate which Third Party Content provider has the biggest impact on the page load time and the distribution. The three line charts on the right side show you the request trend, the total page load time and the Onload time and the average time that Third Party Content contributes to your page performance.

Dynatrace Third Party Monitoring Dashboard
Dynatrace Third Party Monitoring Dashboard

Development Monitoring:

A very important thing is that the development has the ability to compare the KPIs between two releases and the differences between the pages with and without Third Party Content. If we have already established Functional Web Tests which integrate with a web performance optimization tool that delivers us the necessary values for the KPIs. We just have to reuse the switch we have established during Step 1 and run automatic tests on the pages we have identified as the most important. From this moment on we will always be able to automatically find regression caused by Third Party Content.

We may also consider enhancing our switch and make each of the Third Party plugins switchable. This allows us to check the overhead a new plugin adds to our page. It also helps us when we have to decide which feature we want to turn if there are two or more similar plugins.

Last but not least as now business, operation and development have all the necessary data to improve the user experience, we should meet up regularly to check the performance trend of our page and find solutions to upcoming performance challenges.


It is not a big deal to start improving the Third Party Content integration. If we want to succeed it is necessary that business, development and operations work together, we have to be creative, we have to make compromises and we have to be ready to go different ways of integration – never stop aiming for a top performing website! If we take things seriously we can improve the experience of our users and therefore increase our business.

Klaus is a Senior Technology Strategist in the Center of Excellence at Dynatrace. 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.