Let me settle this quickly: yes, page speed is a ranking factor. Google has confirmed it multiple times since 2010, and again in 2021 when Core Web Vitals became part of the page experience update. But the real question isn’t whether speed matters. It’s how much it matters, what specific metrics Google actually uses, and what you should do about it without wasting time chasing a perfect score.
I’ve audited hundreds of Singapore websites over the years. E-commerce sites hosted on shared servers in the US. Corporate sites bloated with uncompressed hero videos. F&B brands running WordPress themes with 47 plugins. In almost every case, page speed problems were quietly bleeding traffic and conversions, and the site owners had no idea.
This guide breaks down the technical reality of page speed as a ranking factor. You’ll learn exactly which metrics Google measures, how to diagnose your own site, and the specific fixes that deliver the biggest improvements. No fluff, no vague advice.
What Page Speed Actually Means (And What It Doesn’t)
Page speed is the time it takes for a specific web page to load and become usable. That sounds simple, but it’s actually a collection of different measurements, each capturing a different moment in the loading process.
Think of it like ordering kopi at a hawker centre. There’s the time you place your order (the browser sends a request). There’s the time the uncle acknowledges you (Time to First Byte). There’s the moment you see your cup being prepared (First Contentful Paint). And there’s the moment the kopi is in your hand and you can drink it (Largest Contentful Paint). Each of these moments matters, and they measure different things.
Page speed is not the same as site speed. Site speed is an average across your entire domain. Page speed is specific to individual URLs. Your homepage might load in 1.2 seconds while your product listing page takes 6.8 seconds because it’s loading 200 unoptimised images. Google evaluates pages individually, so you need to think about speed on a page-by-page basis.
Page speed is also not just about how fast your server responds. It includes everything: server response time, how the browser downloads and parses your HTML, CSS, and JavaScript, how images and fonts are loaded, and how the layout stabilises as elements appear on screen.
The Metrics That Define Page Speed
Google doesn’t look at a single “load time” number. It evaluates page speed through a set of specific metrics, primarily the Core Web Vitals. Here’s what each one measures in plain terms:
Largest Contentful Paint (LCP) tracks how long it takes for the biggest visible element on your page to render. This is usually your hero image, a large text block, or a video thumbnail. Google considers an LCP of 2.5 seconds or less as “good.” Between 2.5 and 4 seconds is “needs improvement.” Anything above 4 seconds is “poor.”
Interaction to Next Paint (INP) replaced First Input Delay in March 2026. While FID only measured the delay before the browser started processing your first interaction, INP measures the responsiveness of every interaction throughout the entire page visit. If a user clicks a button, taps a menu, or types in a form field, INP captures how long it takes for the page to visually respond. An INP of 200 milliseconds or less is considered good.
Cumulative Layout Shift (CLS) measures visual stability. Ever tried to tap a link on your phone, only for an ad to load and push the link down, causing you to tap the wrong thing? That’s layout shift. A CLS score of 0.1 or less is good. This metric doesn’t measure speed in the traditional sense, but it’s part of the page experience signal that Google uses alongside speed metrics.
How Google Uses Page Speed as a Ranking Factor
Google first announced page speed as a ranking factor for desktop searches in 2010 through the “Speed Update.” In 2018, they extended this to mobile searches. Then in June 2021, they rolled out the Page Experience Update, which incorporated Core Web Vitals as ranking signals.
So page speed is confirmed as a ranking factor. But here’s the nuance that most articles miss: it functions primarily as a demotion signal, not a promotion signal.
What does that mean practically? Having a fast site won’t catapult you from page 5 to page 1. But having a painfully slow site can push you down when you’re competing against pages with similar content quality and relevance. Google’s John Mueller has said this repeatedly. Content relevance and quality remain the dominant ranking factors. Speed is a tie-breaker.
The Tie-Breaker Effect
Imagine two Singapore law firms both have excellent, well-optimised pages targeting “commercial lease review Singapore.” Both have strong backlink profiles. Both have comprehensive, authoritative content. One page loads in 1.8 seconds with good Core Web Vitals. The other takes 5.2 seconds with a poor LCP score.
Google will likely favour the faster page. Not because speed is more important than content, but because all other signals are roughly equal, and speed tips the balance.
This is why page speed optimisation delivers the most noticeable ranking improvements for sites that already have solid content and technical SEO foundations. If your content is thin or your site has crawlability issues, fixing speed alone won’t save you. But if you’re neck-and-neck with competitors, speed can be the edge that moves you up.
The Indirect Ranking Effects Are Bigger Than the Direct Ones
Here’s where it gets interesting. The direct ranking impact of page speed is modest. Google has said so. But the indirect effects are substantial, and this is what most site owners underestimate.
A slow page increases your bounce rate. Google’s own research found that as page load time goes from 1 second to 3 seconds, the probability of bounce increases by 32%. From 1 to 5 seconds, it increases by 90%. When users bounce, they send a signal that your page didn’t satisfy their query. Over time, this erodes your rankings.
A slow page also reduces dwell time. If users who do stay are frustrated by sluggish interactions, they spend less time on your page and visit fewer pages per session. These engagement metrics influence how Google perceives the quality of your site.
Then there’s the crawl budget issue. If your pages take a long time to load, Googlebot can crawl fewer pages within its allocated time for your site. For a small 50-page site, this barely matters. But if you’re running a Singapore e-commerce store with 10,000 product pages, slow load times mean new products and updated pages get indexed days or weeks later than they should.
You Don’t Need a Perfect PageSpeed Insights Score
I see this mistake constantly. Business owners fixate on getting a 100/100 score on Google PageSpeed Insights and spend weeks chasing it. Let me be direct: a perfect score is not a ranking factor. The score itself is a diagnostic tool, not a signal that Google feeds into its ranking algorithm.
What Google actually uses are the Core Web Vitals metrics from real user data, collected through the Chrome User Experience Report (CrUX). This is field data from actual Chrome users visiting your site. It’s different from the lab data that PageSpeed Insights generates when it simulates a page load.
You can have a PageSpeed Insights score of 65 and still pass all Core Web Vitals with flying colours if your real users experience fast load times. Conversely, you can score 95 in the lab test but fail Core Web Vitals because your actual visitors are on slow 4G connections in areas with poor coverage.
What Score Range Should You Actually Target?
Focus on passing Core Web Vitals thresholds in the field data. That means:
- LCP under 2.5 seconds for at least 75% of page loads
- INP under 200 milliseconds for at least 75% of interactions
- CLS under 0.1 for at least 75% of page loads
For the PageSpeed Insights score itself, anything above 80 on mobile is solid. Above 90 is excellent. Chasing the last 5-10 points usually involves trade-offs that aren’t worth it, like removing analytics scripts or stripping out functionality your users need.
In Singapore, most users are on fast fibre connections at home and decent 4G/5G on mobile. This means your baseline conditions are better than many other markets. But don’t get complacent. Mobile users on MRT trains passing through tunnels experience intermittent connectivity, and that’s when a well-optimised page makes the difference between a completed visit and an abandoned one.
Tools for Measuring and Diagnosing Page Speed
You need the right tools to understand where your speed problems actually are. Here are the ones I use in every audit, and what each one is best for.
Google PageSpeed Insights
Start here. Enter any URL and you get both field data (from real Chrome users) and lab data (simulated). The field data section at the top is what matters for SEO. It shows your actual Core Web Vitals performance. The lab data below is useful for diagnosing specific issues.
Pay close attention to the “Opportunities” section. It lists specific actions like “Serve images in next-gen formats” or “Eliminate render-blocking resources,” along with estimated time savings for each. This is your prioritised to-do list.
Google Search Console Core Web Vitals Report
This gives you a site-wide view. It groups your URLs into “Good,” “Needs Improvement,” and “Poor” categories for both mobile and desktop. The real value here is spotting patterns. If all your blog posts are slow but your service pages are fast, you know the issue is likely related to how your blog template handles images or scripts.
GTmetrix
GTmetrix provides a waterfall chart that shows every single resource your page loads, in order, with timing for each. This is invaluable for identifying the specific files causing bottlenecks. You can see that your 2.3MB hero image takes 1.8 seconds to load, or that a third-party chat widget script blocks rendering for 900 milliseconds.
The free version tests from a limited number of locations. If you’re targeting Singapore users specifically, the paid version lets you test from a Singapore server, which gives you more accurate results.
WebPageTest
This is the most technical option. You can test from specific locations (including Singapore), on specific connection speeds, and on specific devices. It generates filmstrip views showing exactly what the user sees at each moment during loading. You can also run comparison tests to see how your site stacks up against a competitor’s.
For advanced users, WebPageTest lets you block specific domains during testing. This is useful for isolating the impact of third-party scripts. Block your analytics, chat widget, and ad scripts one by one to see how much each contributes to your total load time.
Chrome DevTools
Built right into your Chrome browser. Press F12, go to the Performance tab, and record a page load. You’ll see a detailed timeline of everything that happens during loading: network requests, JavaScript execution, layout calculations, and paint events. This is where you go when you need to understand exactly why your LCP is slow or why your INP is high.
Deconstructing the PageSpeed Insights Score: What Each Metric Weighs
The PageSpeed Insights performance score is calculated using a weighted combination of six metrics. Understanding the weights helps you prioritise your optimisation efforts. Here’s the current breakdown:
Largest Contentful Paint (LCP): 25% Weight
This carries the heaviest weight and is also a Core Web Vital. Your LCP element is typically the hero image, a background image, or the largest text block above the fold. To improve it, you need to ensure this element loads as quickly as possible.
Common LCP killers I see on Singapore sites: uncompressed PNG hero images (often 3-5MB), hero images served from a CDN node in the US instead of Singapore, and render-blocking CSS that delays the browser from painting the page.
Interaction to Next Paint (INP): 25% Weight
Previously this slot belonged to First Input Delay (FID), but Google replaced it with INP in March 2026. INP is a harder metric to pass because it measures all interactions, not just the first one. Heavy JavaScript is the usual culprit. If your page runs complex scripts on every click or scroll event, your INP will suffer.
E-commerce sites with lots of dynamic filtering, live search, and add-to-cart animations are particularly vulnerable here. Every interactive element needs to respond within 200 milliseconds.
Cumulative Layout Shift (CLS): 15% Weight
Layout shifts happen when elements change position after they’ve been rendered. The most common causes are images without defined width and height attributes, ads that load late and push content down, and web fonts that swap in and change text size.
A practical fix: always specify width and height attributes on your img tags. This lets the browser reserve the correct space before the image loads, preventing shift. For ads, use CSS to reserve a fixed-size container.
First Contentful Paint (FCP): 10% Weight
FCP measures when the first piece of content appears on screen. It’s the user’s first visual confirmation that something is loading. A slow FCP often points to server-side issues (slow TTFB) or render-blocking resources in the head of your HTML.
Speed Index (SI): 10% Weight
Speed Index captures how quickly the visible area of the page is populated with content. It’s calculated by analysing video frames of the page loading and measuring the visual progression. A page that renders progressively (showing content piece by piece) will score better than one that stays blank for 3 seconds and then shows everything at once.
Total Blocking Time (TBT): 15% Weight
TBT measures the total time between FCP and Time to Interactive where the main thread is blocked long enough to prevent input responsiveness. Any task longer than 50 milliseconds is considered a “long task,” and the time beyond 50ms is counted as blocking time. Heavy JavaScript frameworks and unoptimised third-party scripts are the primary causes of high TBT.
Note that Time to First Byte (TTFB) isn’t directly part of the score calculation, but it appears in the Diagnostics section and affects every other metric. If your server takes 2 seconds to respond, every metric starts 2 seconds late.
Practical Steps to Improve Your Page Speed
Here’s where we get into the work that actually moves the needle. I’ve organised these by typical impact, starting with the fixes that usually deliver the biggest improvements.
1. Optimise and Compress Your Images
This is almost always the single biggest win. On the average Singapore business website I audit, images account for 60-80% of total page weight. Here’s what to do:
Convert images to WebP or AVIF format. WebP typically delivers 25-35% smaller file sizes than JPEG at equivalent quality. AVIF is even better but has slightly less browser support. Most modern CMS platforms and CDNs can handle automatic conversion.
Implement responsive images using the srcset attribute. Serve a 400px-wide image to mobile users and a 1200px-wide image to desktop users. There’s no reason to send a 2400px-wide image to someone viewing your site on a phone screen.
Lazy load images below the fold. Add loading=”lazy” to any img tag that isn’t visible in the initial viewport. This tells the browser to only load these images when the user scrolls near them. But never lazy load your LCP image. That’s the one image you want to load as fast as possible.
Set explicit width and height on every image element. This prevents layout shift (improving CLS) and helps the browser allocate space during rendering.
2. Minimise and Defer JavaScript
JavaScript is the second most common speed killer. Every script your page loads needs to be downloaded, parsed, compiled, and executed. Here’s how to reduce its impact:
Audit your scripts ruthlessly. Open Chrome DevTools, go to the Coverage tab (Ctrl+Shift+P, type “coverage”), and reload your page. It shows you exactly how much of each JavaScript file is actually used on that page. I regularly find that 50-70% of loaded JavaScript is unused on any given page.
Add the “defer” attribute to non-critical scripts. This tells the browser to download the script in the background and only execute it after the HTML has been fully parsed. For scripts that aren’t needed until user interaction (like chat widgets), use dynamic import or load them on user interaction.
Remove unused plugins and third-party scripts. Every analytics tool, heatmap tracker, chat widget, and social media embed adds weight. Ask yourself: is this script generating enough value to justify the speed cost? For a Singapore SME site, I often find 3-4 redundant tracking scripts that nobody is actually checking.
3. Optimise Your Server Response Time
Your Time to First Byte (TTFB) sets the floor for all other metrics. If your server takes 1.5 seconds to respond, your LCP cannot possibly be under 1.5 seconds.
If you’re hosting on a shared server in the US or Europe, consider migrating to a server in Singapore or at least Asia-Pacific. The physical distance between your server and your users adds latency. For a Singapore-focused business, hosting in Singapore or using a CDN with a Singapore edge node can reduce TTFB by 200-500 milliseconds.
Implement server-side caching. If you’re on WordPress, a caching plugin like WP Rocket or W3 Total Cache can reduce TTFB dramatically by serving cached HTML instead of generating pages from the database on every request. I’ve seen TTFB drop from 1.8 seconds to 180 milliseconds just by enabling proper caching on a WordPress site.
If your site runs on a CMS with a database backend, optimise your database queries. Slow queries are a common cause of high TTFB, especially on WooCommerce sites with thousands of products.
4. Implement a Content Delivery Network (CDN)
A CDN caches copies of your static files (images, CSS, JavaScript) on servers around the world. When a user in Singapore requests your page, they get these files from a nearby server instead of your origin server.
Cloudflare offers a free tier that works well for most small to medium sites. For larger sites or those needing more control, Cloudflare Pro, BunnyCDN, or AWS CloudFront are good options. Make sure your CDN has a point of presence in Singapore. Most major CDNs do.
5. Optimise CSS Delivery
CSS is render-blocking by default. The browser won’t paint anything on screen until it has downloaded and parsed all your CSS files. Here’s how to handle this:
Inline your critical CSS. Identify the CSS needed to render the above-the-fold content and embed it directly in the HTML head. Load the rest of your CSS asynchronously. Tools like Critical (an npm package) can automate this extraction.
Remove unused CSS. Like JavaScript, most sites load far more CSS than any single page needs. The Coverage tab in Chrome DevTools shows unused CSS as well. PurgeCSS is a tool that can automatically strip unused styles from your CSS files.
Minify your CSS files. Remove whitespace, comments, and unnecessary characters. This typically reduces file size by 10-20%. Most build tools and caching plugins handle this automatically.
6. Preload Key Resources
Use the link rel=”preload” tag to tell the browser about critical resources it will need but hasn’t discovered yet. This is especially useful for fonts and your LCP image.
For example, if your LCP element is a hero image, add this to your HTML head:
<link rel="preload" as="image" href="/images/hero.webp">
For web fonts, preload the font file and use font-display: swap in your @font-face declaration. This ensures text is visible immediately using a system font, then swaps to your custom font once it loads. This prevents the invisible text flash that hurts both FCP and user experience.
7. Enable Text Compression
Enable Gzip or Brotli compression on your server. Brotli typically achieves 15-20% better compression than Gzip for text-based files. Most modern servers and CDNs support Brotli. This compresses your HTML, CSS, and JavaScript files during transfer, reducing download times significantly.
Check if compression is enabled by looking at the response headers in Chrome DevTools (Network tab). Look for “content-encoding: br” (Brotli) or “content-encoding: gzip”.
How Page Speed Affects Your Conversion Rate
Rankings aside, page speed has a direct and measurable impact on your bottom line. This is where the business case becomes impossible to ignore.
Portent’s research found that a site that loads in 1 second has a conversion rate 3x higher than a site that loads in 5 seconds. Deloitte found that a 0.1-second improvement in mobile site speed increased conversion rates by 8.4% for retail sites and 10.1% for travel sites.
For Singapore e-commerce businesses, this translates directly to revenue. If your online store generates $50,000 per month and your pages load in 4.5 seconds, improving load time to 2.5 seconds could realistically increase conversions by 15-25%. That’s $7,500 to $12,500 in additional monthly revenue from the same traffic.
Speed and Mobile Users in Singapore
Singapore has one of the highest smartphone penetration rates in the world, at over 97%. Google’s data shows that 53% of mobile users abandon a site that takes longer than 3 seconds to load. In a market where mobile traffic often accounts for 65-75% of total visits, slow mobile performance means you’re losing the majority of your potential customers before they even see your content.
Mobile optimisation isn’t optional here. It’s where most of your traffic lives. And mobile devices, despite Singapore’s excellent network infrastructure, still have less processing power than desktops. Heavy JavaScript that runs fine on a MacBook Pro can cripple performance on a mid-range Android phone.
The Trust Factor
Speed also affects perceived credibility. A study by Skilled.co found that 79% of online shoppers who experience a slow website say they won’t return. In Singapore’s competitive market, where consumers have dozens of alternatives a click away, a slow site tells visitors that you don’t care about their experience. That’s a trust signal, and it’s hard to recover from.
Think about it from your own experience. When you visit a site that loads instantly and responds crisply to every tap, it feels professional and reliable. When a site stutters, shifts around, and makes you wait, it feels amateurish. Your customers feel the same way about your site.
Page Speed Optimisation Priorities: Where to Start
If you’re feeling overwhelmed by all these metrics and fixes, here’s a simple prioritisation framework I use with clients:
Step 1: Run PageSpeed Insights on your top 10 pages by traffic. Check both mobile and desktop. Note which Core Web Vitals are failing and which “Opportunities” have the highest estimated time savings.
Step 2: Fix images first. This is almost always the highest-impact, lowest-effort change. Convert to WebP, compress, resize, and lazy load. On a typical site, this alone can improve your PageSpeed Insights score by 15-30 points.
Step 3: Address render-blocking resources. Defer non-critical JavaScript, inline critical CSS, and preload your LCP element. This usually takes more technical skill but delivers significant improvements to LCP and FCP.
Step 4: Optimise your server and hosting. If your TTFB is above 600 milliseconds, investigate your hosting setup. Consider upgrading your plan, switching to a Singapore-based server, or implementing caching.
Step 5: Audit third-party scripts. Remove anything unnecessary. Defer or lazy-load the rest. This improves TBT and INP.
Step 6: Monitor continuously. Page speed isn’t a one-time fix. Every new plugin, every content update, every new third-party integration can introduce regressions. Set up regular monitoring through Google Search Console and run PageSpeed Insights checks monthly.
Common Page Speed Myths in Singapore
Let me address a few misconceptions I encounter regularly when working with Singapore businesses.
“Singapore has fast internet, so page speed doesn’t matter here.”
Singapore does have excellent broadband infrastructure. But speed still matters for three reasons. First, Google’s ranking algorithm is global, not region-specific. Your Core Web Vitals are evaluated the same way regardless of where your users are. Second, mobile users on the go experience variable connection quality. Third, fast internet doesn’t compensate for heavy, poorly optimised pages. A 10MB page is still slow even on a 1Gbps connection because the browser still needs to parse and render all that content.
“I got a score of 95, so my speed is fine.”
The lab score and real-world performance are different things. Check your field data in PageSpeed Insights and your Core Web Vitals report in Search Console. If your field data shows “poor” LCP despite a high lab score, you have a problem that needs fixing. The lab test runs under ideal conditions. Your actual users don’t browse under ideal conditions.
“Page speed is only important for e-commerce.”
Every type of website benefits from speed. Service businesses need fast pages to capture leads before visitors bounce. Content sites need speed to keep readers engaged. Even B2B sites with long sales cycles benefit because first impressions matter, and a slow site creates a negative first impression that colours the entire relationship.
The Relationship Between Page Speed and Other SEO Factors
Page speed doesn’t exist in isolation. It interacts with and amplifies other SEO factors in ways that are worth understanding.
Speed and mobile-first indexing. Google predominantly uses the mobile version of your site for indexing and ranking. If your mobile pages are slow, that’s the version Google is evaluating. A desktop-fast, mobile-slow site is effectively a slow site in Google’s eyes.
Speed and crawl efficiency. Googlebot has a limited crawl budget for your site. Faster pages mean more pages crawled per session. For large sites, this directly affects how quickly new content gets indexed. I worked with a Singapore property portal that had over 15,000 listing pages. After reducing average page load time from 4.2 seconds to 1.8 seconds, their indexing rate for new listings improved by roughly 40%, going from an average of 3 days to same-day indexing for most new pages.
Speed and content freshness. If your pages load slowly and Googlebot can’t crawl them efficiently, your content updates take longer to reflect in search results. For businesses in fast-moving industries like fintech or property, this delay can mean losing rankings to competitors who publish and get indexed faster.
A Real-World Example: What Speed Optimisation Looks Like
Let me walk you through a simplified version of a speed optimisation project I handled for a Singapore professional services firm. Their main service pages were loading in 5.8 seconds on mobile with a PageSpeed Insights score of 34.
The diagnosis revealed several issues. Their hero image was a 4.2MB PNG file. They had 14 JavaScript files loading in the head, all render-blocking. Their WordPress theme loaded three separate font families with multiple weights. They were hosted on a shared server in the US. And they had 6 third-party scripts including two analytics platforms, a chat widget, a heatmap tool, and two social media embeds.
Here’s what we did, in order:
Converted all images to WebP and compressed them. The hero image went from 4.2MB to 87KB. Total image weight across the page dropped from 8.1MB to 340KB. This alone brought load time down to 3.4 seconds.
Moved all non-critical JavaScript to defer loading. Inlined critical CSS. Preloaded the hero image and primary font. Load time dropped to 2.1 seconds.
Migrated hosting to a Singapore-based VPS with server-side caching enabled. TTFB went from 1.4 seconds to 190 milliseconds. Load time dropped to 1.4 seconds.
Removed the duplicate analytics platform and the heatmap tool (which nobody had checked in 8 months). Lazy-loaded the chat widget to only initialise on scroll. Final load time: 1.2 seconds. PageSpeed Insights score: 91 on mobile.
Over the following 3 months, their organic traffic increased by 23%, bounce rate decreased from 61% to 38%, and average session duration increased by 34 seconds. Their lead form submissions went up by 18%. Not all of this was due to speed alone, as we made other SEO improvements simultaneously. But the speed gains were a significant contributor, particularly to the bounce rate and engagement improvements.
What to Do Next
Page speed is a confirmed ranking factor, but its real power lies in the cascade of improvements it triggers: lower bounce rates, better engagement, faster indexing, and higher conversions. You don’t need a perfect score. You need your Core Web Vitals in the green zone and a page that loads fast enough that your visitors never think about speed at all.
Start with PageSpeed Insights on your most important pages. Look at the field data first. If your Core Web Vitals are in the “good” range, you’re in solid shape. Focus your energy elsewhere. If they’re not, the fixes outlined above will get you there.
If you’d rather have someone handle the technical diagnosis and implementation, that’s what we do at Best SEO. We run detailed speed audits that go beyond what automated tools show, identifying the specific bottlenecks on your site and fixing them methodically. Drop us a message and we’ll take a look at your site. No obligation, just an honest assessment of where you stand and what would make the biggest difference.