Then, as launch gets closer, another requirement suddenly becomes critical: "The website needs to be fast."
The problem is that performance is not something developers simply switch on at the end of the project. Many of the decisions that determine how fast a website can be were already made during strategy, design and development.
At Cuberto, we think performance should be discussed much earlier.
Great visuals come with a performance cost
A highly interactive website can still be fast, but every visual decision has a cost. Large videos need to be downloaded. Image sequences may require dozens or hundreds of frames. 3D scenes need assets and JavaScript. Complex transitions require additional processing in the browser.
None of this means those things should be avoided.
For many brands, motion and interaction are an important part of the experience. We use them extensively in our own work. The important part is understanding the trade-off early.
Performance is also not the same thing as SEO. Google considers Core Web Vitals, but strong performance scores alone do not guarantee strong rankings. Content, structure, relevance and the overall page experience still matter.
What does “fast” actually mean?
“We need the website to load in under two seconds”
Sounds clear, but technically it raises several questions.
1) Two seconds until what?
The first content appears? The main content becomes visible? Every image and script has finished downloading?
2) And under which conditions?
A high-end laptop on office Wi-Fi will produce a very different result from a mid-range phone on a mobile network.
That is why we prefer measurable performance targets. Google's current Core Web Vitals focus on three things: how quickly the main content appears, how responsive the page is when someone interacts with it and whether the layout remains visually stable while loading.
Lab tools such as Lighthouse are useful during development. Real production data becomes even more important after launch because it shows how the website behaves for actual users, networks and devices.
A performance requirement should therefore define both the metric and the conditions, rather than simply asking for “a fast website.”
A Content Delivery Network (CDN) is not a workaround
We sometimes see a CDN treated as something that should only be added when a website turns out to be slow. In practice, it makes more sense to consider it as part of the infrastructure from the beginning.
A CDN is part of modern web infrastructure. If your server is located in New York and someone opens the website in Singapore, every request that has to travel back to the origin adds latency. A CDN caches suitable assets closer to the visitor, reducing the distance those requests need to travel and reducing load on the origin server.
Cloudflare, for example, caches static assets such as images, CSS and JavaScript by default, while more advanced caching behavior can be configured depending on the architecture of the website.
This does not mean a CDN can fix an inefficient website. It will not make excessive JavaScript disappear. It will not optimize a huge video automatically. And it will not solve every slow database request.
Analytics and third-party tools affect performance
A website can perform well during development and become noticeably heavier after marketing tools are added.
Google Analytics, Google Tag Manager, CRM tracking, heatmaps, A/B testing tools, chat widgets, embedded video players and advertising pixels all introduce additional requests and in many cases additional JavaScript.
Google's own web performance documentation lists analytics, metrics, video embeds and A/B testing among common third-party scripts that can affect page performance. It also warns that excessive tags and event listeners in a tag manager can create additional network requests and processing overhead.
That does not mean analytics should be removed. It means every integration should have a reason to exist. Before launch, we recommend reviewing the complete list of tracking and third-party services rather than continuously adding tools because another department requested them.
WordPress is not automatically slow
The same applies to CMS selection. WordPress is often blamed for slow websites, but WordPress itself is not necessarily the problem.
Hosting configuration, themes, plugins, database queries, caching and the way the frontend is built can all have a major effect on performance.
WordPress's own performance documentation specifically notes that server configuration, themes and plugin performance can significantly affect site speed and recommends removing unnecessary plugins and using caching where appropriate.
The problem usually appears when the CMS gradually becomes responsible for everything. A plugin is installed for forms. Another for analytics. Another for SEO. Another for optimization. Another adds a visual builder. Several more add functionality nobody remembers six months later.
Each individual decision may seem harmless. Together, they can create a very different website from the one that was originally tested.
This is why the CMS and plugin strategy should be part of the technical architecture, not something assembled after development.
Hosting matters more than many clients expect
Frontend optimization gets most of the attention, but the browser still has to receive a response from somewhere. A slow origin server creates a delay before the page has even had a chance to render.
Time to First Byte measures how long it takes for the first response from the server to reach the browser, and web.dev specifically points to server responsiveness as an important foundation for loading performance.
The right hosting setup depends on the website. A mostly static marketing website has very different requirements from a WordPress installation processing dynamic requests or a platform connected to external APIs.
Server resources, geographic location, caching, database performance and configuration all matter. WordPress's own documentation notes that server load and configuration can have a major impact on performance.
A $5 shared hosting plan and a properly configured production environment should not be expected to produce the same result.
And again, CDN and hosting are not competing solutions. A good CDN reduces the work reaching the origin, while a good origin still needs to respond efficiently when it is required.
Performance should be decided before launch
By the time a website reaches QA, most of its performance profile already exists. The creative direction has been approved. The media has been produced. The technology has been selected. The CMS has been implemented. Third-party tools have been chosen.
That is why we prefer to agree on several things much earlier:
- how important performance is relative to visual complexity;
- which devices and markets matter most;
- how much motion, video and 3D the experience requires;
- which CMS and integrations are actually necessary;
- where the website will be hosted;
- whether a CDN will be used;
- which analytics and marketing tools need to run in production.
There is nothing wrong with building a visually ambitious website.
There is also nothing wrong with prioritizing maximum performance. The problem begins when both are treated as unlimited requirements with no trade-off between them.
A successful launch is not about removing everything interesting from a website to improve a Lighthouse score. It is about making deliberate decisions early enough that design, technology and performance support the same goal.
