Fast enough is the target, and you are probably not there yet

AI builders optimise for producing something that works. Nothing in that process is trying to keep your page small, and three specific problems show up again and again as a result.

Run the free check

AI-built apps commonly ship three performance problems: unoptimised images at full camera resolution, a JavaScript bundle containing libraries used once or not at all, and fonts that block rendering while they download. Fixing the images is usually the largest single improvement and the easiest, and fast enough rather than perfect is the correct target.

How much this actually matters

Let us be honest about the size of this before spending an evening on it, because performance advice is often oversold.

Speed is one signal among many, and a fast page about nothing still ranks for nothing. If your app is not indexed, or has one page, or blocks crawlers, those problems are larger than this one by a wide margin and should be fixed first.

Where it genuinely matters is the human side. A page that takes several seconds to show anything on a phone on an ordinary connection loses people before they see what you built, and those people do not come back to try again.

So the target is fast enough rather than perfect. The difference between a good score and an excellent one will not decide anything. The difference between four seconds and one second will.

Problem one: the images

This is nearly always the largest single problem and the easiest to fix, so it is the one to do first.

Images arrive from a camera, a stock site, or a generator at full resolution, several thousand pixels wide and often several megabytes each. They get used directly, and the browser downloads the whole file and then displays it in a space a few hundred pixels wide on a phone.

Three fixes, in order of effect. Resize to roughly the size it is actually displayed at, which for most web images means no more than about 1600 pixels wide. Convert to a modern format such as WebP, which is substantially smaller than JPEG or PNG at comparable quality. And add lazy loading so images below the fold are fetched when needed rather than all at once.

For a page with a few large photographs, doing this alone often removes most of the page weight.

Problem two: the bundle

When you ask an AI builder for a feature, it reaches for a library, which is usually the right call and it accumulates.

The result after a few months of iteration is a JavaScript bundle containing several libraries used once, one or two used nowhere at all because the feature was removed but the import survived, and often two libraries doing the same job because different sessions made different choices.

The visitor downloads all of it before the page becomes interactive.

The fixes are ordinary. Look at what is actually in your bundle, remove anything not used, replace anything heavy used for one small thing, and split the bundle so a visitor downloads what the current page needs rather than everything the app can do. That last one matters most on an app with several distinct sections.

Problem three: the fonts

Custom fonts are the quiet one, because the page looks fine when you test it locally where everything is cached.

A font file has to be downloaded before text can be drawn in it. Depending on how it is loaded, the browser may show nothing at all while it waits, so a visitor on a slow connection sees a blank area where your headline should be.

Three things help. Load fonts from your own domain rather than a third party, which removes a connection to another server before anything can start. Set the font display behaviour so text is shown immediately in a fallback and swapped when the custom font arrives, so nothing is invisible. And load only the weights you actually use, since a family loaded in six weights when the design uses two is five sixths wasted.

The simplest fix of all is worth mentioning: using a system font stack costs nothing to download and is perfectly respectable.

Measuring it honestly

Do not judge performance by loading your own site on your own machine. Your connection is good, the files are cached, and you are the least representative visitor available.

Test on a phone, on a mobile connection, with a cleared cache. That is the experience most of your visitors have, and it is usually considerably worse than the one you have been assuming.

The measurement worth caring about is how long until the visitor sees the main content and can interact with it. Composite scores are a reasonable summary and it is easy to spend a week improving a number without improving anything a person would notice.

Measure before and after each change so you know which fix did what. Otherwise you cannot tell an evening well spent from an evening wasted.

What to skip

A short list, because performance work has an unusually high proportion of effort that produces nothing.

Skip chasing a perfect score. The last portion of any performance score is disproportionately expensive and produces no difference a visitor could perceive.

Skip a content delivery network for a small site with a local audience, at least until there is evidence you need one.

Skip micro-optimising your own code before addressing the images, the bundle and the fonts, since those three account for most of the weight on almost every app of this kind.

And skip removing a feature people use in order to save a small amount of load time. The product matters more than the number.

Part of a larger guide

This page is one part of The fixes. The other parts:

Questions people ask

How much does page speed matter for SEO?
It is one signal among many, and a fast page about nothing still ranks for nothing. If your app is unindexed, has one page, or blocks crawlers, those are much larger problems. Where speed genuinely matters is the human side, since a page taking several seconds on a phone loses people before they see it.
What is the biggest performance problem in AI-built apps?
Images, almost always. They arrive at full camera resolution, often several megabytes each, and get used directly while being displayed a few hundred pixels wide on a phone. Resizing, converting to a modern format like WebP, and lazy loading often removes most of a page's weight.
Why is my JavaScript bundle so large?
Because each feature request reaches for a library and they accumulate. After a few months you typically have libraries used once, imports left behind by removed features, and sometimes two libraries doing the same job. The visitor downloads all of it before the page becomes interactive.
Are custom fonts a performance problem?
They can be, and it hides locally where everything is cached. A font must download before text can be drawn in it, and depending on how it is loaded the browser may show nothing while waiting. Serve fonts from your own domain, set the display behaviour to show fallback text immediately, and load only the weights you use.
How should I test my site's speed?
On a phone, on a mobile connection, with a cleared cache. Loading your own site on your own machine tells you almost nothing, because your connection is good, the files are cached, and you are the least representative visitor available.
Do I need a perfect performance score?
No. The last portion of any performance score is disproportionately expensive and produces no difference a visitor could perceive. Fast enough is the target: the gap between four seconds and one second matters, the gap between good and excellent does not.

Get the technical list scored

The free Get Found Check covers the technical items on your domain and tells you which ones are worth an evening and which are already fine.

Run the free check Have Licheo do it for you