Why Your App Feels Slow (And What Good Performance Actually Looks Like)
Akamai's research puts it at a 7% conversion drop per second of delay. Google uses page speed as a ranking signal. Users leave slow sites, and they don't always tell you why — they just leave.
Performance is a product feature. But it's one most founders don't have a framework for evaluating. Here's what you actually need to know.
The three metrics that matter
Google measures web performance using Core Web Vitals — three signals that together describe how a page feels to use:
| Metric | What it measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP | Load speed (when does the main content appear?) | < 2.5s | 2.5s – 4s | > 4s |
| CLS | Visual stability (does content jump around?) | < 0.1 | 0.1 – 0.25 | > 0.25 |
| INP | Interactivity (how fast do clicks and taps respond?) | < 200ms | 200ms – 500ms | > 500ms |
These aren't abstract engineering numbers. LCP is how long a user stares at a loading page before they see something useful. CLS is the frustration of a page layout shifting as you're about to click something. INP is whether buttons feel responsive or laggy.
Your product needs to be in the "Good" range for all three. If any are in "Poor", it's actively hurting you.
How to measure where you stand
You don't need a developer to check your score. Two free tools:
PageSpeed Insights (pagespeed.web.dev) — Enter your URL. Get a score with specific issues. Run it on your landing page, pricing page, and one key in-app page.
Google Search Console — If you've added your site, it shows Core Web Vitals data aggregated from real users visiting your site. This is field data, not lab data — it shows what users are actually experiencing.
Check these before and after any significant release. If scores drop, something changed.
The most common causes of slow pages
Unoptimised images — The biggest single contributor to slow pages. A 3MB JPEG that could be a 200KB WebP, loaded without lazy loading so the browser fetches everything at once. Your developer should be using modern image formats (WebP), appropriate sizes, and lazy loading for images below the fold.
Too much JavaScript — Every library you add makes the browser download, parse, and execute more code before the page becomes interactive. Large JavaScript bundles are invisible to you and painful for users on slower connections. Ask your developer to check your bundle size regularly.
Slow API calls — If your page waits for a server response before it renders anything, every millisecond of database latency shows up directly in your LCP. Server-side rendering (which Nuxt provides) fetches data on the server and delivers a complete page — users see content immediately.
Unoptimised web fonts — Loading a Google Font incorrectly can block rendering and cause text to be invisible while the font loads. Font optimisation is a small thing that's worth doing right from the start.
What your developer should be doing
For most Nuxt applications, the high-impact items are:
- Images via @nuxt/image — automatically converts to WebP, generates responsive sizes, applies lazy loading. This single change often improves LCP significantly.
- Pre-rendering marketing pages — your landing page, pricing, blog, and feature pages don't change per user. They should be pre-built and served from a CDN as static HTML. Sub-100ms response times globally, zero server load.
- Bundle analysis — periodically checking what's included in the JavaScript bundle and removing things that aren't needed. Large third-party libraries are the usual culprit.
- Deferred third-party scripts — analytics tools, chat widgets, and other third-party scripts should load after your core content. They shouldn't block the page from rendering.
The conversation to have with your developer
When you're planning a release, ask:
- What's our current Lighthouse score on the main pages?
- Are images being served in WebP format?
- Are our marketing pages pre-rendered?
- Did we add any new third-party scripts? How are they loaded?
You don't need to understand the implementation. You need to know that someone is paying attention to it, and that "passing" means something specific (Green on Core Web Vitals, not "it seems fine to me").
Performance debt compounds. A site that's slightly slow at launch becomes noticeably slow as you add features. Building the discipline of measuring it is more valuable than any single optimization.