A high PageSpeed score does not always mean that a website is fast for every visitor. For reliable measurement, start with PageSpeed Insights, distinguish between Lab Data and Field Data, use Lighthouse or Chrome DevTools to find the cause, and then check both the metrics and the site's functionality again.
This process is suitable for beginners and does not require installing a large collection of tools. You need a publicly accessible URL and the Chrome browser if you want to use DevTools. Search Console access is needed only if you want to monitor data for the website. The goal is not to achieve a score of 100, but to make the main content appear quickly, keep the page responsive, maintain a stable layout, and reduce unnecessary resources.
Three aspects to measure before optimizing
Website performance is not just the time it takes to load the entire page. Start with three questions:
- Has the main content appeared? Largest Contentful Paint (LCP) indicates when the largest content element in the initial viewport is rendered.
- Does the page respond when users click or enter information? Interaction to Next Paint (INP) measures the responsiveness delay of interactions.
- Does the layout shift? Cumulative Layout Shift (CLS) measures visual stability during loading.
According to the Web Vitals guidance, the target thresholds at the 75th percentile are an LCP of no more than 2.5 seconds, an INP of no more than 200 milliseconds, and a CLS of no more than 0.1. These are targets for evaluating most users, not a guarantee that every device will achieve the same results; the thresholds may be updated in the official documentation (see web.dev).
Performance should also be considered alongside usability. A website can be fast, but if its text is difficult to read, its buttons are too small, or its layout is difficult to use on a touchscreen, it still provides a poor experience. See also how to test a website on a phone.
Choose a tool based on the question you need to answer
| Tool | Primary data | When should you use it? | Limitations |
|---|---|---|---|
| PageSpeed Insights | Lighthouse and real-user data from CrUX | Quickly check a public URL | Field Data may not be available for new websites or sites with little data |
| Lighthouse | Simulated checks for Performance, Accessibility, Best Practices, and SEO | Find optimization opportunities in a relatively controlled environment | Results vary according to the device, network, browser, and machine condition |
| Chrome DevTools Performance | CPU, network, rendering, long-task, and interaction traces | Diagnose underlying causes in greater depth | You need to know how to read recordings and should test multiple scenarios |
| CrUX or Search Console | Real-user experience data | Evaluate how the website performs in real-world use | Not every URL or website has sufficient data |
PageSpeed Insights: Where to start
Open PageSpeed Insights, enter the full URL of the page you want to test, and review the two sections separately: Field Data and Lab Data. PageSpeed Insights combines real-user data from the Chrome User Experience Report (CrUX) with the simulated analysis performed by Lighthouse (see developers.google.com).
- Field Data: shows how real users experienced the page during the period when the data was collected.
- Lab Data: recreates a specific test condition to identify optimization opportunities and diagnose technical issues.
The two sections may produce different results, and that does not necessarily indicate an error. Lab Data uses a simulated environment, whereas Field Data aggregates results from different devices, networks, and contexts. Therefore, a page with a high Lighthouse score may still deliver poor LCP or INP for some users.
Lighthouse: Find optimization opportunities
Lighthouse can run in PageSpeed Insights, Chrome DevTools, the command line, or as a Node.js module. When reading the report, open the details for each item instead of looking only at the overall score. Warnings about below-the-fold images, render-blocking CSS, or JavaScript that increases processing time are often more useful than a single score (according to developer.chrome.com).
Chrome DevTools: Identify the cause
On a computer with Chrome installed, open the page you want to test in an incognito window to reduce the influence of browser extensions if necessary. Press F12 or Ctrl + Shift + I on Windows/Linux, select Performance, then click Record. Reload the page or perform a specific action, such as opening a menu, running a search, or submitting a form; then stop the recording.
- Main thread: find long tasks that prevent the browser from responding promptly.
- Network: find resources that take a long time to load, are large, or come from too many domains.
- Rendering and Layout: check whether the browser is recalculating the layout or repainting too often.
- Interactions: try real interactions, because INP issues may appear only after scrolling, opening a filter, or entering data.
DevTools lets you record a CPU profile and analyze runtime bottlenecks; Performance Monitor also displays CPU usage, JavaScript memory, the number of DOM nodes, and the number of layout calculations (according to developer.chrome.com).
A repeatable measurement and optimization process
1. Select URLs and record a baseline
Select at least one representative URL for each important page type: the homepage or a landing page, an article or category page, a product page or form, and a page with many images, advertisements, videos, or tracking scripts.
Record the test date, URL, device type, LCP, INP, CLS, TTFB, downloaded data size, number of network requests, and key warnings. Test the same URL several times under broadly comparable conditions, and record the trend rather than drawing conclusions from a single run.
2. Classify the cause before making changes
| Symptom | Cause to investigate | First action to take |
|---|---|---|
| High LCP | A large hero image, a slow server response, or delayed CSS or other critical resources | Identify the LCP element, then check TTFB, image dimensions, and render-blocking resources |
| High INP | Long-running JavaScript, long tasks, too many event handlers, or third-party code | Record a Performance trace, find long tasks, and reduce work on the main thread |
| High CLS | Images, advertisements, iframes, or dynamic content without predetermined dimensions | Reserve space before the resource loads |
| High TTFB | The server, database queries, caching, or server location | Check the HTML response time before changing the frontend |
3. Optimize images
Export images close to their rendered dimensions, compress them before uploading, and use an appropriate format. For images below the fold, you can use loading="lazy"; do not defer an image that produces the LCP, because the main content may appear later (according to web.dev).
<!-- Ảnh trong vùng nhìn đầu tiên: thay URL và alt bằng dữ liệu thật -->
<img src="hero.webp"
width="1200"
height="630"
alt="Mô tả ngắn cho ảnh đầu trang"
fetchpriority="high">
<!-- Ảnh bên dưới vùng nhìn đầu tiên -->
<img src="bai-viet-1.webp"
width="800"
height="450"
loading="lazy"
alt="Mô tả ngắn cho ảnh">Place the code above in the HTML or the template where the image is rendered. Replace hero.webp, bai-viet-1.webp and the content alt with the actual resources. width and height help the browser reserve space, reducing the risk of CLS.
4. Reduce JavaScript and third-party resources
Review libraries, plugins, advertisements, analytics tools, chat widgets, embedded maps, and A/B testing scripts. Third-party code can create additional connections, load more code, consume processing time, and delay rendering (according to web.dev).
- Remove code that is no longer used instead of merely deferring everything.
- Load a feature only when it is needed—for example, load a map after the user clicks to open it.
- Use
deferfor scripts that do not need to run before the HTML has been parsed. - Do not install two tools with the same function unless there is a clear reason to do so.
- After making changes, test sign-in, forms, payments and conversion tracking.
5. Address render-blocking CSS
CSS commonly blocks rendering because the browser must build the CSS object model (CSSOM) before it can build the render tree. Remove unused CSS, separate CSS intended only for specific pages or components, and deliver critical CSS early (according to web.dev).
Do not automatically inline all CSS. This can make the HTML larger and reduce caching efficiency. Compare size, load time and functionality before and after the change.
6. Check the server, caching and CDN
If TTFB is high, optimizing images or browser-side JavaScript will not resolve the server wait time. Check caching for HTML, CSS, JavaScript and static images; database queries; server load; response compression; HTTP/2 or HTTP/3; HTTPS; and the distance between the server, CDN and primary user groups.
If you do not administer the server, send the TTFB measurements, URL and test time to your hosting provider. Before changing the cache, record what is cached, its expiration time and how to clear it. After deployment, clear the cache according to the correct procedure and test again.
Example: An article page with high LCP
Hypothetical example: PageSpeed Insights shows poor LCP but stable CLS; the LCP element is a large hero image that is detected only after JavaScript runs.
- Export the image at close to the largest display size you need to support.
- Convert it to an appropriate format and compress it.
- Place the image URL in the initial HTML instead of inserting it with JavaScript.
- Do not set
loading="lazy"for the hero image. - Reserve
widthandheight. - Measure the same URL and device type again.
If LCP remains high, check TTFB and render-blocking CSS next. Do not immediately move on to fixing JavaScript if the trace shows that most of the time is spent on the server or loading the image.
Verify, document and roll back after making changes
Before modifying a plugin, theme code, cache configuration or script, back up the current version or save it as a versioned copy, and document the change clearly. If the website has a staging environment, test there first; otherwise, change one small group of items at a time when you can monitor for errors.
- Run the same URL again using the tool and approximately equivalent conditions.
- Compare LCP, INP, CLS, TTFB and download size.
- Open the page on a real mobile device if the website serves mobile users.
- Try scrolling, opening the menu, submitting a form, searching, adding a product or completing a payment.
- Check for JavaScript errors, images that fail to load, layout shifts and tracking code.
- If an error appears, restore the version or setting you just changed, clear the cache according to the platform's procedure, then measure and test again.
Real-user data usually does not change immediately after a fix. CrUX includes only URLs or origins that meet certain data-availability conditions, so use Lab Data for a quick post-deployment check and monitor Field Data over time (according to developer.chrome.com). Search Console can help track the Core Web Vitals report at the website level once the website has been verified and data is available.
Common beginner mistakes
- Looking only at the Performance score: the overall score does not replace real-user data.
- Lazy-loading every image: the LCP image may load too late.
- Installing another plugin without measuring again: the plugin may reduce image size but add JavaScript or network requests.
- Removing code based on an audit warning without testing functionality: forms, payments or analytics may break.
- Changing many things at once: it becomes difficult to tell which change helped or caused an error.
- Equating speed with SEO: content, crawlability, usefulness and usability still need to be assessed separately.
If you are optimizing a content website, combine speed testing with the SEO and website optimization guide for beginners.
The minimum workflow
- Choose three to four representative URLs.
- Measure them with PageSpeed Insights and save the LCP, INP, CLS and TTFB values along with the warnings.
- Compare Field Data with Lab Data when both are available.
- Prioritize the most significant cause: images, the server, JavaScript, or render-blocking resources.
- Fix one group of issues, verify functionality, and measure again.
- Use DevTools when the high-level report does not provide enough detail.
- Monitor CrUX or Search Console after the changes have stabilized.
Once you have completed these steps, you will have a baseline, prioritized causes, controlled changes, and evidence to guide the next decision. You do not need to pursue a perfect score if real-world experience and website functionality have improved appropriately.
Reference source
- About PageSpeed Insights — Google for Developers.
- Lighthouse — Chrome for Developers.
- Web Vitals — web.dev.
- Performance panel: Analyze your website’s performance — Chrome DevTools.
- Third-party JavaScript performance — web.dev.
- Browser-level image lazy loading for the web — web.dev.
- Render-blocking CSS — web.dev.
- Overview of CrUX — Chrome for Developers.
