Speed optimization is a team sport

There's a persistent myth that website speed is solely the developer's problem. The truth is that a fast site depends on cooperation across departments. Developers, no matter how skilled, rarely have the authority to fix performance issues alone. If you're a developer trying to get a speed project off the ground, here's how to make the case, bring other teams on board, and prove the value of your work.

Why your business stakeholders are part of the fix

Consumer behavior has shifted hard toward digital channels, and companies that can't keep up risk declining revenue. Adapting requires more than a new tool or framework; it requires organizational change and buy-in from the top.

You'll struggle to get dedicated development time for a speed project unless stakeholders treat it as a priority. Similarly, collaboration with marketing and design teams goes more smoothly when executives signal that performance matters. To get that support, it helps to frame two macro trends for your stakeholders:

  • Even when purchases happen in a physical store, most customers research on a digital platform first. A poor site experience can hurt in-store revenue and reduce customer loyalty and willingness to recommend your business.
  • Mobile traffic is growing faster than desktop. The correlation between mobile speed and conversion is strong, with one SOASTA study cited by Google showing conversions can drop by up to 20% for every second of mobile page load delay.

Smart executive decisions now have to include digital expertise. One practical recommendation: invite a developer to meetings where business decisions affecting the site are made. This way the constraints and opportunities of the platform are considered from the start.

A draft proposal you can adapt

In general, around 10% of sales happen on digital platforms, but studies show that as much as 85% of the sales in physical stores are influenced digitally first. Having a site that performs well, especially on mobile (which is becoming the primary device), is thereby crucial for our business's revenue. We propose a speed project that will help the site increase conversions, and to set up streams of communication so that the insights in technical teams can be better put to use before decisions that will affect the site are made.

Preparing the data

Walk into the meeting with numbers on your own site, your competitors, and a clear ROI story. The most persuasive data connects speed directly to revenue. Try these approaches:

  • Calculate your relative mobile conversion rate. Work with your analytics team to compare two historical periods of 2 to 3 months where load times clearly differed. This analysis usually reveals that slow speed hit mobile conversions hard, and you can translate that into lost revenue.
  • Use statistical models to estimate the value of speed. Google's TestMySite can calculate the business impact of a faster site. You'll just need the average monthly visitors, conversion rate, and average order value from your analytics team.
  • Pull best-practice case studies. Public examples of companies that sped up their sites and measured the effect make a compelling argument. "How Page Load Time Affects Conversion Rates: 12 Case Studies" is a good starting point.
  • Quantify the mobile share. Have the analytics team report what percentage of your traffic comes from mobile versus desktop.
  • Estimate the cost. Stakeholders can't judge ROI without an effort estimate. Calculate how long the initial focused project will take, plus what ongoing maintenance requires. The TUI case study shows one model: developers got 20% of their time freed from backlogs to dedicate to speed work.

Making the business case

When you're face to face with decision-makers, present your findings clearly. The core arguments are:

  • The share of your mobile traffic and its growth trend together make the case for investing in the mobile experience.
  • Your analysis shows how speed influences the company's revenue.
  • Developers can use available time to improve mobile conversion rates.
  • A representative from the development team should sit in on executive meetings about the site.

The last point is about breaking down silos before they cause expensive mistakes. A Harvard Business Review study found that one in six IT projects has a cost overrun of 200%. That is exactly what happened to Kmart, which lost ground to Walmart and Target while undertaking a $1.4 billion IT modernization in 2000. Early communication and maintenance planning could turn those failures into a competitive advantage.

Build a partnership with your marketing team

Marketing needs third-party tools to run campaigns and gather data. But those tools typically ship as render-blocking scripts that make visitors wait before they see content. Striking a balance between data collection and speed is necessary because a slower site undermines the ROI of every ad dollar spent.

One practical balance is to keep scripts lean:

  • Remove duplicate tools that measure roughly the same thing.
  • Eliminate tools that are no longer in use.
  • Measure only what’s business-critical, not what’s merely “nice to have.”

Developers can't know which tools marketing depends on, and marketing may not know which tools are heaviest. Collaboration is therefore essential.

Drafting the first proposal

Tools used for tracking and ads often block how quickly visitors see content when they enter the site. This reduces the value of marketing investments, since we pay for ads, people get interested, they click but then have to wait. This risks them getting annoyed and leaving. One study found that conversion rate decreased from around 50% to around 35% when the speed metric Time to Interactive increased from 0.15 s to 0.3 s. Can we work together on solving this to create a balance between the tools you need and site performance, making increased return on marketing investments a result?

Preparing for the meeting

  • Create a list of every script on the site.
  • Ask marketing to sort the list into three buckets in advance:
    • Business-critical — scripts that must remain.
    • Nice-to-have — tools that could be removed. For example, heatmaps or screen recordings may only be analyzed occasionally without driving action; instead, run them for two weeks to collect insights, then clean up.
    • Not used or not owned — candidates for immediate removal.
  • Measure each script’s performance impact. In WebPageTest, use the Block tab in Advanced Settings, or block network requests in Chrome DevTools to compare speed with and without the script.

Running the meeting

  • Walk through each script and compare perspectives: your technical insights on performance costs with their business justifications.
  • Open a discussion on these questions:
    • Does the benefit of the data exceed the conversion loss from slower load times?
    • Is there a faster vendor for business-critical tools on the market?
    • Are alternatives available? For instance, usability tests, where context and user motivations offer deeper insight than heatmaps, could replace a heavier tool in some cases.

Agreeing on a way forward

  • Define a process. Choose one of two directions: either the marketing team always has developers review a new tool’s speed impact first, or give marketing a defined performance budget they must meet, teaching them to run their own speed checks.

Speed depends on your web design team

Connectivity is improving in many regions, but websites are growing heavier, generally getting slower. Developers must collaborate with designers to reverse that trend. A gorgeous page is worthless if visitors leave before it renders.

Finding the shared ground

Both the development and design teams ultimately depend on the site converting. Image optimization is the developer’s responsibility, but page weight is also a design discipline: choosing intros, layouts, and imagery that support a fast page is an explicit design decision.

An initial note to design

Studies show that pages with fewer images and less elements create more conversions. For example, a study by Google and SOASTA found that sessions that converted users had 38% fewer images than sessions that didn't convert. Can we work together to reach speed targets and set up a joint collaboration that can increase conversions on the site? Examples of what we can achieve together include finding the right level of image compression with a balance between quality and speed, or reducing complex layouts or functionalities that often result in heavy, slow sites.

Building the shared plan

  • Identify slow, heavy pages. On e-commerce sites, look at campaign pages, top category and product pages, the homepage, and the checkout flow.
  • Propose a simple performance budget by page weight, starting at 1 MB, or 1.5 MB if branding heavily impacts conversion.
  • List pages that currently exceed that weight.

For your design team meeting

  • Commit to improving image delivery with compression, responsive images, resizing, lazy loading, caching, and server optimization.
  • Create a test page with different image qualities and dimensions, and agree on a balanced level for various screen sizes. Consider mobile contexts—one study shows more than half of mobile sessions are under 30 seconds; those users usually want a fast page, not pixel-level scrutiny of imagery.
  • Agree on the performance budget with designers committing to a maximum of 1–1.5 MB.

Include your analytics team in the loop

Most companies rely on data to make decisions, but site speed often fails to make it into business reports. Contributing to that is just how things are typically organized: if speed isn’t reported, it isn’t prioritized. But analytics teams continually have questions about analyzing revenue, and developers need meaningful data reporting on the results of their work. That creates a natural partnership.

A collaboration with shared value

Reported metrics become prioritized metrics. Left out of weekly reports, would-be impactful speed improvements lose visibility. Since speed tracking and analysis is unfamiliar to many analytics teams, developers have to provide the initial assistance—but the analytics team’s ability to tie speed to revenue gives development teams a powerful clear return on investment (ROI) narrative upward.

The introduction

Many case studies show the effect site speed has on revenue and bounce rate. Could we possibly collaborate to set up site speed tracking for our company, and perhaps get speed as a part of the reports going to stakeholders so that we get more buy-in?

Getting ready

The discussion

  • Review the relative mobile conversion rate chart from The value of speed — discuss whether the analytics team is ready to adopt this metric into their regular reporting.
  • Consider whether Google Analytics’ load time metric is acceptable for business reporting as a baseline. It is reliable as field data but is only one of many speed metrics. Observe patterns: does the relative mobile conversion drop when load times are elevated for two to three months straight? If it does, the correlation is real enough to track. If load times have stayed steady, there’s nothing to correlate yet — improve speed first, then come back to validate the analysis later.
  • Walk through the speed charts your team already uses and look with the analytics team for trends against either load time or relative conversion rate.
  • Expect iteration. For these analysts, aligning speed with revenue is likely new to them; allow time for them to propose approaches and come back with ideas. Re-measure and refine the strategy well beyond your first shared breakdown.

Reward the cycle

After the speed improvements roll out, ask the analytics team to revisit the analysis to report the financial win back to the business — an indication of both progress and your teams’ ability to collaborate. Reporting it to stakeholders weekly, for example, makes ongoing upkeep the norm rather than a one-time peak in performance.