Web Performance Is a Business Decision, Not a Developer Problem

When a site is slow, the instinct is to hand it to engineering and ask them to fix it. That framing misses the real problem. Performance is not a technical malfunction — it is a product decision with revenue consequences, and fixing it requires the same cross-functional thinking as any other growth problem.

The business case is not subtle. Google’s research has shown that a one-second delay in mobile page load can reduce conversions by up to 20%. Bounce rates climb sharply as load time increases. And since 2021, Core Web Vitals have been a direct ranking signal in Google Search — meaning slow pages are not just losing customers after they arrive, they are losing the organic traffic to bring those customers in the first place.

If your paid search budget is the only thing keeping your acquisition numbers up while organic traffic bleeds, web performance is part of the diagnosis.

What Performance Actually Measures

The most useful framework for non-technical stakeholders is Core Web Vitals, the set of metrics Google uses to assess the experience of loading and interacting with a page. Three numbers do most of the work:

Largest Contentful Paint (LCP) measures how long it takes for the main content of a page to appear — the hero image, headline, or product photo that tells the user something has loaded. Under 2.5 seconds is the target. Above 4 seconds is a failing grade.

Interaction to Next Paint (INP) measures how quickly the page responds to user input — a click, a tap, a keystroke. A sluggish response here is the jank that makes people feel like the site is broken even when the content has loaded.

Cumulative Layout Shift (CLS) measures visual stability — whether content jumps around while the page loads, causing misclicks and disorientation. A late-loading ad that pushes the button you were about to tap is a CLS problem.

You can audit any page against these metrics for free with Google PageSpeed Insights or Lighthouse in Chrome DevTools. The scores are directional, not precise, but they identify where the problems are.

Where Performance Problems Actually Come From

The assumption is that performance is about code quality. Often it is not. The most common culprits in real projects:

Images that were never sized for the web. A product photograph uploaded at 4 MB is still 4 MB on the page unless something converts it. Unoptimised images are the single most common cause of poor LCP. Modern formats like WebP and AVIF can cut file sizes by 30–70% with no visible quality loss.

Third-party scripts. Every analytics tag, chat widget, A/B testing tool, and cookie banner you add to a page loads external JavaScript that the browser must download, parse, and execute before it can finish rendering. A site with twelve marketing tags can easily add two or three seconds to load time — and each tag was added by someone who had a good reason.

Fonts. Custom web fonts are often loaded in ways that cause text to be invisible until the font file arrives. This is fixable with a single line of CSS or a loading strategy change, but it is frequently overlooked.

Hosting and caching. A site on shared hosting in a US-East data centre loads faster in Virginia than in California, and much faster in California than in Germany. A content delivery network (CDN) solves this by serving assets from locations close to the user. Not using one is a straightforward performance tax.

Why Design and Marketing Own Part of This

Performance is not solely the engineering team’s problem to solve because engineers are not the ones adding third-party scripts, choosing five custom font weights, or uploading uncompressed images through a CMS.

Marketers adding one more tracking pixel, designers specifying full-bleed 4K background videos, and product teams shipping feature after feature without auditing the JavaScript they add — these are the incremental decisions that turn a fast site slow. The engineers can build infrastructure to catch and compress some of it, but they cannot override decisions being made in other parts of the organisation.

The fix is treating performance as a shared constraint, the same way you would treat accessibility or brand consistency. Define a performance budget — a maximum allowed page weight, LCP target, or INP threshold — and make it part of the definition of done for any new work, regardless of which team is doing it.

A Practical Starting Point

If you have never done a performance audit, the sequence that gives the most return with the least disruption:

1. Run a Lighthouse audit on your highest-traffic landing page and your checkout or signup flow. Note the LCP and CLS scores specifically.
2. Identify and audit every third-party script loaded on those pages. Remove anything that is not actively used or cannot be justified by measurable business value.
3. Check your images. Are they being served in modern formats and sized appropriately for display dimensions? If not, this is the highest-leverage fix available.
4. Review font loading strategy. If text is invisible while fonts load, implement font-display: swap.

None of these steps requires a major engineering initiative. The first three can often be done in a day by someone who knows where to look.

The deeper architectural work — lazy loading, server-side rendering, edge caching — comes later and matters more at scale. But most SMB sites have not done the basics, and the basics account for the majority of the gain.

---

PNK WORKS builds and audits websites and web apps with performance baked in from the start, not bolted on later. Talk to us.