Three things that
make your app fast.

This is nearly always the whole problem. A PNG straight out of Figma can be ten times bigger than it needs to be, and WebP does the same job at a fraction of the size. Nobody can see the difference. Your loading time can halve.

Look at this page: [paste your URL]

List the images that are slowing it down.
For each one tell me:
- the file size and the format
- what it should be instead
- roughly how much I would save

Then tell me which single image is costing me
the most, so I can start there.

I am not technical. Skip anything that needs
me to edit code unless there is no other way.

The steps, click by click

1. 1

   Open your site, right click the biggest image on the page, and choose Inspect. The panel that opens shows the file size. If it is over 200KB for a normal photo, that is your problem sitting right there.

2. 2

   Go to squoosh.app and drag that image onto the page. Nothing uploads to a server, it converts in your browser.

3. 3

   On the right hand side there is a dropdown that probably says MozJPEG or PNG. Change it to WebP. Watch the file size number underneath change, usually to something between a quarter and a tenth of what it was.

4. 4

   Drag the slider in the middle of the picture left and right. That is a before and after. If you cannot see a difference, and you almost certainly cannot, click the download arrow at the bottom right.

5. 5

   Replace the old file with the new one wherever your images live, then do the same for the next five biggest. Five is enough to feel it. You are not trying to finish today.

Done when: Reload your live site and check that biggest image again in Inspect. The number should be a fraction of what it was, and the page should feel different before you have measured anything.

If it looks different: If your images come out of a CMS or are uploaded by users, converting them by hand will not hold, because the next upload undoes it. That is the case for the Next.js Image component or an equivalent on your platform, which does the conversion automatically every time. Worth twenty minutes of a developer's time once.

Most slow apps are downloading code and fonts for pages the visitor is not looking at. A font you tried once and abandoned, an animation library used on one screen, an analytics tag from a tool you stopped paying for. It all still ships.

I ran PageSpeed Insights on my site and it
says I have unused JavaScript and unused CSS.

Here is what it listed:
[paste the file names and sizes from the report]

For each one tell me in plain English:
- what it probably is
- whether it is safe to remove
- how I remove it, step by step

My app is built with [say what you used, e.g.
Next.js, or Claude built it and I am not sure].

The steps, click by click

1. 1

   Run your site through pagespeed.web.dev first. Scroll to the section called Diagnostics and look for Reduce unused JavaScript and Reduce unused CSS. It lists the actual files and how much of each is wasted.

2. 2

   Start with your fonts, because it is the easiest and safest cut. Find where fonts load in your project and count the weights. If you are loading Light, Regular, Medium, Bold and Black but your site only ever uses two of them, delete the rest.

3. 3

   Now look at the list for anything you recognise as a tool you no longer use. An old analytics script, a chat widget you removed the button for, a library from a feature you cut. Those are safe deletions.

4. 4

   Anything you do not recognise, leave alone and ask Claude with the prompt above. Deleting something you cannot name is how you break a working app to save 40KB.

Done when: Run PageSpeed Insights again. The unused JavaScript and unused CSS numbers should both be smaller, and your score should have moved.

If it looks different: If the report lists files with names like chunk-4f8a2b.js and nothing recognisable, that is bundled code and you cannot pick it apart by hand. That is a genuine developer job. Do items 01 and 03 instead, they will give you most of the win anyway.

This is last on the list and it is the one that makes the other two mean anything. Without a number before and after, you are redecorating in the dark. It is also free and takes about thirty seconds to run.

Here is my PageSpeed Insights result:
[paste the whole thing, or the scores and
the top few Opportunities]

Tell me:
- what is actually wrong, in plain English
- the ONE thing to fix first for the biggest gain
- roughly how much faster that will make it
- whether I can do it myself or need a developer

Ignore anything that would save less than
half a second. I do not want a list of twenty
things, I want the one that matters.

The steps, click by click

1. 1

   Go to pagespeed.web.dev, paste your live URL, press Analyze. Wait about thirty seconds.

2. 2

   Screenshot the result before you change anything. This is your before. Without it you will genuinely not remember whether it was 41 or 61 last week.

3. 3

   Look at Mobile first, not Desktop. Almost everyone visiting you is on a phone on ordinary data, and the mobile score is usually much worse and much more honest.

4. 4

   Scroll to Opportunities. It is already sorted by how much time each fix saves. Do the top one. Ignore the rest for now.

5. 5

   Make that one change, wait a few minutes, and run it again. If the number moved, you learned something real. If it did not, you just saved yourself from doing nineteen more things that would also not have worked.

Done when: You have a before screenshot and an after screenshot, and the number went up. That is the whole job.

If it looks different: If your score bounces around by ten points between runs, that is normal. The lab test simulates a slower device and there is variance. Run it three times and take the middle one, or trust the real-visitor section instead, which is averaged over 28 days.