Guides / Prompting and shipping

How to Make Your Website Faster: A Practical Checklist

Measure first, then fix what slows your site: images, JavaScript, fonts, third-party scripts and server response. With Core Web Vitals targets and AI prompts.

Mythex Team · 2026-09-29 · 7 min read

To make a website faster, measure it first with PageSpeed Insights, then fix the biggest cause it points to — usually oversized images, too much JavaScript, heavy fonts or third-party scripts. Aim for Google's Core Web Vitals "good" targets: main content visible within 2.5 seconds, responses to taps within 200 milliseconds, and almost no layout jumping. Most sites get there with a handful of changes, not a rewrite.

Measure before you change anything

Guessing wastes time. Two free tools cover almost everyone:

• PageSpeed Insights (pagespeed.web.dev) — paste a live URL. It shows field data from real Chrome users (if your site has enough traffic) and lab data from a simulated load, plus a list of specific problems.
• Lighthouse in Chrome DevTools — the same lab test, run on any page you can open, including a preview. Test in mobile mode; phones on slower networks are where problems show.

The numbers that matter are Google's Core Web Vitals. As of September 2026, Google's documentation on web.dev gives these "good" thresholds, measured at the 75th percentile of page loads:

INP replaced the older First Input Delay metric in 2024. If a tool still reports FID, it is out of date.

Write down your starting numbers. After each fix, test again so you know what helped.

Where the time goes: options and trade-offs

Each common cause has a fix, and each fix has a cost. Start with the ones at the top — they are the cheapest and the most common.

Images

Images are the most common problem and the easiest to fix. A 4,000-pixel photo shown at 800 pixels wide forces every visitor to download five times more than they see.

• Serve images at the size they are displayed, with responsive srcset sizes for phones and desktops.
• Use modern formats (WebP or AVIF) and sensible compression.
• Set width and height on every image so the browser reserves space. This alone fixes most layout shift.
• Lazy-load images below the fold with loading="lazy".
• Never lazy-load the main image at the top of the page. Google's LCP guidance is blunt about this: lazy-loading the LCP image always delays it. Give it fetchpriority="high" instead.

JavaScript

Many AI-built sites are single-page apps (SPAs): the browser downloads a JavaScript bundle and then draws the page. The bigger the bundle, the longer the blank screen. Fixes, in order of effort:

1. Remove what you don't use. Ask for a list of dependencies and cut libraries that were added once and forgotten — a date library for one date, a full icon pack for five icons.
2. Split per route. Load the code for the admin dashboard only when someone opens it, not on the home page.
3. Prerender public pages. A marketing page that ships as real HTML appears before any JavaScript runs. This also helps search engines; see SEO for AI-built websites.

Slow INP usually means one long task blocking the page — filtering a huge list on every keystroke, or re-rendering a whole table when one cell changes. Chrome DevTools' Performance panel shows which.

Fonts

Each font family and weight is another file. Two families and three or four weights are usually plenty. Preload the font used above the fold, use font-display: swap so text shows immediately, and self-host fonts if the external font service is slow for your visitors.

Third-party scripts

Chat widgets, analytics, heatmaps, ad pixels, embedded videos and social feeds all load code from other servers. Each one looks small; together they are often the slowest part of the page. Keep the ones you actually look at. Load the rest after the page is interactive, and replace heavy embeds (a YouTube player, a map) with a lightweight preview that loads the real thing on click.

Server response

Time to first byte (TTFB) — how long the server takes to start answering — sits underneath every other metric. Static pages served from a CDN (a network of servers close to your visitors; see what is a CDN) are fast almost everywhere. Pages built by a server on each request depend on that server and its database. Caching repeated work and adding database indexes for slow queries are the usual fixes.

Prompts that work

Be specific: name the page, the metric and the constraint. Paste the PageSpeed Insights findings if you have them.

PageSpeed Insights reports LCP of 4.8 s on mobile for the home page, and the LCP element is the hero image. Resize and convert the hero image to WebP, serve responsive sizes, set width and height, give it fetchpriority="high" and make sure it is not lazy-loaded. Lazy-load every image below the fold. Don't change the design.

Audit this app's dependencies. List each package, what uses it and roughly how much it adds to the bundle. Remove unused ones and split the /admin and /settings routes into separate chunks that load only when visited.

The search box on /products feels laggy. Debounce the filter, avoid re-rendering the whole list on each keystroke, and paginate or virtualise the list if it has more than 200 items.

Step by step

1. Test the live page in PageSpeed Insights on mobile. Note LCP, INP and CLS, and the top three problems listed.
2. Fix images first: sizes, formats, dimensions, lazy loading below the fold, priority for the hero.
3. Cut third-party scripts you don't use, and defer the rest.
4. Trim fonts to what the design needs.
5. Shrink JavaScript: remove unused packages, split per route.
6. Prerender public pages if they are still client-rendered and LCP is still slow.
7. Check the server: caching, database indexes, static hosting for content that rarely changes.
8. Republish and retest. Field data in PageSpeed Insights updates over the following weeks as real visits come in, so judge early results by lab data.

Common mistakes

• Testing only on a fast laptop. Your visitors are on mid-range phones and patchy mobile data. Test in mobile mode.
• Chasing a perfect 100. The lab score is a guide. Once Core Web Vitals are in the good range, content and usability matter more than the last few points.
• Lazy-loading everything, including the hero image. That makes LCP worse.
• Adding a speed plugin or library on top. Removing weight almost always beats adding code to manage it.
• Optimising the preview, not the live site. Development previews run unoptimised builds. Measure the published URL.
• Fixing speed once. Every new widget, image and feature adds weight. Retest after big changes.

Speed checklist

• LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 on mobile
• Images resized, compressed, modern format, with width and height
• Hero image not lazy-loaded; below-the-fold images lazy-loaded
• No unused JavaScript libraries; heavy routes split out
• Two font families or fewer, main font preloaded
• Only the third-party scripts you actually use, loaded late
• Public pages prerendered or static where possible
• Retested on the live URL after publishing

Speed and mobile layout go together; see how to make a website mobile responsive. For a full pre-launch pass, how to take an AI prototype to production covers the rest.

Speed on Mythex

On Mythex you make these changes by asking in chat, or in the code editor on Pro. Check the published URL, not the Preview, since Preview runs a development server. Static front ends deploy as static sites when you publish (static websites), which suits content pages. Apps with a server scale to zero: they sleep when idle and wake on the next visit, so the first request after a quiet spell is slower, and an attached database sleeps after 5 idle minutes (hosting limits). If a public page is slow only on the first visit, that is the likely cause. Keeping marketing pages static helps. After changes, publish again and hard-refresh.