If your AI-built website is slow, measure before you change anything. Run it through PageSpeed Insights, check whether it's slow for everyone or only for some visitors, then fix the usual causes in order: oversized images, too much JavaScript, and a server far from your users. For many student sites, those three fixes matter more than switching tools.
My AI-built website is slow: what can a student actually fix?
You described a product to an AI coding assistant, it built the site, and you deployed it. Then a friend opened the link on their phone and waited. And waited.
This is a common problem with AI-built sites, and usually a fixable one. The code works, but nobody told the assistant to keep it light. The good news is that speed problems are measurable, and once you know which one you have, the fix is usually a short prompt and a redeploy.
Is it slow for everyone, or only for some visitors?
Start here, because the answer decides the fix.
PageSpeed Insights reports two kinds of data. Field data comes from real Chrome users over the previous 28 days, when your site has enough traffic. Lab data comes from one simulated page load: for mobile, a mid-tier phone on a mobile network. Google's documentation notes the two can differ, because real users have many different devices and connections, while the lab test has exactly one.
For a new student project, you'll usually only get lab data. That's fine. Run the mobile test, not just desktop, because that's what most people will open your link on.
Then ask: does the site feel slow to everyone, or mainly to people far from where it's hosted? If it's slow everywhere, the problem is almost always the page itself. If it's fine nearby and slow far away, the problem is distance to the server.
What the guidance agrees on
The official guides come at speed from different angles, but they point to the same few causes.
There are three numbers to watch. Google's Core Web Vitals guide defines good as the main content appearing within 2.5 seconds (Largest Contentful Paint), the page responding to a tap within 200 milliseconds (Interaction to Next Paint), and the layout not jumping around (a Cumulative Layout Shift of 0.1 or less). It recommends judging these at the 75th percentile of page loads, split by mobile and desktop.
Don't load what nobody has scrolled to yet. MDN's guide to lazy loading explains that adding loading="lazy" to images and embedded frames tells the browser to wait until the user scrolls near them. No JavaScript is needed, and the first screen loads faster.
Distance to the server is real. A web.dev article on content delivery networks explains that a CDN serves your files from servers closer to the user, cutting round-trip time. In its words, CDN servers "are located closer to users than origin servers." It recommends serving as much of the site as possible through a CDN, especially images and other static files.
Put together: heavy pages make everyone wait, and distance adds to it for visitors far from your server.
Where the guidance disagrees or goes quiet
How much speed matters for search. Google's page experience documentation says Core Web Vitals are used by its ranking systems, but it also says Google always tries to show the most relevant content "even if the page experience is sub-par." It cautions that chasing perfect scores only for SEO may not be worth it. So a faster site won't rescue a page nobody needs. Fix speed for your users, not for a score.
AI-generated code. None of these guides was written with AI coding assistants in mind. Unless you ask otherwise, an assistant may reach for defaults that add weight: a large UI library for one button, an animation package for a fade-in, a 4,000-pixel photo where an 800-pixel one would do. Check your own project for these rather than assuming. The guides tell you what to measure. They don't tell you that the fastest fix is often deleting something the assistant added.
A fix-it checklist, in order
Do these one at a time, redeploy, and retest after each. That way you know what helped.
| Step | What to check | What to ask your AI assistant |
|---|---|---|
| 1 | Images larger than they're displayed | "Resize and compress every image to the size it's shown, and use a modern format like WebP." |
| 2 | Images below the first screen | "Add loading="lazy" to images and iframes that aren't visible on first load." |
| 3 | Unused libraries | "List every dependency and tell me which ones this site doesn't need. Remove them." |
| 4 | Big scripts on first load | "Load heavy components only when they're needed, not on first page load." |
| 5 | Data loaded one request at a time | "Find any requests that wait on each other but don't need to, and run them in parallel." |
| 6 | Server far from users | Check where your host serves the site from, and whether it uses a CDN. |
| 7 | Layout that jumps while loading | "Give images and embeds fixed width and height so the page doesn't shift." |
Two cautions. First, read what the assistant changed before you deploy it. "Remove unused libraries" sometimes removes one you need. Second, keep your old version in git so you can roll back.
What if it's slow only for people far away?
If your page is already light and distance is the problem, you have a few options, roughly in order of effort:
- Check your host's settings. Many platforms let you choose a region for servers or functions. Put it closest to most of your users.
- Use a CDN for static files. If your host doesn't already do it, put images, scripts and styles behind one.
- Make more of the site static. Pages that are pre-built files can be cached near users. Pages built on every request have to wait for the server.
- Accept a trade-off. For a first product, it's fine if a few distant visitors wait an extra second. Spend your time on the users you actually have.
How STARC approaches this
STARC is a small nonprofit, and its one-person company cohort asks students to get something live early: in week 0, one line of code on the internet; by week 2, version zero at a public URL. To graduate as "Shipped," a product has to be live at Demo Day with at least 10 real users who aren't classmates, friends or family, backed by evidence. A site that takes ten seconds to open on a phone loses people before they become users, so speed is part of shipping, not polish for later.
The first cohort hasn't run yet, so there are no past projects to point to. How the program works is on the How it works page, and common questions are in the FAQ.
The short version
Measure first, on mobile. If it's slow everywhere, shrink the images, cut the libraries the AI added, and lazy-load what's below the fold. If it's slow only far away, look at your server region and CDN. Then stop: a site that loads in a couple of seconds for the people who use it is fast enough to learn from.
Related questions
Is my site slow because AI wrote the code?
Not directly. AI coding assistants often add libraries and large components you didn't ask for, and they rarely resize images, so AI-built sites tend to be heavy. Those problems are easy to find with a speed test and easy to fix by asking the assistant for specific changes.
Does a slow site hurt how it ranks on Google?
It can, but less than people think. Google says Core Web Vitals are used by its ranking systems, but relevance comes first, and a perfect score is not worth chasing for search alone. Speed matters more for whether real visitors stay.
Why does my site feel fast to me but slow to my users?
You probably have a fast laptop, a good connection and a cached copy of the site. Your users may be on mid-range phones, on mobile data, or far from the server. Field data from real users, which PageSpeed Insights shows when there's enough traffic, tells you what they actually see.
Do I need a CDN for a student project?
If your users are spread out geographically, it can help, because a CDN serves files from servers closer to each visitor. Some hosting platforms already include one, so check what your host does before adding anything.
Want to build your own product?
The OPC cohort: 12 students, 8 weeks, one real product with real users.
Last updated: 2026-10-15. Written by the STARC team. Rules quoted here come from our transparency page; if they change, this post is updated.
More questions
Mobile app or web app: which should a student build first with AI?
For students building a first product with AI: why a web app is usually the better first build, when a mobile app is worth it, and the store rules to know.
Non-CS major applying for product manager jobs: does building your own product help?
For non-CS majors aiming at PM internships and APM roles: when a product you built yourself helps, when it doesn't, and what interviewers will ask.
Can I talk about a project I built with AI in a grad school interview?
How to present an AI-built project in a grad school interview: what faculty will probe, how to describe what AI did, and a 2-minute answer structure.