“A slow website isn't a technical problem. It's a revenue problem dressed in technical clothes.”
Every performance audit we've run starts with this observationStart With a Baseline, Not a Guess
Before you change anything, measure. The most common mistake founders make when their site feels slow is jumping straight to solutions - switching hosting, compressing a few images, or installing a caching plugin - without knowing which problem actually costs them the most. You can do all three things and still have a slow site.
Run your site through Google PageSpeed Insights and note your Largest Contentful Paint, Total Blocking Time, and Cumulative Layout Shift scores separately for mobile and desktop. Mobile is the one that matters more - over 60% of web traffic is mobile, and Google indexes the mobile version of your site first. A site that scores 90 on desktop and 38 on mobile is a slow site.
Write down the scores before you touch anything. You need a before number to know whether your fix actually worked, and to prioritise which problem is worth the most to solve first.
The Most Common Cause: Unoptimised Images
Images are responsible for the majority of slow LCP scores. A typical startup homepage contains 2 to 5 MB of image data when it should contain under 500KB. This happens because the person who built the site uploaded files directly from a design tool like Figma or a stock photo library without converting or compressing them.
A 3,000 x 2,000 pixel JPEG displayed at 600 x 400 pixels on screen is sending 5x more data than the browser will ever use. Converting that same image to WebP typically reduces file size by 25 to 35% on top of correct resizing. These two changes alone - right format, right dimensions - solve a large proportion of slow LCP problems without touching anything else.
If your site is built on Next.js, the next/image component handles most of this automatically. If it's on WordPress, plugins like ShortPixel or Imagify automate the conversion. If it's a custom build that's not using any optimisation pipeline, that gap needs to be filled deliberately - it won't fix itself.
Too Much JavaScript Loading Too Early
JavaScript is the second biggest slow-site culprit and the harder one to diagnose without developer tools. Every script your page loads - analytics, chat widgets, A/B testing tools, cookie consent managers, social embeds - has to be downloaded, parsed, and executed by the browser. Each one adds to the time before your page is usable.
Open Chrome DevTools, go to the Network tab, filter by JS, and reload the page. Sort by size. If you see third-party scripts larger than 50KB loading before your content, they are likely blocking your page from rendering. A Hotjar tracking script, a Intercom widget, and a Facebook Pixel together can add 300 to 500 milliseconds of blocking time before a user sees anything.
The fix is loading third-party scripts asynchronously or deferring them until after the page paints. Most analytics and chat tools load fine this way and it has no effect on their function. The scripts your users see should load first. Everything you use to monitor them can wait.
Slow Server Response Times
Time to First Byte (TTFB) measures how long your server takes to respond to a request before the browser can start loading anything. Google considers under 800ms good. If your TTFB is above that, your entire site is starting late and all other optimisations are working uphill.
- Shared hosting plans often produce TTFB over 1,500ms under normal load
- Single-region servers cause slow responses for users geographically far from the data centre
- Unoptimised database queries on dynamic sites can hold the server response until the query completes
- Missing server-side caching means the server rebuilds every page on every request
- PHP-based sites (WordPress) without object caching are especially vulnerable to this under traffic spikes
The fix depends on the cause. A CDN like Cloudflare solves the geographic distance problem for static assets. Moving to a faster hosting tier (Vercel, Railway, or a managed VPS) solves shared-hosting TTFB. Server-side caching with Redis or Varnish solves the rebuild-on-every-request problem. You need to know which one you're dealing with before you can fix it.
Render-Blocking Resources
When a browser encounters a CSS or JavaScript file in the head of your HTML, it stops rendering the page until that file is downloaded and processed. These are render-blocking resources. Every millisecond spent waiting for them is a millisecond the user stares at a blank or partial screen.
Google Fonts is a common offender. A standard Google Fonts embed loads two requests before the page can paint - one to resolve the fonts.googleapis.com domain and one to download the stylesheet. Adding a preconnect hint for fonts.googleapis.com and fonts.gstatic.com, and using font-display: swap, reduces the blocking impact to near zero.
The Hosting and CDN Gap
A surprising number of startup sites are still on shared hosting - either because the original developer picked whatever was cheapest, or because the site was migrated without reconsidering the infrastructure. Shared hosting puts your site on a server with hundreds of other sites and allocates a fixed slice of CPU and memory. Under any real traffic load, response times degrade.
Moving to Vercel or Netlify for a static or Next.js site, or to a managed VPS for a WordPress site, is usually the single highest-leverage infrastructure change available. Vercel in particular serves static assets from edge locations globally, which collapses TTFB for most visitors to under 100ms without any code changes.
When the Problem Is the Build Itself
Sometimes the root cause is not configuration or hosting - it's the way the site was built. Sites generated by AI tools like Bolt, Lovable, or v0 often produce functional code quickly but with performance trade-offs baked in: everything bundled into one large JavaScript file, no image optimisation pipeline, no lazy loading. The site works, but it was never built to be fast.
In these cases, incremental fixes have a ceiling. You can compress images and defer scripts and still find the site scores poorly because the underlying architecture sends 1.5MB of JavaScript on every page load. The right call is a focused rebuild of the parts that cause the most damage - not necessarily the whole site, but the critical rendering path.
This is exactly where Zovintra's technical audit work sits. We diagnose what is actually slowing your site, separate the quick wins from the architectural issues, and either fix what can be fixed fast or scope a targeted rebuild for what can't. If your PageSpeed score is under 60 on mobile and you're not sure why, that's the right starting point for a conversation.
