To speed up a website, measure it with PageSpeed Insights and Search Console's Core Web Vitals report, then fix what matters most: compress images into WebP or AVIF, defer third-party scripts, enable caching and a CDN, and improve server response. Google's "good" thresholds are LCP within 2.5 seconds, INP up to 200 ms and CLS up to 0.1.
What are Core Web Vitals and what is a good score for each?
Core Web Vitals are three metrics Google uses to judge real visitor experience: how fast the main content appears (LCP), how quickly the page responds to taps, clicks and typing (INP), and how stable the layout is while loading (CLS). Each metric is assessed at the 75th percentile of page loads, separately for mobile and desktop, so at least three out of four visits need to hit the "good" threshold.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the largest visible element in the first screen renders, such as the hero image or main heading | 2.5 s or less | 2.5 s to 4 s | Over 4 s |
| INP (Interaction to Next Paint) | How quickly the page responds to interactions throughout the visit: clicks, taps and key presses | 200 ms or less | 200 ms to 500 ms | Over 500 ms |
| CLS (Cumulative Layout Shift) | How much page elements move unexpectedly while loading | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Thresholds source: the LCP, INP and CLS pages on web.dev.
A fourth metric matters even though it is not a Core Web Vital: Time to First Byte (TTFB). web.dev suggests 0.8 seconds or less for most sites, because a slow server delays everything that follows, especially LCP.
Why did INP replace FID?
On 12 March 2024, INP became a stable Core Web Vital, replacing FID. FID only measured the delay before the first interaction, so a site could look fine even if it froze later when a visitor opened a menu or added a product to the cart. INP observes every interaction during the visit and reports the longest one, ignoring outliers on interaction-heavy pages, so it exposes the heavy JavaScript problems FID used to hide.
Does site speed affect your Google ranking and your sales?
Yes, within clear limits. Google says Core Web Vitals are used by its ranking systems, but it still shows the most relevant result even when that page's experience is weaker. Speed helps you win when your content is on par with competitors; it does not make up for content that fails to answer the searcher's question.
The effect on sales is more direct. In the "Milliseconds Make Millions" study by Deloitte and Google, published in 2020 across 37 brands' sites, a 0.1-second improvement in mobile site speed was associated with an 8.4% increase in conversion rates for retail sites.
How do you measure your site speed correctly?
Separate two kinds of data before judging your site:
- Field data: measurements from real visitors on their own devices and networks. The Core Web Vitals report in Search Console uses CrUX data from the last 28 days, which reflects how Google actually assesses your pages.
- Lab data: a simulation on a fixed device and network, such as Lighthouse in Chrome or WebPageTest. It is useful for finding causes and testing a fix before release, but results vary from run to run.
PageSpeed Insights shows both. Test the pages that bring in money first: the homepage, service or product pages, and checkout. Test on mobile, since phones and mobile networks are usually slower than desktops. If your site has little traffic, field data may not be available yet, so rely on lab tests for now.
Which steps actually make a website faster?
1. Images: size, format and loading
- Convert JPG and PNG images to WebP or AVIF. According to Google, lossy WebP images are 25–34% smaller than comparable JPEG images.
- Serve each image at the size it is displayed using srcset, instead of uploading a multi-thousand-pixel photo for a small thumbnail.
- Use loading="lazy" only for images below the first screen. Never lazy-load the hero image that is your LCP element; load it early with rel="preload" or fetchpriority="high".
- Set width and height on every image and reserve space for every ad or banner so the page does not jump when they appear.
2. JavaScript and CSS
Snaabble provides a tailored technical assessment to define the right stack & exact budget.
- Minify files, remove unused code (tree shaking) and split code by page (code splitting).
- Defer third-party scripts such as Facebook Pixel, chat widgets and maps with defer or async, or load them after the first interaction.
- Inline the CSS needed for the first screen (critical CSS) and load the rest later.
- Break up long JavaScript tasks that block the main thread; they are the most common cause of poor INP.
3. Arabic web fonts
Arabic font files are relatively large because they contain each letter's initial, medial and final forms. Self-host the font, keep only the weights you use in WOFF2 format, and set font-display with a similarly sized fallback font so text is not delayed and does not jump when the web font finishes loading.
4. Caching
- In the browser: set a long Cache-Control lifetime for static files whose names change with each release, such as images, fonts, CSS and JS.
- On the server: cache repeated query results in Redis or Memcached, and cache pages that are the same for every visitor, such as articles and service pages.
5. CDN and compression
A CDN such as Cloudflare serves static files from servers close to the visitor and enables Brotli compression and HTTP/3. It helps most when your server is in Europe or the US while your visitors are in Egypt and the Gulf.
6. Server and database
Add indexes to frequently searched columns, remove N+1 queries that run dozens of queries to render a single list, and enable OPcache on a supported PHP version if your site runs on Laravel. If TTFB is still high after that, the hosting itself is usually the problem; see how to choose web hosting.
Sites with many returning visitors can also use a service worker to cache the interface on the device, which is the idea behind progressive web apps (PWA).
Which mistakes keep a site in the red?
| Metric | Common causes | Fix |
|---|---|---|
| LCP | A huge uncompressed hero image, a lazy-loaded hero image, a slow server, or render-blocking CSS | Compress and preload the image, improve TTFB, reduce render-blocking files |
| INP | Long JavaScript tasks, too many tracking and chat scripts, filters that rebuild the whole page on every click | Split code, defer scripts, and reduce the work done after each interaction |
| CLS | Images and ads without dimensions, a cookie bar or banner injected at the top, font swapping on load | Reserve space in advance, overlay late banners instead of pushing content down, tune the fallback font |
Where should you start with limited time and budget?
| Priority | Action | Metric it usually improves | Effort |
|---|---|---|---|
| 1 | Compress images, convert to WebP or AVIF, set dimensions | LCP and CLS | Low |
| 2 | Enable a CDN and Brotli compression | TTFB and LCP | Low |
| 3 | Defer third-party scripts and remove unnecessary ones | INP and LCP | Low to medium |
| 4 | Browser and server caching | TTFB | Medium |
| 5 | Split JavaScript, optimize queries or change hosting | INP and TTFB | Medium to high |
Measure again after each step. If your site is an online store, track the effect on sales as explained in e-commerce conversion rate optimization.
What else do site owners ask about speed?
Is compressing images enough to speed up a site?
No. Image compression is often the easiest fix, but slowness can also come from heavy tracking scripts, crowded shared hosting or unindexed database queries. Check TTFB and INP before assuming images are the cause.
Why does my PageSpeed Insights score change between tests?
The lab part of the report depends on server load at test time, ads and external scripts, and the test server's location. Compare the average of several runs and make final decisions based on field data in Search Console.
Do good Core Web Vitals secure top rankings?
No. Google's guidance states that good results in the Core Web Vitals report are no promise of top positions; helpful, relevant content comes first.
Does a slow site hurt paid ads?
Yes. Visitors who wait too long leave before seeing the offer, so the click is wasted, and in Google Ads landing page experience is one of the three Quality Score components.
Snaabble is a software company based in Talkha, Dakahlia, Egypt, working on website design and development. To discuss your current site's speed or a new build, message us on WhatsApp at +20 103 673 3131 or email hello@snaabble.com. Directions are on our location page.
