A fast marketing site is relatively easy to build when very little is happening on it.
The harder version has large hero media, analytics, advertising tools, CRM forms, a headless CMS, content previews, and a marketing team that needs to publish without waiting for an engineer.
That was part of the challenge when Monogram built Kasada's new website.
Kasada is a cybersecurity company, so the platform also needed to communicate technical credibility. But performance could not come at the cost of the workflows required to actually run the website.
The interesting engineering problem became: how do you protect frontend performance without turning performance into a restriction for marketing?
Performance is an architectural problem
It is easy to treat web performance as an optimization phase.
Compress some images. Lazy load a few resources. Run Lighthouse. Fix the obvious problems.
That approach becomes fragile on a marketing platform because the website keeps changing.
New campaigns appear. Analytics tools are added. Advertising scripts change. Editors replace media. Landing pages are assembled differently. Forms appear in new places.
Performance therefore cannot depend entirely on engineers manually reviewing every page.
For Kasada, Monogram built the site with the Next.js App Router and created caching and revalidation strategies around its content heavy architecture. Published pages could benefit from static generation and optimized asset delivery, while editors still had draft and live preview workflows inside Sanity.
The important distinction is that editorial flexibility and production rendering do not have to follow the same execution model.
An editor needs current draft content.
A visitor usually needs the latest published version, delivered as efficiently as possible.
Treating those as separate requirements gives the application more room to optimize both.
Rich media needs guardrails too
Scripts are not the only source of performance problems on marketing sites.
Hero sections are particularly dangerous because they combine two competing goals. They are usually the most visually important content on the page, but they can also contain some of its heaviest assets.
Kasada's implementation included specific performance work around hero media rather than treating media optimization as a generic concern.
That suggests a useful design system principle:
Performance constraints should live as close as possible to the components capable of creating performance problems.
If every editor can independently decide how a large hero asset is loaded, performance becomes dependent on individual publishing decisions.
If the component owns the important delivery behavior, editors can change content without also needing to become performance engineers.
This is one of the less visible advantages of connecting a CMS to a controlled component system.
The CMS provides flexibility over content.
The component defines the technical boundaries around how that content reaches the browser.
Third party scripts are part of your performance budget
Marketing platforms rarely control every resource they execute.
Analytics and advertising tools introduce JavaScript from systems outside the application's core bundle. Those tools may be necessary for attribution, campaign measurement, or other business requirements, so simply removing them is often not a realistic engineering recommendation.
Kasada had this exact constraint.
Monogram implemented audit aware loading for production analytics and advertising integrations, specifically to prevent those tools from unnecessarily degrading performance measurements and Core Web Vitals.
The broader lesson is more important than the specific implementation.
A third party script should not become invisible to the architecture simply because your team does not own its code.
It still consumes browser resources.
It can still compete with rendering work.
It can still affect Core Web Vitals.
And it can still change independently of your application.
That means third party integrations deserve the same architectural questions as other dependencies:
What does this script need to do? When does it need to execute? Which pages actually require it? What happens to the user experience when it becomes expensive?
Performance engineering on a marketing website is partly dependency management.
Marketing capabilities should reuse infrastructure
Protecting performance does not mean preventing marketing from adding functionality.
The better approach is to make common capabilities reusable.
Kasada's HubSpot integration demonstrates this on the lead generation side. Forms were incorporated into the reusable content section library instead of being implemented independently across landing pages and campaigns. Form validation and visual behavior could therefore remain aligned with the rest of the platform while submissions flowed into Kasada's CRM.
This is useful beyond forms.
If a capability will appear repeatedly across a website, implementing it as shared infrastructure creates a place where engineering constraints can be enforced once.
That might include rendering behavior, validation, accessibility, script loading, or integration logic.
The alternative is allowing each page to solve the same problem independently.
That gives teams flexibility quickly, but it also creates multiple places where performance and maintainability can deteriorate.
Optimize the system, not just the launch
The most important performance decision in a large marketing project often happens before anyone opens a performance profiler.
It is deciding who controls what.
On Kasada's website, Sanity gives marketers control over structured content and page composition. The component system gives engineering control over rendering behavior and design consistency. Next.js provides the production rendering, caching, and revalidation layer. External marketing systems remain integrated without being allowed to define the architecture of the application.
That division of responsibility matters because the website is not frozen after launch.
Editors will publish.
Campaigns will change.
New integrations will appear.
Media will be replaced.
If performance depends on everything remaining exactly as it was on launch day, the architecture has already failed.
A more durable approach is to build performance expectations into the places where future changes will happen.
For a CMS driven Next.js site, that means thinking beyond Lighthouse scores and asking:
Which content can be delivered statically?
What actually needs revalidation?
How will editors preview unpublished changes?
Which components can introduce expensive media?
Which external scripts can affect rendering?
Which recurring marketing capabilities should become shared infrastructure?
Those questions are less exciting than choosing a new framework.
They are also much more likely to determine whether the site is still fast six months after launch.
That was the useful lesson from Kasada: performance works better as a constraint of the platform than as a cleanup task for individual pages.
Top comments (0)