Performance problems are easy to miss when you build on a fast laptop and a good connection.
Your users will not all have that setup.
They will arrive on older phones, weak signal, battery saver mode, private browsers, corporate devices and impatient moods.
If the page looks beautiful but loads slowly, the app feels unfinished.
Start with production build
Run:
npm run build
For Next.js apps, the production build often shows route sizes and warnings that development mode hides.
Ask your agent:
Review the production build output.
Identify:
- unusually large routes
- heavy shared JavaScript
- dynamic rendering where static would be enough
- warnings that could affect performance
- pages likely to have slow first load
The build output is not the whole story, but it tells you where to look.
Check images
Images are one of the fastest ways to ruin launch performance.
Look for:
- huge hero images
- PNGs where WebP or AVIF would work
- missing width and height
- images loaded eagerly below the fold
- unoptimized screenshots
- background images that do not scale well
- mobile users downloading desktop-sized assets
Search:
rg "<img|next/image|background-image|\\.png|\\.jpg|\\.webp"
Use this prompt:
Audit image usage in this app.
Find images that are too large, missing dimensions, missing responsive sizes, loaded eagerly without need, or likely to hurt LCP or layout shift.
Recommend exact fixes.
Check third-party scripts
Every script has a cost.
Common launch bloat comes from:
- analytics
- tag managers
- chat widgets
- heatmaps
- embedded videos
- social widgets
- A/B testing tools
- payment libraries
Search:
rg "script|iframe|gtag|analytics|hotjar|intercom|youtube|vimeo|pixel"
Ask:
Review third-party scripts and embeds.
For each one:
- explain why it is loaded
- whether it loads on every page
- whether it can be delayed
- whether it needs consent
- whether a static link or lightweight placeholder would be better
Do not embed heavy players or widgets just because they look convenient.
Understand Core Web Vitals
The three Core Web Vitals most founders should know:
- LCP: how quickly the main content appears
- INP: how quickly the page responds to interaction
- CLS: whether the layout jumps around
You do not need to become a performance engineer overnight.
You do need to know whether your app feels slow, jumpy or unresponsive.
Use this prompt:
Explain the likely Core Web Vitals risks in this app.
Focus on:
- largest contentful paint
- interaction responsiveness
- cumulative layout shift
- mobile performance
- third-party script impact
Provide fixes in priority order.
Mobile is not optional
Many AI-built apps are designed and tested in a desktop preview.
Before launch, check:
- hero text wraps cleanly
- CTAs are visible without awkward scrolling
- tap targets are large enough
- menus are reachable
- forms are usable with mobile keyboards
- cards do not overflow
- modals fit small screens
- tables degrade gracefully
Ask:
Review this app's mobile UX.
Find layout, tap target, menu, modal, form, overflow and readability issues that could affect launch conversion.
Prioritize fixes that require small code changes.
What PageLens can help with
PageLens checks public pages across performance and UX signals, including common image, layout, mobile and Core Web Vitals issues.
The useful part is not just seeing "performance could improve."
It is seeing which page, which issue, which evidence, and what to fix first.
Run PageLens after deployment, not only before. Performance often changes when real hosting, production assets, analytics and caching are involved.
The launch rule
If the homepage, pricing page, signup page or checkout path is slow, fix that before polishing long-tail pages.
Performance is not only technical.
It is trust.