You’re about to sign a redesign scope. It promises a “fast, modern site,” but the rest of the document is about layouts, brand, and new tools. Performance is a single bullet, not a set of rules anyone can actually build against. That’s the real risk: not that your developers don’t care about speed, but that you haven’t committed—on paper—to the tradeoffs that will protect it.
Set performance targets, constraints, and ownership before you sign the redesign scope, or the new site can inherit the same speed problems in a prettier package.
Redesigns don’t create performance problems out of nowhere—they hard‑code the tradeoffs no one was willing to say out loud in the scope. This article is about getting those tradeoffs explicit, so performance becomes part of your operating model, not a last‑minute firefight.
1. The real performance decision in a redesign: what you commit to before anyone opens Figma
Most redesigns treat performance like this:
- One line in the brief: “Site should be fast and optimized for Core Web Vitals.”
- Maybe a non-binding statement in the SOW: “Agency will follow performance best practices.”
- A vague plan to “do a speed pass” at the end.
That’s not a performance strategy. That’s a dispute waiting to happen.
What you’re actually deciding—usually without saying it—is:
- Which journeys must not slow down even if design or tooling requests conflict.
- Which components and scripts are allowed to exist across templates.
- Who gets to say “no” when a request will blow up load time.
If those decisions aren’t captured in the scope, they will be made ad hoc during design reviews, rushed QA, or after complaints start coming in from sales and customers. And they will almost always break toward:
- Heavier imagery and video (because visuals are visible in sign-off).
- More third-party tools (because each solves a real stakeholder request).
- Flexible, anything-goes templates (because “we might need that later”).
We’ve already argued that accessibility belongs in the scope, not as a post-launch clean-up job; if you found the argument in When Accessibility Debt Means Your Redesign Scope Is Too Small convincing, performance sits in the same category. Governance concerns don’t bolt on nicely at the end. They reshape what “in scope” actually means.
2. Visible requests vs. invisible constraints: the tradeoffs you actually have to choose
Most redesign conversations are dominated by visible requests:
- Bigger hero images and richer photography
- Video backgrounds and looping explainers
- More animations, transitions, and interactions
- New marketing tools: chat, pop-ups, AB testing, heatmaps, personalization
Meanwhile, the performance decisions that matter are mostly invisible in Figma or PowerPoint:
- How heavy each template is allowed to be
- How many scripts are allowed to run and where
- How images are handled, compressed, and loaded
- How many “global” components stack up on every page
You can’t have infinite freedom on the visible side and no constraints on the invisible side and still expect predictable speed.
Here are the performance tradeoffs you actually need to settle up front in the scope:
2.1 Speed vs. visual richness
You’re not choosing between “ugly but fast” and “beautiful but slow.” You’re choosing:
- Where rich visuals are worth the weight (e.g., hero on the homepage, single flagship explainer video).
- Where they are explicitly not allowed (e.g., campaign landing pages meant for paid mobile traffic).
Without that distinction in writing, you get the same heavy hero pattern reused everywhere because it “looks on-brand.” That’s how one design decision slows an entire funnel.
If you want a deeper dive into this kind of mistake on confidence-building pages, we unpack that specifically in How to Tell When Image-Heavy Redesign Decisions Are Slowing the Very Pages Meant to Build Confidence.
2.2 Flexibility vs. template discipline
Stakeholders love flexible templates: “Let’s make sure we can add anything, anywhere.”
That sounds empowering. Operationally, it means:
- No stable performance envelope for key page types
- Every new campaign becomes a fresh negotiation with speed
- Authors can inadvertently assemble the heaviest possible page
Template discipline—clear rules about which blocks can appear on which page types—is a performance decision, not just a content one. It belongs in the component library spec and the SOW.
2.3 Third-party tooling vs. script budgets
Every new tool on your site usually brings JavaScript with it. Individually, each is “just one more script.” Together, they’re a hidden, growing tax on every user session.
The tradeoff to settle isn’t “tools or no tools.” It’s:
- How much third-party weight you’re willing to carry on specific page types
- Which tools are allowed globally vs. limited to certain templates
- Who approves new tools against a script budget, not just a marketing benefit case
When this isn’t defined, scripts get added over time until your most important funnels are effectively running through molasses—and IT is asked to “upgrade the hosting” to fix what is fundamentally a front-end decision.
2.4 Animation/interaction vs. load order
Delightful animation often ships as blocking scripts and big libraries. Unless the scope defines:
- Which interactions are core to conversion vs. “nice-to-have”
- Where animation must be non-blocking or progressively enhanced
…you end up slowing down the crucial “first contentful” experience so that secondary animations are perfect. That’s the wrong tradeoff in almost any commercial scenario.
Not choosing on these axes is still a choice. It defaults you to slow, because every stakeholder request adds weight and latency, while no one has explicit permission to protect speed.
3. The Performance Guardrails Triangle: targets, constraints, and ownership
To keep this manageable, use a simple framework you can literally sketch in a notebook: the Performance Guardrails Triangle.
Three corners, all of which must be explicit in your redesign scope:
- Targets – What “fast enough” means, for which journeys
- Constraints – The specific rules you’re putting in the SOW and component library
- Ownership – Who has authority to enforce and adjust those rules over time
If your scope mentions “fast” but is silent on any one of these, it’s incomplete.
3.1 Corner 1: Targets
Targets are not vague aspirations like “great Core Web Vitals.” They are a small set of business-relevant commitments, such as:
- “First-time mobile visitor from paid search can reach and submit the lead form on a key service page without noticeable lag.”
- “Resource library results load quickly enough that scrolling and filtering feel instant on a mid-range phone.”
You don’t need to be the speed engineer here. You do need to specify:
- Priority journeys: e.g., homepage → service page → contact; ad → landing page → form; pricing → comparison → demo.
- Device context: especially mobile and typical connection quality for your audience.
Your technical team or agency can translate that into specific metrics and tests. But if you can’t name the journeys, no amount of technical tuning will align with business risk.
3.2 Corner 2: Constraints
Constraints are where most scopes are silent—and where governance actually lives.
Examples of constraints that belong in a redesign SOW and component spec:
- Template weight rules for core page types (even if expressed qualitatively, like “no autoplay background video on any lead-gen template”).
- Script budgets by page type (e.g., “no more than N third-party scripts on landing pages; global tools limited to analytics and tag manager”).
- Image handling rules (e.g., responsive formats, maximum hero dimensions, no unoptimized uploads).
- Component placement rules (e.g., testimonial carousels only allowed on X templates; interactive calculators only where they directly support conversion).
Your developers can help define these, but you as the business or marketing owner must decide where they are non-negotiable, because they trade directly against visual ambition and tooling freedom.
3.3 Corner 3: Ownership
Ownership is where redesigns either become sustainable or start to rot.
Ownership means:
- One role accountable for performance targets being respected in design reviews
- One role responsible for monitoring performance across releases
- Clear decision rights: who can say “no” to new scripts or heavy components
If your plan is effectively “our developers will just keep an eye on it,” you don’t have ownership. You have hope.
Performance ownership should sit where business risk is managed—usually marketing or operations—with strong technical partners. Treating speed as a side project for an individual developer or IT person guarantees it loses every tradeoff to visible marketing asks.
For a sense of what happens after launch when no one owns this corner of the triangle, our piece on How to Spot Performance Drift Across Templates Before Users Start Complaining expands on the monitoring side.
4. Tradeoffs to settle by page type, not in the abstract
Abstract rules sound good; templates are where they either work or fall apart. Scope your performance guardrails by page type, not just “the site.”
Below is a non-exhaustive list of decisions you should settle before sign-off.
4.1 Homepage
- Hero media rule: Is video allowed? Autoplay? On desktop only? On mobile?
- Global components: Which global elements (navigation, announcement bars, chat widgets) are allowed here, and what’s the maximum stack you’ll tolerate?
Because the homepage often reuses hero and navigation components, a heavy pattern here can cascade into every major journey.
4.2 Service and solution pages
- Confidence vs. weight: How many large visuals, diagrams, or embeds are allowed above the fold?
- Reusable components: Which modules (e.g., tabs, accordions, carousels) are allowed, and are they implemented in a shared, performance-conscious way?
These pages frequently carry the load for paid traffic and sales follow-up. Overloading them with image-heavy modules is a classic failure mode.
4.3 Pricing and comparison pages
- Table and comparison patterns: Will these be plain HTML with light styling, or interactive React-style components loaded for every visitor?
- Additional scripts: Are calculators or configurators mandatory? If so, can they be loaded only when engaged, not on every visit?
Your pricing page is often the most scrutinized page by decision-makers. Making it script-heavy because “it feels more modern” can quietly harm conversion.
4.4 Lead-gen landing pages
- Script budget: How many third-party scripts are allowed (analytics, AB testing, heatmaps, chat)? Define this in numbers and in priorities.
- Layout discipline: Are these built from a strict, light template, or can any global component be dropped in?
Landing pages are where vague performance promises collide with real spend. If your paid traffic is mostly mobile, these should be your strictest templates.
4.5 Blog and article pages
- Tracking and embeds: Which embed types are allowed (YouTube, podcast players, code sandboxes), and how are they loaded?
- Author freedom: Can content editors freely insert any script or embed, or are there standardized, optimized blocks?
If you’ve ever watched a blog slowly turn into an embed museum, you know how this goes: each article adds one more “small” third-party widget until the whole section drags.
4.6 Resource library and search results
- Result density and lazy loading: Do you load 50 results at once, or use pagination/infinite scroll with sensible defaults?
- Filtering and search patterns: Are you implementing custom JavaScript-heavy filters everywhere, or reusing a single, efficient pattern?
When you’re ready to go deeper on how template-level decisions like these accumulate into serious weight, our post on How to Spot Template Weight Before New Features Make Key Pages Slower operationalizes this angle.
The point: don’t argue about performance in the abstract. Decide per page type which compromises you’re willing to make, then bake those decisions into templates, not one-off pages.
5. Shared layers, drift, and Semantic Decay: what breaks when you treat performance as a checkbox
Performance has its own version of Semantic Decay. Just as ungoverned content and linking slowly erode a site’s topical clarity, ungoverned design and scripting slowly erode its speed and reliability.
Three patterns show up repeatedly when performance was treated as a one-off task in a redesign:
- Shared front-end layers become a single point of slowness. One heavy navigation, header, or UI library gets loaded on every page. When you later discover it’s slow, you can’t fix it without touching half the site. Our piece on How to Tell When Shared Front-End Layers Are Compounding Delay Across Key Templates is effectively a post-mortem for this failure mode.
- Templates accumulate weight as components and scripts are added over time. Because no one owns the “template budget,” each request is handled locally. Eventually, your key templates carry substantial weight, and “performance optimization” becomes synonymous with “expensive refactor.”
- Third-party scripts creep in quietly. Marketing, sales, and support teams each add one or two tools. None are clearly owned; all run everywhere. When slowness is finally noticed, IT and hosting vendors are blamed for issues that stem from front-end bloat.
This is performance drift: the slow weakening of your site’s speed posture because there were no standards, review cadence, or decision rights. If you want to see what it looks like in the wild, and how to spot it early, How to Spot Performance Drift Across Templates Before Users Start Complaining expands on the patterns.
A well-built redesign with no governance will still decay. The only question is whether you catch it in quarterly reviews—or when customers and sales teams start escalating complaints.
6. Who owns performance decisions before, during, and after the redesign
You don’t need a new department for this. You do need clarity.
Think in terms of phases and decision rights, not just tasks.
6.1 Discovery and scope
Primary owner: Marketing or operations leader (website owner)
Responsible for:
- Defining business-critical journeys and prioritizing them
- Approving performance targets in business language
- Agreeing on non-negotiable constraints with technical partners
Risk if missing: Scope reads like a wish list without guardrails; everyone assumes someone else will “keep it fast.”
6.2 Design and component library
Primary owner: Design lead, in partnership with engineering lead and website owner
Responsible for:
- Translating constraints into component rules (e.g., which blocks can appear on which templates)
- Avoiding bespoke, one-off interactions when a lighter shared pattern exists
- Flagging where design ambition conflicts with agreed performance rules
Risk if missing: Visually-driven decisions double template weight; heavy hero and interaction patterns are approved with no understanding of their cross-site impact.
6.3 Build and implementation
Primary owner: Engineering lead, with clear acceptance criteria from website owner
Responsible for:
- Implementing shared layers and templates according to performance guardrails
- Enforcing script budgets, image handling, and lazy-loading rules
- Running agreed performance tests before launch and during soft rollouts
Risk if missing: “Best efforts” tuning late in the project, focused on the homepage desktop experience while real revenue journeys go untested.
6.4 Post-launch and ongoing operations
Primary owner: Website owner (marketing/ops) with recurring support from performance-focused partners
Responsible for:
- Monitoring key journeys for regressions (especially after campaigns, tool additions, or template changes)
- Reviewing new requests (tools, components, embeds) against script budgets and template constraints
- Scheduling periodic performance audits and refactors before issues become systemic
Risk if missing: Performance regressions discovered by customers or sales; IT and hosting providers are blamed for front-end and governance decisions.
This is where it often makes sense to move from “project” thinking to an ongoing performance-optimization relationship—someone whose job is to maintain the guardrails you’ve defined and adjust them as the business evolves. Our performance optimization service is structured around that kind of recurring ownership, not just one-time tuning.
7. A quick diagnostic: are your performance tradeoffs settled enough to sign this scope?
Use this as a pre-approval checklist before you sign a redesign SOW or green-light build.
If you can’t answer “yes, and I can show you where it’s written” to most of these, you’re not done.
- Priority journeys – Have you explicitly listed the 3–5 user journeys that matter most for revenue or lead generation, and are they referenced in the scope?
- Page-type rules – For each key page type (home, service, pricing, landing, blog, resources), have you defined specific performance-sensitive rules (e.g., hero media limits, script budgets, component constraints)?
- Script budgets – Does the scope define any limits on third-party scripts by page type, and does it say who can approve exceptions?
- Template discipline – Is there a documented component library with rules about which blocks can appear on which templates, or is the plan “flexible pages that can do anything”?
- Image workflow – Is there a defined process for image optimization (formats, sizes, who is responsible) that’s built into the CMS or publishing workflow, not just a reminder in a launch checklist?
- Shared layers – Have you agreed which front-end layers (e.g., navigation, header, global UI libraries) will be shared, and how their weight and scripts will be governed over time?
- Testing plan – Is there a concrete plan for performance testing that includes multiple page types and mobile journeys, not just a single homepage report?
- Ownership and escalation – After launch, who is accountable for monitoring performance, and what is the process when someone wants to add a heavy component or tool that exceeds the guardrails?
If your honest answers show gaps, you have two options:
- Tighten the scope now. Push for explicit targets, constraints, and ownership language before you sign.
- Plan a parallel performance stream. If the redesign train is already moving, carve out a dedicated performance-optimization track (internal or external) that defines guardrails, monitors key journeys, and has real authority to push back on risky decisions.
Either path is better than pretending “we’ll keep it fast” is a strategy.
8. When you need more than better scope language: folding performance into your operating model
Updating the scope language is the immediate fix. The durable fix is treating performance like any other form of risk you govern:
- Roles: A named website owner accountable for speed on key journeys.
- Rules: Written targets and constraints, aligned with business outcomes.
- Review cadence: Regular checks across templates and journeys, not just once a year.
- Exception handling: A clear process for evaluating and approving heavy asks (new tools, big components) against your guardrails.
If that sounds familiar, it’s because it mirrors how we talk about Semantic Decay: without clear ownership and periodic review, your structure and content drift away from the strategy you thought you had. Performance behaves the same way.
From here, there are three practical next steps:
- If you’re mid-scope: Reopen the document and add explicit targets, constraints, and ownership—your Performance Guardrails Triangle. Treat this as a non-negotiable revision before you sign.
- If the redesign is already underway: Establish a parallel performance track with its own decision rights. Make sure design and build teams know where the guardrails are and who can say no.
- If you’re already seeing drift: Use performance drift as a diagnostic signal that you need governance, not just another round of tuning. The broader website redesign topic hub is a good place to explore related governance decisions you may need to make.
If you want help turning this from a checklist into an operating habit—guardrails, monitoring, and decision support baked into how your site runs—our team can step in as the persistent owner of that triangle. You can talk through the tradeoffs with us or simply get in touch to pressure-test your current scope before it hard-codes the next generation of performance problems.