Guides / General / Fixing problems

Check Your Page Speed with PageSpeed Insights and Fix It

By the Qorlize team · Last reviewed November 12, 2026

You run your page through Google's PageSpeed Insights and get an orange 54 on mobile, a long list of warnings about JavaScript, images and caching, and a desktop score of 92 that seems to contradict it. For a one-page site, most of that report does not matter. A few numbers do, and the fixes for a small static page are usually short and in a predictable order.

Running the test

Open pagespeed.web.dev, paste the full address of your published page and press Analyze. The page must be online; PageSpeed Insights cannot test a file on your computer or a page behind a login. The report has separate Mobile and Desktop views. Look at mobile first: the mobile test simulates a mid-range phone on a mobile network, which is closer to how many visitors arrive from a shared link, and it is almost always the lower score.

Field data and lab data are different things

The report has two parts, and mixing them up causes most of the confusion.

Field data comes from the Chrome User Experience Report (CrUX): measurements from real Chrome users who visited the page over the previous 28 days. It shows what visitors actually experienced. Google's documentation says that if the page does not have enough visits, PageSpeed Insights falls back to data for the whole origin (your domain), and if the origin does not have enough either, no field data is shown. For a new or small site, "no data" here is normal and not a sign that anything is wrong.
Lab data comes from Lighthouse, which loads the page once in a controlled, simulated environment. It produces the 0 to 100 performance score and the list of suggestions. It is useful for finding causes, but it is one simulated visit, so the score moves a few points between runs.

The score bands are 90 and above for good, 50 to 89 for needs improvement, and below 50 for poor. If the field data says the page passes and the lab score is 70, your real visitors are fine. If there is no field data, use the lab data as your guide.

LCP, INP and CLS

These three metrics are Google's Core Web Vitals. Each is judged at the 75th percentile of visits, meaning three out of four visits must reach the target, and a page passes the Core Web Vitals assessment when all three are good. The thresholds, as published on web.dev and in the PageSpeed Insights documentation:

Metric	Measures	Good	Needs improvement	Poor
LCP, Largest Contentful Paint	When the biggest image or text block in the first screen finishes appearing	2.5 s or less	up to 4 s	over 4 s
INP, Interaction to Next Paint	How quickly the page visibly responds after a tap, click or key press	200 ms or less	up to 500 ms	over 500 ms
CLS, Cumulative Layout Shift	How much content jumps around while loading	0.1 or less	up to 0.25	over 0.25

INP needs real interactions, so it appears only in field data. The lab section shows Total Blocking Time instead, which measures how long scripts keep the browser busy during loading; a high value there usually means a poor INP for real users.

On a simple page, LCP is almost always the hero image or the main heading, and the diagnostics in the lab section usually name the LCP element. That tells you exactly which file to look at.

What usually slows a small site

Huge images. A 4 MB photo from a phone, displayed 800 pixels wide, is the single most common cause of a slow LCP. The browser has to download all of it before the hero appears. PageSpeed Insights usually flags it among its image suggestions, often with an estimate of how much could be saved.

Web fonts. Each font file is another download, and Korean fonts are large because they cover thousands of characters. A page that loads three weights of two families can wait on several hundred kilobytes of fonts before text appears, or show text that reflows when the font arrives.

Third-party scripts. Chat widgets, analytics tags, embedded maps, video players, social feeds and the Tailwind CDN script that many AI-generated pages include. Each one downloads and runs code you do not control. They hurt Total Blocking Time and INP more than LCP.

Images without dimensions. If an <img> has no width and height attributes, the browser does not know how much space to reserve, so the text below jumps down when the picture loads. That is CLS. Banners and cookie notices that push content down after loading do the same.

Fixes in order of payoff

Resize and compress the images. This is usually the biggest win by far. Scale each image to roughly the largest width it is shown at (1200 to 1920 pixels for full-width banners, less for body images), then compress as WebP or JPEG at a quality around 75 to 85. A tool such as Finipix does this in the browser for a batch of images, with presets for body images, banners and thumbnails. Making images smaller for the web walks through it, and web image formats and sizes helps choose the format.
Add width and height to every image. Use the image's actual pixel dimensions, for example width="1200" height="800", and keep height: auto in your CSS so it still scales. The browser uses the ratio to reserve space, which fixes most CLS.
Do not lazy-load the hero. loading="lazy" is good for images further down the page, but on the LCP image it delays the very thing being measured. Remove it from the first screen's main image.
Trim the fonts. Use one family in two weights, not three families in five. Add &display=swap to a Google Fonts link (or font-display: swap in your own @font-face) so text shows immediately in a fallback font. How fonts work on a web page covers Korean fonts and subsets.
Question every third-party script. Remove widgets nobody uses. Replace an embedded map with a static image linked to the map, and an embedded video with a thumbnail that links to it, if the embed is not essential.
Then look at the rest. Suggestions about unused CSS, caching headers or server response time matter less for a small static page, and some depend on your host's settings rather than your file.

Test again after each change, and run the test two or three times. The lab score varies between runs; a change of a few points means nothing, a change from 50 to 85 does.

After the fixes

Field data takes up to 28 days to reflect changes, because it is a rolling window of real visits. The lab score updates immediately. If your page is small and has no field data, aim for a mobile lab score in the 90s, an LCP under 2.5 seconds and a CLS near zero, and then stop: past that point, your time is better spent on the content. Before publishing a new version, the landing page checklist covers the other things worth checking.

Want to try it on your own file? Open the Finipage editor. It runs in your browser and your file stays on your device.