We increasingly rely on third-party scripts to deliver some of the business-critical features of our sites – analytics, adverts, multi-variant testing, comments, recommendations, retargeting, social sharing etc.
Often these scripts get added with the seemingly innocent “it’s just a snippet of JavaScript,” but they can have a dramatic impact on performance, from slowing the page down to completely breaking it when a third party has availability issues.
Despite this explosion in third-party components there’s little information on the value they deliver, how they interact with our sites, and what their impact on performance is.
In this session we’ll share the insights we’ve gained from analysing the impact third-party scripts are having on performance of the sites we monitor, the value they deliver, and how our clients manage them.
We’ll look at which third parties are the most popular, how they interact with our pages, and how consistent their performance is.
Attendees will come away with a better understanding of third-party performance, and pointers to how to make informed decisions when choosing third parties.
We’re not developers or operations, we’re performance consultants. That gives us a fantastic perspective on real challenges faced by hundreds of online businesses, not just because we analyse their sites but because we hear from developers through to executives about strategy, goals and challenges. Being independent we also tend to get told the unbiased truth (and it isn‘t always pretty!).
One problem that has been cropping up with increasing frequency across all of our customers is that of third-party assets and the performance impact that they may be having.
This has led us to do investigations on behalf of our clients with some interesting conclusions.
Over the next 40 minutes we will introduce our definition of third-parties, why you might be using them and the impact they are probably having om your website. We will also attempt to suggest some actions you cam take as developers, managers, website owners to take back control of your websites performance.
Critical content
HTTP Archive
8 redirects
One of the biggest challenges most of our clients face is finding the third-parties on their site. All third-parties tend to be added at go-live with little or no verification. These third-parties cam them spawn off hundreds of requests to other sites creating a sprawling mess of dependencies.
This request map shows in blue the requests from the root domain just right of centre. The red star to its left shows over 20 requests initiated by an advertising provider!
In this case, advertising is the sites sole source of revenue. Thus it is critical that advertising networks are on the page. For your sites there will be other content that is considered important to business success (hopefully all of them).
We’re generally familiar with the risks involved with blocking third-parties: pages not rendering.
Steve Souder discovered that while a windows machine will block render for 20 seconds when a blocking resource is unreachable – osx machines will do nothing for over a minute. If you think any of your customers will wait over a minute to load your site then…
What hasn‘t really been done yet is studying the general performance impact of third-parties when they are well-behaved (ie not failing).
So we decided to do exactly that!
MVT is easy target because it has a direct impact on user experience, it drives huge amounts of revenue AND is easy to detect as it is generally client-side.
Worth noting that there are alternatives to client-side – companies like SiteSpect offer a reverse-proxy solution and you can do it at server-side.
So let's use a familiar metric – SpeedIndex. This chart plots a histogram of sites in httparchive by the percentage which achieved the SpeedIndex on the x axis. There‘s a normal distribution with the median around 3000 which feels about right.When we overlay the same data for sites with client-side MVT in the page there is a clear histogram shift to a higher speedindex and thus a worse perceived performance!
So to see what that means we picked on an example site – jcpenney.
In order to determine the impact of maximise on the page performance we removed it from the site. We ran 9 tests each of the homepage with and without maximise and this video shows the median run from each test compared.
Pageload +1 second / 20%
SpeedIndex + 1,300 / 38%
Clearly there is a significant impact on render performance. Also note that mvt scripts are not cached so this overhead AMD potential delay is on every page where maximise is instrumented.
Ok so we know that it has a performance impact, but at least it is predictable and consistent so we can take account of it right?
Well one of the nice things about having a synthetic monitoring solution is that we have data to inspect. We measure the performance of 100M pages a month and a significant number of them use mvt.
This chart shows the data for a day from a test node in London.
The markers represent test results and the colour is the carrier on which the test ran.
When we zoom in on the time period and break the results down by customer you can see that multiple customers were affected by this and it occurred over peak UK trading hours from 7 until 8:30!
This chart shows the waterfall chart for the homepage of a major uk airline whose site was effectively unavailable intermittently for over an hour.
Include stories of
Third-party script installed via tag manager broken login for all their international customers
So given that third-parties can pose so much risk… how do we manage them?
Tag managers take pain away from managing third-parties. Well, they take pain away form IT. You instrument the tag manager code once on your site and then anyone with access to the configuration can add and remove arbitrary third-party tags.
This makes it more simple to manage and reduces deployment time of tags, but is it the silver bullet?
Perhaps unsurprisingly, sites with tag management have more objects on them than the average site in httparchive. On just said that it makes it easier to add tags spnwe would expect that.
One other benefit of tag managers is that they should ensure that your tags are loaded asynchronously. What that means os that while the number of requests increases that shouldn‘t have an impact on perceived performance.
SELECT AVG(reqTotal) as meanReqs,AVG(renderStart) as meanRenderStart,AVG(onLoad) as meanOnLoad,AVG(fullyLoaded) as meanFullyLoaded,AVG(SpeedIndex) as meanSpeedIndex FROM [httparchive:runs.latest_pages]
WHERE rank IS NOT NULL
SELECT type,AVG(reqTotal),AVG(renderStart),AVG(onLoad),AVG(fullyLoaded),AVG(SpeedIndex) FROM [httparchive:runs.latest_pages] as pages JOIN (
SELECT pageid, type FROM (
SELECT REGEXP_EXTRACT(url,
r'(gtm\.js|tealium|brighttag|ensighten|adobedtm|satellite-|tagman|qubit).*') type, pageid
FROM [httparchive:runs.latest_requests]
WHERE REGEXP_MATCH(url, r'gtm\.js|tealium|brighttag|ensighten|adobedtm|satellite-|tagman|qubit.*')
GROUP BY pageid,type
)
GROUP BY pageid,type
) as lib ON lib.pageid = pages.pageid
WHERE rank IS NOT NULL
GROUP BY type;
Ah, so tag managers do seem to correlate with increased speedindex. Hmm.
Well tag managers are open to abuse – e.g. loading an MVT provider which requires its script to be blocking. In the case of jcpenney here…
http://requestmap.webperf.tools/render/150520_JM_4a1b8ceea5e6c8fbe3064a2b74167bea
Third-parties are like babies – they need a lot of attention and cause a lot of stress but are very rewarding
We don’t know enough – what third parties are on the site, what impact they have and what value they provide to the business.
Who’s on the site / regular analysis / audit
requestmap
What’s the business value / remove the chaff
Direct revenue generation
Insight
Marketing
Cost reduction
What’s the impact they have / protect your critical path
SPOF: Spof-o-matic
General: Webpagetest with blocks
Rendering: heatmap
Synthetic:
+ Consistent
+ Use API to remove dead tags
+ Tests even when tags removed
Limited test locations
RUM:
+ Real Customer metrics
+ API to remove dead tags
Cannot test removed tags
Relies on resource-timings and timing-allow-origin for granular metrics
Whatever route, you should be measuring your third-parties and holding them to SLAs. If they fail, get them off the site.
Tag managers are just a band-aid over a growing problem
Tag Manager – maintain control of who can add what, and the business processes around that
Sprints and User Stories – marketing / business define a user story, devs create the solution.
CSP to Enforce –
Bottom-line : concerted effort between business / marketing / IT