Make the site fast on a phone and a slow connection
Help visitors see and use the important parts quickly, even on an ordinary phone or unreliable connection.
When to use this
Before launch, after adding many images or widgets, or when the site feels fine on your computer but slow on a phone.
Before you start
- A site with real content and representative images; placeholder-only tests can hide the actual problem.
- The one or two pages customers must be able to use quickly.
- A phone for the final human check, ideally once on Wi-Fi and once on a slower mobile connection.
- A list of third-party widgets you must keep, such as maps, video, chat, analytics or booking tools.
The prompt
Review the whole site for a visitor using a narrow phone screen and a slow connection. Improve speed without removing essential content, changing the brand or redesigning the pages. Start by testing the home page and [MOST IMPORTANT CUSTOMER PAGE] at a phone size with a simulated slow connection. Give me a short before list of what makes the visitor wait, what moves around while loading, and what cannot be controlled from inside this app. Then make the first visible section useful as soon as possible. Resize and compress images without making them visibly poor, use the right image size for the visitor's screen, and delay images and heavy sections below the first screen until the visitor approaches them. Do not delay the main image or content needed in the first screen. Remove only extra code, fonts, animations and repeated files that are genuinely unused. Keep form submission, visitor tracking, payments and other working connections intact. Load non-essential third-party widgets, which are tools supplied by another service such as a map or chat box, after the main content. Show a clear fallback if a map, video or other external tool fails. Reserve the correct space for images and cards before they load so buttons and text do not jump. Keep buttons responsive while background work finishes, and show a simple loading or error message instead of a blank screen. The style should remain [CURRENT BRAND FEELING]. After the changes, repeat the same phone and slow-connection test, compare it with the before list in plain language, and tell me which remaining delays come from services outside my control.
Already building? Paste this into your project. Starting fresh? Open a free account with a compatible builder below.
Build it on
What this creates
- A before-and-after plain-language speed review
- Better-sized and compressed images for different screens
- Faster first content and delayed non-essential sections
- Stable page spacing while images and cards load
- Clear fallbacks for slow or failed external widgets
Check it worked
Paste the prompt, wait for the build to finish, then confirm these — in plain language, no technical checks needed:
- On your phone, useful text and the main action appear before every lower-page image finishes loading
- The menu and main button respond while slower sections are still loading
- Text and buttons do not jump to a different place as images appear
- Images still look acceptably sharp and are not stretched
- On a deliberately slow test, the page shows a useful loading or error message instead of staying blank
- Your forms, payments, visitor tracking and other required connections still work after the speed changes
Something missing? That's normal — ask for it in one short follow-up message rather than re-running the whole prompt.
Next steps
Fix the heaviest page first
When one gallery, menu or catalog page is still noticeably slower
Focus only on [PAGE NAME]. Identify its three biggest causes of waiting, fix the ones this app controls, and keep [ESSENTIAL FEATURE OR IMAGE QUALITY] intact. Do not change other pages. Repeat the same slow-phone test and explain the difference in plain language.
You'll know it worked when: The chosen page becomes usable sooner without losing its essential content.
Make a heavy widget optional
When a map, video, chat or embedded tool slows the first view
Replace the automatic loading of [WIDGET] with a lightweight preview and a clear [BUTTON LABEL] button. Load the real widget only after the visitor chooses it. If loading fails, show [FALLBACK INFORMATION OR LINK] instead of a blank space.
You'll know it worked when: The page loads without waiting for the widget, which still opens when requested.
Prevent speed regressions
After the site is fast enough
Add a repeatable performance check for the home page and [IMPORTANT PAGE] at a phone size. Flag newly added images that are unnecessarily large, layout that jumps while loading, and third-party scripts that delay the main content. Give me a short checklist to run after future changes.
You'll know it worked when: You have a simple check that catches common slowdowns before publishing.
Watch out for
- The main image should not be delayed. Loading the first-screen image late can make the site feel slower. Delay only content that starts below the first screen.
- Compression can destroy important detail. Photographers, stores and food businesses should compare key images at phone and desktop sizes before accepting smaller files.
- Third-party widgets can dominate the wait. A heavy map, chat box or video may remain slow even after the rest is fixed. Delay it, show a placeholder, or remove it if it is not earning its cost.
- Your repeat visit can look faster than a customer's first visit. Test in a private window or cleared browser so saved files do not hide the real first-time experience.
- Performance changes can break quiet dependencies. Retest forms, payments, visitor tracking and sign-in rather than assuming a faster page still does everything.
Platform notes
All three core platforms can optimize the pages and files your app controls, but none can make a visitor's network or a slow third-party widget fast. Lovable's published-site search and performance review can confirm common problems. v0's standard app setup has strong image, font and loading tools when configured correctly. Base44 manages the system that publishes the app, so focus on your images, page structure and connections, and ask it to name anything the managed platform does not let it change.
Spend fewer credits
Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.
- Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
- Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
- Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
- One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
- Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
- Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.
The prompts on this page are written to do most of this work for you — that's the point of them.
Read the full guideRelated playbooks
Related prompts
Part of these kits
Last reviewed: 2026-07-27