A slow website costs you twice: visitors leave before they see your offer, and search engines have less reason to show you. Google measures real-world page experience with three metrics called Core Web Vitals. This guide explains what they mean, how to measure them and which fixes usually make the biggest difference.
Key takeaways
- Core Web Vitals measure loading (LCP), responsiveness (INP) and visual stability (CLS).
- Google's "good" thresholds are LCP 2.5 s or less, INP 200 ms or less and CLS 0.1 or less, measured at the 75th percentile of real visits.
- Images, JavaScript and hosting are the most common causes of slow pages.
- Speed is part of user experience; it helps conversions as well as SEO.
What are the three metrics?
Largest Contentful Paint (LCP): loading
LCP is the time it takes for the largest visible element, usually a hero image or a main heading, to appear. A good LCP is 2.5 seconds or less. It is the metric most affected by image size, server speed and render-blocking resources.
Interaction to Next Paint (INP): responsiveness
INP measures how quickly the page responds when a user taps, clicks or types. A good INP is 200 milliseconds or less. Heavy JavaScript running on the main thread is the usual cause of poor scores.
Cumulative Layout Shift (CLS): stability
CLS measures unexpected movement of content while the page loads, such as a button jumping just as you tap it. A good CLS is 0.1 or less. It is mostly caused by images without dimensions, late-loading fonts, and ads or banners injected above content.
How to measure
- PageSpeed Insights shows both lab data (Lighthouse) and, when available, field data from real Chrome users.
- Google Search Console has a Core Web Vitals report that groups your URLs into good, needs improvement and poor.
- Lighthouse in Chrome DevTools helps you test changes locally. Test with mobile settings, because that is where most problems show up.
Field data from real visitors is what Google uses; lab tests are for finding and fixing problems.
The fixes that matter most
1. Optimize images
Images are usually the largest files on a page. Resize them to the size they are displayed, compress them, and use modern formats such as WebP or AVIF. Add explicit width and height attributes so the browser reserves space, lazy-load images below the fold, and never lazy-load the main hero image.
2. Ship less JavaScript
Every script has to be downloaded, parsed and executed. Remove libraries you do not need, split code so each page loads only what it uses, and defer third-party scripts such as chat widgets and analytics until after the page is usable. Static or server-rendered pages with minimal client-side code are the fastest approach for marketing sites, which is why we build our own pages that way.
3. Use good hosting and a CDN
A fast first byte makes every other metric easier. Host close to your visitors or behind a content delivery network, enable HTTP/2 or HTTP/3 and compression (Brotli or gzip), and cache static assets for a long time with versioned file names.
4. Handle fonts carefully
Use only the font weights you need, serve fonts from your own domain or preload them, and use font-display: swap so text is visible immediately. For Arabic and English sites, load the Arabic font only on Arabic pages.
5. Prevent layout shift
Give images, videos and embeds fixed dimensions or an aspect ratio, reserve space for banners and ads, and avoid inserting content above what the user is already reading.
6. Keep your database and plugins lean
On CMS sites, slow queries and too many plugins are frequent culprits. Remove unused plugins, cache pages, and keep software updated.
Diagnosing a slow page step by step
Do not guess; follow the evidence. Run PageSpeed Insights on the mobile tab and read the field data first. If LCP is poor, open the diagnostics and identify the LCP element: it is usually an image or a large heading. Check how large that file is, whether it is lazy-loaded by mistake, and whether anything blocks it, such as a heavy stylesheet or a script in the head. If INP is poor, record a Performance trace in Chrome DevTools while tapping the slow control and look for long tasks. If CLS is poor, enable layout shift highlighting and see which elements jump. Fix one cause at a time and re-test, so you know what worked.
Third-party scripts: the hidden cost
Chat widgets, tag managers, heat maps, social embeds and ad pixels each add network requests and main-thread work, and you do not control their code. Audit them regularly: remove anything nobody uses, load the rest after the page is interactive, and prefer lightweight alternatives. For videos, show a thumbnail and load the player only when the visitor clicks. For maps, use a static image until interaction. These small changes often improve INP and LCP more than any server upgrade.
Set a performance budget
A performance budget is a limit you agree not to exceed, for example a maximum size for images on a page or a maximum amount of JavaScript. When every new feature must fit inside the budget, speed stops being a one-off project and becomes a habit. Write the limits down, check them before each release and decline additions that break them unless something else is removed.
Why static and server-rendered pages are fast
When a page is prepared in advance and served from a CDN, the browser receives ready HTML immediately and needs little JavaScript to show it. Client-side rendering, by contrast, sends a nearly empty page and builds the content in the browser, which delays LCP and uses more CPU on phones. For marketing sites, blogs and service pages, pre-rendered HTML with small, targeted scripts for interaction is usually the best balance of speed, SEO and simplicity. Dynamic features such as dashboards and carts can still load their code only where needed.
Mobile testing tips for Jordan and the region
- Test on a mid-range Android phone, not only on a fast laptop, since many visitors use such devices.
- Throttle the network in DevTools to a slower mobile profile to see what a typical visitor experiences.
- Test the Arabic pages separately, because fonts and right-to-left layout can affect both loading and stability.
- Check pages after consent banners and chat widgets load, as these often cause shifts.
Speed and conversions
Speed is not only a ranking factor. A page that responds quickly feels more professional, reduces abandonment on mobile and makes forms and checkouts easier to complete. Treat performance as part of your product, and re-test after every significant change.
Quick wins you can finish in one day
- Convert your largest images to WebP and resize them to the dimensions they are displayed at.
- Add width and height to every image and video so the layout does not jump.
- Remove any plugin, script or font weight that nothing uses.
- Preload the main hero image and the primary font, and lazy-load everything below the fold.
- Turn on compression and long-term caching for static files at your host or CDN.
- Move chat widgets, analytics and similar scripts so they load after the page is usable.
- Re-test on mobile and write down the before and after numbers so you can see what each change achieved.
Real results vary by site, which is why recording numbers matters. If a change does not help, undo it and try the next one rather than stacking guesses.
A simple performance routine
- Test your key pages on mobile with PageSpeed Insights.
- Fix the largest issue first, usually images or JavaScript.
- Re-test, and repeat.
- Check the Search Console report monthly.
- Run a test after adding any new script, plugin or large image.
Frequently asked questions
Are Core Web Vitals a ranking factor?
Yes, page experience signals, including Core Web Vitals, are used by Google in ranking. They are one factor among many, and content relevance remains the most important, but a poor experience can hold a good page back.
What is a good PageSpeed score?
The score is a lab estimate; the real goal is passing the three Core Web Vitals thresholds for real users. A high score is a helpful indicator, not the target by itself.
Why is my site slow only on mobile?
Phones have less processing power and often slower connections, so large images and heavy JavaScript hurt much more. Always test with mobile settings.
Can I fix this myself?
Image compression and removing unused plugins are accessible to most site owners. Deeper issues in code and infrastructure usually need a developer.
How often should I test speed?
Test your key pages after every significant change and review the Search Console report at least monthly, since new scripts, plugins and images can quietly slow a site down.
Does a CDN make a site fast by itself?
A CDN helps with delivery time, but it cannot fix oversized images, heavy JavaScript or slow server code. Use it together with the other fixes in this guide.
Next step
Want to know how your site performs? Read about our web development and hosting and DevOps services, or ask for a speed review.
This article is no longer available. Back to blog
