The two-sided coin of web performance
Hacking performance across your organization.
I’ve given Web performance talks where I get to show one of my favorite slides with the impact of third-party dependencies on load time. It’s the perfect use case for “those marketing people,” who overload pages with the tracking pixels and tags that make page load time go south. This, of course, would fuel the late-night pub discussrion with fellow engineers about how much faster the Web would be if those marketing people would attend a basic Web performance 101 course.
I’ve also found myself discussing exactly this topic in a meeting. This time, however, I was the guy arguing to keep the tracking code, although I was well aware of the performance impact. So what happened?
Learn faster. Dig deeper. See farther.
The case for third-party cruft
The responsibility of building our marketing analytics and customer acquisition programs fell to me. I’m not a marketing person, but being the company’s chief evangelist, I was in the best position to get the job done.
We needed quite a bit of tracking on our pages to make our business work smoothly. Understanding which functionalities our customers actually use is key to optimizing onboarding and product development. Tuning ad campaigns based on user behavior helps to market to the right people and ensures we don’t waste money on a misconfigured ad campaign.
If you start to list even the bare minimum tools required, it starts to get scary:
- Behavior tracking for aggregated user behavior, like Google Analytics.
- Tooling for tracking individual user behavior, like Woopra or KissMetrics.
- Tracking pixels for your ad providers.
- Tracking for remarketing platforms.
- JavaScript integration for a chat on our website.
- JavaScript-based A/B testing (we avoided that, but still mentioning it for completeness).
If you now consider that it’s common for a site to use more than one ad provider — like Facebook, Twitter, and Google, plus a number of remarketing providers, too — you start to see that 10 third-party additions on a page are nothing.
The hard truth is, they make your pages slow, but you need them to run your business. At this point the discussion becomes very heated and intense. And developers lecturing everyone on Web performance 101 isn’t a great place to start, either. I imagine the same situation happening in a lot of companies. The marketing team being pretty clear that the developers don’t get business requirements and the tech team responding in kind that their counterparts have no idea about solid engineering.
Performance hacking
At ruxit we’ve developed a model called performance hacking. In short, performance hacking is about having all teams, product, operations, and business, get on the same page and follow the same principles or rhythm. We see this as an extension to our DevOps approach by integrating stakeholders like marketing into the process. For us, it provides a more holistic approach by looking beyond technology.
Our way of solving problems is using a simple SCRUM story-based approach; the customer — in this case, marketing — can decide what is important. However, they have no say over how it is actually done. In many organizations, I know marketing has control over what a tag manager loads. One of the big successes of these tools, surprisingly, is that the tech marketing people do not need to talk to their engineering counterparts.
Following our approach, we defined a story without the discussion of whether this “marketing crap” had to be on the page or not. We did, however, get very precise about what we needed. This led to a technical implementation where we used quite a bit of custom coding to control when things load, rather than just putting every third party on every page using default tag manager behavior. In some cases, we even built whole tracking functionalities ourselves rather than relying on tools.
This obviously had an impact on product delivery, as we spent cycles on these non-feature tasks. At the same time, people started to understand that features won’t make a better product if you don’t have the means to properly drive interest and track behavior to improve the product.
Obviously, not everything goes according to plan. Our marketing team constantly tries out new platforms and therefore needs to continuously add new tracking to our pages. In the past, sometimes they would just “forget” they put it on the page. We’ve stopped this experimentation anarchy, too. By defining that everything must be part of a story and a sprint, including “just” trying out new platforms, we’ve made it part of the company culture. Coincidentally, we’ve helped make our site and application more secure by using cross-domain policies, as no third-party additions not agreed on in advance get loaded.
This post is part of a collaboration between O’Reilly and ruxit. See our statement of editorial independence.