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.
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:
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|
|Total Load Time|
|Number of Domains|
|Number of Resources|
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
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.
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
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%|
|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:
- Third Party Content usage by customers and generated business value –Business Monitoring
- The impact of new added Third Party Content– Development Monitoring
- The performance of Third Party Content in the client browser – Operations 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!
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.
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.