Page Speed: What It Is, How to Measure It and How to Make Your Site Faster

Your visitors decide whether to stay in the first few seconds, and a slow page spends those seconds testing their patience. Every extra moment of loading pushes more of them towards the back button, and search engines notice the same sluggishness. The good news is that page speed is measurable, and most of what slows a site down is fixable. This guide explains what page speed is, how to measure it properly, and the practical steps that make your pages load faster.

What is Page Speed?

Page speed is how quickly the content on a single web page loads and becomes usable, measured from the moment someone requests the page to the point where they can see and interact with it. It is an umbrella term rather than one number, because a page loads in stages and each stage has its own metric.

People often confuse page speed with site speed. Page speed describes one specific page. Site speed describes the typical experience across a sample of pages on your whole site. The distinction matters when you start measuring, because a fast homepage can sit alongside a painfully slow product page.

Page Speed vs Site Speed vs Core Web Vitals

These three terms get used interchangeably, but they mean different things. Getting them straight makes every report you read afterwards easier to follow.

Core Web Vitals are a subset, not a synonym. They are Google’s chosen way of scoring the parts of page speed that affect real people, and we will cover them in detail below. Page speed is the broad concept; Core Web Vitals are the specific yardstick Google applies to it.

Why Page Speed Matters for SEO and Conversions

Slow pages cost you twice. They frustrate the people who reach your site, and they weaken how that site performs in search. Here is how the damage adds up.

Page Speed as a Google Ranking Signal

Google confirms in its page experience documentation that Core Web Vitals are used by its ranking systems. So speed genuinely factors into where your pages appear, on both desktop and mobile.

But it helps to keep the weight in perspective. Google also says that chasing a perfect score purely for search reasons may not be the best use of your time, because content relevance still does most of the ranking work. Treat page speed as one lever among several, not the only one. If you want that technical work handled properly, our technical SEO services cover exactly this.

Crawl Budget and Indexing

Speed also affects how much of your site Google bothers to crawl. When pages respond slowly, Googlebot fetches fewer of them in the time it allocates to your site. Google explains that if a site slows down or returns server errors, Googlebot crawls less. For a large site, that can mean new or updated pages take longer to appear in search.

So a slow server has a second cost beyond annoying visitors. It can quietly limit how quickly your fresh content gets discovered and indexed.

Bounce Rate, User Experience and Conversions

The people who reach your site feel every delay. Slow pages tend to see higher bounce rates and fewer completed actions, whether that action is a purchase, a form or a call.

The pattern is consistent: as load time climbs, more visitors leave before the page even finishes. If your page takes several seconds to become usable, a large share of that traffic is gone before it sees your offer. Speeding the page up keeps more of the visitors you already worked hard to attract.

The Page Speed Metrics That Matter in 2026

Because page speed is measured in stages, you need to know which numbers to watch. A handful of metrics do most of the work, and Google groups the most important ones into Core Web Vitals.

Core Web Vitals: LCP, INP and CLS

Core Web Vitals are the three metrics Google uses to judge real-world page experience. Each is measured at the 75th percentile of real visits, meaning at least 75 percent of visits must hit the target for a page to pass.

• Largest Contentful Paint (LCP)measures loading. It marks when the largest visible element finishes rendering. A good LCP is 2.5 seconds or less.
• Interaction to Next Paint (INP)measures responsiveness, tracking how quickly the page reacts across a whole visit. A good INP is 200 milliseconds or less.
• Cumulative Layout Shift (CLS)measures visual stability, or how much the layout jumps around while loading. A good CLS is 0.1 or less.

One change worth noting: INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. If you are reading older guides that still list FID, they are out of date.

Supporting Metrics: TTFB, FCP, TBT, Speed Index and TTI 

Beyond the three headline metrics, several diagnostic numbers help you find where the delay sits. They are not Core Web Vitals, but they explain why your scores look the way they do.

• Time to First Byte (TTFB)is how long the server takes to send the first byte of the page. A good TTFB is 0.8 seconds or less.
• First Contentful Paint (FCP)is when the first content appears on screen. A good FCP is 1.8 seconds or less.
• Total Blocking Time (TBT)measures how long the main thread is blocked, which stops the page responding to input.
• Speed Indexmeasures how quickly content visibly fills the screen during load.
• Time to Interactive (TTI)marks when the page becomes fully interactive.

TTFB is the one to fix first if it is slow, because it feeds directly into FCP and LCP. A slow server delays everything that follows.

What Counts as a Good Page Speed Score

When you run a test, you usually get a performance score out of 100 alongside the individual metrics. The score is a useful summary, but the metrics tell you what to fix. Google groups the Lighthouse performance score into three bands.

One important distinction: your field data and your lab score are different things. Field data reflects what real visitors actually experienced. The lab score comes from a single simulated test. When the two disagree, the field data is the one Google uses for ranking, so treat it as the source of truth.

How to Measure Your Page Speed

You cannot fix what you have not measured. A few free tools give you both the real-world numbers and the diagnostic detail you need to act.

Google PageSpeed Insights

PageSpeed Insights is the tool most people start with, and it is free. Go to pagespeed.web.dev, enter your page URL and click Analyze. Within a minute you get a report combining real-user field data with a lab test.

Use the mobile and desktop toggle at the top to check both, and pay closer attention to mobile. Google indexes the mobile version of your site first, and mobile is usually where the slow scores hide.

Lighthouse and Chrome DevTools

Lighthouse is the engine behind PageSpeed Insights, and you can run it yourself inside Chrome. Open DevTools, find the Lighthouse tab, and analyse the page in a private window so extensions do not skew the result.

The advantage of running it locally is the depth of diagnostic data. You can view a request waterfall to see exactly which files load when, and spot the ones holding everything up.

Field Data vs Lab Data (CrUX)

Your report shows two kinds of data, and the difference matters. Field data comes from the Chrome User Experience Report, which reflects what real Chrome users experienced over the previous 28 days. Lab data comes from a single test run on demand in a controlled environment.

The two often disagree, usually because the lab test uses a deliberately throttled connection. When you need to know whether your site is fast enough for real people, trust the field data. When you need to diagnose a specific problem, the lab test gives you the detail.

Test Your Page Speed Now

Before reading on, it is worth running your own site through PageSpeed Insights so the fixes below have context. Enter your most important page, note your LCP, INP and CLS, and keep the report open as a checklist while you work through the next section.

How to Improve Your Page Speed

Most slow pages share the same handful of causes. Work through these in roughly this order, because the early ones tend to deliver the biggest gains for the least effort.

Optimise and Compress Images

Images are usually the heaviest thing on a page, so they are the first place to look. Make sure each image is no larger than it needs to be, compress it before uploading, and serve appropriately sized versions for different screens.

Lazy-loading also helps. It tells the browser to hold off loading images below the fold until the visitor scrolls towards them, so the initial view loads faster.

Choose the Right Image Format

Format matters as much as size. Modern formats like WebP and AVIF can produce much smaller files than JPEG or PNG at the same quality, so switching format alone can cut significant weight.

As a rough guide, use WebP or AVIF where you can, JPEG for photographs where you cannot, and PNG for graphics that need sharp edges or transparency. For animated GIFs, converting them to video is far lighter.

Minify HTML, CSS and JavaScript

Minifying means stripping out the characters a browser does not need, such as spaces, line breaks and comments. The code still works exactly the same, but the files are smaller and download faster.

Most content management systems have a plugin or setting that does this for you, so you rarely need to touch the code by hand.

Enable Compression with Gzip or Brotli

Compression shrinks your text files on the server before they travel to the browser, which then unpacks them. Gzip and Brotli are the two common methods, and Brotli usually compresses a little more tightly.

Most modern hosts support both, and enabling compression is often a single setting or a small addition to your server configuration.

Reduce and Combine HTTP Requests

Every file your page needs, whether a script, a stylesheet or an image, triggers a separate request to the server. The more requests, the longer the page takes to assemble.

You can cut the number down by combining files where sensible, removing anything unused, and avoiding plugins that load resources you do not need.

Leverage Browser and Server Caching

Caching stores a copy of your files so they do not have to be fetched fresh every time. Browser caching keeps static files like images and stylesheets on the visitor’s device, so return visits load faster.

Server caching stores a ready-made version of the page so your server does not rebuild it from scratch on every request. Both reduce work and speed things up.

Use a Content Delivery Network

A content delivery network, or CDN, stores copies of your site on servers around the world. When someone visits, they are served from the location nearest to them, which shortens the distance the data has to travel.

This matters a great deal for speed, and we will come back to why it is especially relevant for Singapore sites below.

Reduce Redirects and Redirect Chains

Each redirect adds another round trip between browser and server before the visitor reaches the page they wanted. A redirect chain, where one redirect leads to another, multiplies that delay.

Audit your redirects and point old URLs straight to their final destination, removing any unnecessary hops in between.

Remove Render-Blocking JavaScript and CSS

Some scripts and stylesheets stop the browser from displaying anything until they have loaded. These are called render-blocking resources, and they delay the moment your visitor sees content.

You can defer non-essential JavaScript so it loads after the main content, and prioritise the CSS needed for what appears first. This lets the page start rendering sooner.

Improve Server Response Time

A slow server delays everything, which is why TTFB is worth fixing early. Response time depends on your hosting quality, how efficiently your site runs, and how much traffic you handle.

If your host is the bottleneck, upgrading from shared hosting to something with dedicated resources often helps. Cleaning up slow database queries and heavy code helps too.

Load Asynchronously and Lazy-Load

Loading resources asynchronously lets the browser fetch them in the background while it carries on rendering the visible page, rather than waiting for each one in turn.

Combined with lazy-loading for offscreen images and content, this keeps the initial load light and brings in the rest as needed.

Improving Page Speed on Your Content Management System

How you apply these fixes depends on the platform your site runs on. Here is where to start on the most common ones.

WordPress

WordPress gives you the most control, mostly through plugins. A caching plugin does much of the heavy lifting, and a technical SEO plugin handles the settings around it.

Caching Plugins

A caching plugin such as WP Rocket or W3 Total Cache handles browser caching, file minification and other speed settings from one place. For many WordPress sites, installing and configuring one of these is the single biggest quick win.

Technical Settings with RankMath or Yoast

Plugins like RankMath or Yoast focus on the SEO side, but their technical settings interact with speed too. Keep them lean, avoid overlapping plugins that do the same job, and remove anything you are not using.

Shopify

Shopify manages hosting and much of the infrastructure for you, so your focus falls on your theme and apps. Choose a lightweight theme, and audit your installed apps regularly, because each one can add scripts that slow the store down.

Image optimisation still matters on Shopify, so compress product images before uploading and let the platform serve responsive sizes.

Wix

Wix handles most technical optimisation automatically and gives you less manual control, which suits many small business owners. Your main levers are keeping images compressed, limiting heavy third-party apps, and not overloading pages with animations.

Squarespace

Squarespace, like Wix, takes care of much of the underlying performance. Your influence is mainly in the content: use appropriately sized images, keep custom code to a minimum, and avoid embedding too many external widgets.

Webflow

Webflow produces relatively clean code and includes a CDN by default. To keep it fast, compress your assets, be careful with heavy animations and interactions, and remove unused custom code before publishing.

Magento

Magento powers large stores and needs more hands-on tuning. Enabling its full-page cache, using a server-side cache like Varnish, and bundling or minifying JavaScript and CSS all help. Because Magento sites tend to be large and complex, server resources matter a great deal.

Page Speed for Singapore Websites

Where your server sits relative to your visitors has a direct effect on speed, and this is where Singapore sites have a specific decision to make. If your audience is mainly in Singapore but your hosting sits overseas, every request travels further than it needs to, adding latency before your page even starts to load.

Hosting close to your audience, or using a content delivery network with edge locations in Singapore or the wider Asia-Pacific region, cuts that distance. For a local business serving local customers, this is one of the easier wins available.

Mobile deserves particular attention here. Singapore has very high mobile usage, so a large share of your visitors will arrive on a phone, often on a mobile network rather than wifi. If your pages are only fast on desktop, you are underserving most of your audience.

If your customers sit overseas while your business is based here, the same logic runs in reverse: a CDN helps you serve them quickly from servers near them, rather than forcing every request back to Singapore.

How Page Speed Affects AI Search

Search is no longer only ten blue links. AI Overviews and AI assistants increasingly answer questions directly, and the pages they draw from tend to be ones that are fast, well structured and easy to crawl.

A slow, unstable page is harder for these systems to process and less likely to be chosen as a source. The same work that improves your Core Web Vitals, clean structure, quick loading and crawlable content, also makes your pages better candidates for AI citation. If you want to position your site for this shift, our AI SEO work focuses on exactly that.

DIY versus Hiring a Page Speed Specialist

Plenty of page speed work is genuinely do-it-yourself. Compressing images, switching formats, installing a caching plugin and enabling compression are all within reach of most site owners, and they often deliver a noticeable improvement on their own.

Other problems run deeper. Render-blocking scripts, server-level bottlenecks, complex JavaScript and ongoing monitoring tend to need someone who works with this daily. If you have worked through the basics and your scores are still poor, that is usually the point to bring in help.

If you would rather hand the whole thing over, our SEO agency Singapore cover page speed as part of technical SEO. Either way, the goal is the same: a site that loads quickly for the people you want to reach.

A faster site does more than lift a score in a report. It keeps more of your visitors, converts more of them, and gives your content a better chance in both traditional and AI search. Run your key pages through a speed test, fix the issues that show up, and check back after a few weeks to see the difference. If you found this guide useful, share it with someone whose site could use a speed boost.