If your website loads slowly on a phone, Google already knows. And it’s costing you rankings. Here are 6 ways to make websites faster with mobile-first indexing, based on what we’ve seen work across dozens of Singapore business sites over the past three years.
Mobile-first indexing means Google’s crawler visits the mobile version of your site first. That mobile version determines how you rank on both mobile and desktop results. There’s no separate index. One index, one crawl, and it starts with your phone experience.
For Singapore businesses, this matters more than most. We have one of the highest smartphone penetration rates in the world. Your customers are searching from MRT platforms, hawker centres, and HDB living rooms. If your mobile site is sluggish or stripped down, you’re invisible to Google and frustrating to the people you want to reach.
Let me walk you through exactly what mobile-first indexing involves, the six technical practices that actually move the needle on speed, and the mistakes I see Singapore businesses make repeatedly.
How Mobile-First Indexing Actually Works (The Technical Version)
Most explanations of mobile-first indexing stop at “Google uses your mobile site.” That’s true but incomplete. Let me break down the mechanics so you understand what’s happening under the hood.
What Googlebot Smartphone Does Differently
Google operates two primary crawlers: Googlebot Desktop and Googlebot Smartphone. Since mobile-first indexing became the default, the smartphone crawler is the one that matters. It renders your page using a mobile viewport (roughly 412×823 CSS pixels), executes your JavaScript, and evaluates the resulting DOM.
This is critical. If your site relies on JavaScript to load content and that JavaScript behaves differently on mobile viewports, Googlebot Smartphone may see a completely different page than Googlebot Desktop. I’ve audited Singapore e-commerce sites where entire product description sections were hidden behind JavaScript toggles that never fired on mobile. Google literally couldn’t see the content.
You can verify exactly what Googlebot sees by using the URL Inspection tool in Google Search Console. Click “Test Live URL,” then view the rendered HTML. Compare this against your desktop render. Any discrepancies are problems.
One Index, Not Two
There is no separate mobile index. Google maintains a single unified index. The term “mobile-first” describes the crawling and evaluation method, not the storage. Content discovered by Googlebot Smartphone goes into the same index that serves desktop search results.
This means if your mobile version is missing content, that content effectively doesn’t exist for Google. It won’t rank on desktop either. I’ve seen businesses lose rankings for high-value keywords simply because their mobile template suppressed content blocks using display:none with no plan to make them accessible.
The Crawl Budget Connection
Crawl budget becomes more constrained on mobile-first indexing. If your mobile site is slow, Googlebot will crawl fewer pages per session. For a 50-page brochure site, this may not matter much. For an e-commerce site with 5,000 product pages or a property listing site with thousands of entries, slow mobile performance directly reduces how much of your site Google indexes.
We measured this on a Singapore property portal. After reducing mobile page load time from 6.2 seconds to 2.1 seconds, the number of pages crawled per day by Googlebot Smartphone increased by 73%. More pages crawled meant more pages indexed, which meant more long-tail keywords ranking.
6 Ways to Make Your Website Faster Under Mobile-First Indexing
Speed is not a single metric. It’s the result of dozens of technical decisions interacting with each other. Here are six specific, actionable practices that produce measurable improvements.
1. Implement Responsive Design with Performance Budgets
Responsive web design is the foundation. Google recommends it explicitly. One URL, one codebase, layout adapts to screen size. If you’re still running a separate m.example.com subdomain, migrating to responsive should be your top priority.
But responsive alone isn’t enough. You need performance budgets. A performance budget sets hard limits on page weight and load metrics. For example:
- Total page weight on mobile: under 1.5MB
- Largest Contentful Paint (LCP): under 2.5 seconds on a 4G connection
- Total JavaScript payload: under 300KB compressed
- Maximum number of HTTP requests: 50
Set these as build-time checks. If a developer adds a 400KB carousel library, the build fails. This prevents the slow creep of bloat that kills mobile performance over months.
For Singapore sites specifically, test on a simulated 4G connection, not WiFi. Many of your users are on mobile data in underground MRT stations or older HDB blocks with spotty coverage. Chrome DevTools lets you throttle to “Fast 3G” or “Slow 4G” to simulate realistic conditions.
2. Serve Modern Image Formats with Proper Sizing
Images are typically the single largest contributor to page weight. On the Singapore sites I audit, images account for 60-80% of total mobile page size. Fixing images alone often cuts load time in half.
Here’s the technical checklist:
Use WebP or AVIF format. WebP delivers 25-35% smaller file sizes than JPEG at equivalent quality. AVIF is even better, roughly 50% smaller, but browser support is still catching up. Use the <picture> element with fallbacks:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Descriptive alt text" width="800" height="600" loading="lazy">
</picture>Use the srcset attribute to serve different image sizes based on viewport width. A 1200px-wide hero image is wasted bandwidth on a 375px-wide phone screen. Generate multiple sizes (375w, 750w, 1200w) and let the browser choose.
Always specify width and height attributes on your <img> tags. This allows the browser to reserve the correct space before the image loads, preventing Cumulative Layout Shift (CLS). CLS is a Core Web Vital metric, and images without dimensions are the number one cause of poor CLS scores.
Add loading="lazy" to every image below the fold. For your above-the-fold hero image, do the opposite: add fetchpriority="high" to tell the browser to prioritise it.
3. Eliminate Render-Blocking Resources
When a browser loads your page, it encounters CSS and JavaScript files that can block rendering. The browser stops drawing the page until these files are downloaded and processed. On mobile connections, each blocking resource can add 200-500ms of delay.
Here’s how to fix this:
Inline your critical CSS. Extract the CSS needed to render the above-the-fold content and place it directly in a <style> tag in the <head>. Load the rest of your CSS asynchronously using the rel="preload" pattern:
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">For JavaScript, use defer or async attributes on all script tags that aren’t essential for initial render. Better yet, audit your JavaScript dependencies. I regularly find Singapore business sites loading 8-12 third-party scripts: analytics, chat widgets, heatmaps, social media pixels, review platforms. Each one adds weight and execution time.
One client’s F&B website was loading a 180KB chat widget JavaScript file on every page. The chat was used by roughly 2% of visitors. We deferred loading the chat script until user interaction (scroll or click), and LCP improved by 1.3 seconds.
4. Ensure Full Content Parity Between Mobile and Desktop
Content parity means your mobile version contains the same text, images, videos, structured data, and internal links as your desktop version. This isn’t about speed in the traditional sense, but it directly affects how efficiently Googlebot can index your site.
Common parity failures I find on Singapore sites:
- Accordion/tab content that is present in the HTML but hidden via CSS on mobile. Google has stated it will index this content, but it may give it reduced weight compared to visible content.
- Desktop pages with 2,000 words of content, mobile versions with 800 words because someone decided mobile users “don’t read.”
- Structured data (Schema markup) only implemented on the desktop template, not the mobile template.
- Internal links in desktop sidebar widgets that disappear entirely on mobile, breaking your internal link equity flow.
Audit content parity systematically. Use Screaming Frog to crawl your site with both a desktop and mobile user agent. Compare word counts, heading structures, and canonical tags across both crawls. Any page where the mobile word count is more than 10% lower than desktop needs investigation.
For structured data specifically, test your mobile URLs using Google’s Rich Results Test tool. Make sure the tool is set to “Mobile” (it is by default). If your structured data doesn’t appear in the mobile test, Google won’t use it for rich results.
5. Optimise Server Response Time and Use a CDN
Before the browser can even start rendering your page, it needs to receive the first byte of data from your server. This is measured as Time to First Byte (TTFB). Google recommends TTFB under 800ms, but for competitive Singapore keywords, aim for under 200ms.
If your website is hosted on a shared hosting plan in the US or Europe, your Singapore visitors are waiting for data to travel across the Pacific Ocean and back. That’s 150-300ms of latency before anything else happens.
Host locally or use a CDN with Singapore edge nodes. Cloudflare, AWS CloudFront, and Bunny CDN all have Points of Presence (PoPs) in Singapore. A CDN caches your static assets (images, CSS, JavaScript) on servers physically close to your visitors, dramatically reducing latency.
On the server side, implement proper caching headers. Static assets should have Cache-Control: max-age=31536000 (one year) with cache-busting filenames. HTML pages should use shorter cache durations or stale-while-revalidate patterns.
If you’re on WordPress (and many Singapore SME sites are), install a caching plugin like WP Rocket or W3 Total Cache. Enable page caching, browser caching, and GZIP or Brotli compression. Brotli compression typically achieves 15-20% better compression ratios than GZIP for text-based resources.
We moved a Singapore legal firm’s site from a US-based shared host to a Singapore-based VPS with Cloudflare in front. TTFB dropped from 1,400ms to 180ms. Their mobile PageSpeed score went from 34 to 78 without changing a single line of front-end code.
6. Fix Mobile Usability Issues That Slow Users Down
Speed isn’t only about milliseconds. Perceived speed matters too. If a user can’t tap the right button, has to pinch-zoom to read text, or gets blocked by an interstitial popup, the experience feels slow even if the technical load time is fine.
Google measures this through mobile usability signals and Core Web Vitals, particularly Interaction to Next Paint (INP), which replaced First Input Delay in March 2026.
INP measures the responsiveness of your entire page throughout its lifecycle. Every tap, click, and keyboard input is measured. If your JavaScript is blocking the main thread when a user taps a button, that delay gets recorded. Aim for INP under 200ms.
Practical fixes:
- Set font size to at least 16px for body text. This prevents iOS Safari from auto-zooming on input fields, which causes jarring layout shifts.
- Make tap targets at least 48×48 CSS pixels with at least 8px of spacing between them. Google’s Lighthouse audit flags this specifically.
- Avoid intrusive interstitials. Google penalises mobile pages that show full-screen popups immediately on load. If you need a popup (for email signups, cookie consent under PDPA requirements), trigger it after user engagement, not on page load.
- Break up long-running JavaScript tasks. If a single JS function takes more than 50ms to execute, it blocks the main thread and degrades INP. Use
requestIdleCallbackorsetTimeoutto chunk heavy operations.
Check your Core Web Vitals data in Google Search Console under “Experience > Core Web Vitals.” The report shows you exactly which URLs have poor mobile performance and which specific metric is failing.
How to Verify Your Mobile-First Indexing Status
Before you optimise anything, confirm where you stand. Open Google Search Console and go to Settings. Under the “About” section, look for “Indexing crawler.” If it says “Googlebot Smartphone,” you’re on mobile-first indexing. Nearly all sites are at this point.
Next, run a URL Inspection on your most important pages. Check:
- Is the page indexed? If not, check for noindex tags or crawl blocks on the mobile version.
- What crawler was used? It should say “Googlebot Smartphone.”
- View the rendered page. Does it look correct? Are all content sections visible?
Then run a Lighthouse audit in Chrome DevTools with the device set to “Mobile.” Record your baseline scores for Performance, Accessibility, Best Practices, and SEO. These are your starting numbers. Every optimisation you make should improve them.
Mistakes I See Singapore Businesses Make Repeatedly
After auditing hundreds of Singapore websites, certain patterns keep showing up. Here are the ones that hurt the most.
Blocking CSS and JS in Robots.txt
Some developers add blanket disallow rules in robots.txt that prevent Googlebot from accessing CSS and JavaScript files. This means Googlebot can’t render your page properly. It sees raw, unstyled HTML, or worse, an empty page if content is JavaScript-dependent. Check your robots.txt file right now. Make sure you’re not blocking /wp-content/, /assets/, or any directory containing CSS and JS files.
Using Separate Mobile URLs Without Proper Annotations
If you still maintain separate mobile URLs (m.example.com), you need correct rel="alternate" and rel="canonical" annotations. The desktop page should have a rel="alternate" media="only screen and (max-width: 640px)" link pointing to the mobile URL. The mobile page should have a rel="canonical" pointing back to the desktop URL. Missing or incorrect annotations cause indexing confusion.
Honestly, if you’re still on separate mobile URLs, the best move is migrating to responsive design. The annotation approach is fragile and creates ongoing maintenance headaches.
Ignoring Lazy-Loaded Above-the-Fold Content
Never lazy-load your above-the-fold images or content. I see this constantly on Singapore sites using page builders like Elementor or Divi. The builder applies lazy loading to all images globally, including the hero image. This delays LCP significantly because the browser waits for JavaScript to trigger the load. Your hero image should load eagerly with fetchpriority="high".
Overloading with Third-Party Scripts
A typical Singapore SME site I audit has: Google Analytics, Google Tag Manager, Facebook Pixel, a live chat widget, a reviews widget, a cookie consent banner, and sometimes a WhatsApp button plugin. Each adds 50-200KB of JavaScript and 1-3 additional network requests.
Audit every third-party script. Ask: does this script earn its weight? If a chat widget adds 180KB but generates one enquiry per month, remove it and use a simple WhatsApp link instead. You can use Google Tag Manager’s trigger conditions to load scripts only on specific pages or after specific user interactions.
What Comes Next: Voice Search, AI, and Mobile
Mobile-first indexing was Google’s response to how people searched in 2016-2020. The next evolution is already happening. Voice search queries, predominantly from mobile devices, now account for a growing share of searches. These queries tend to be longer and more conversational.
Google’s AI Overviews (formerly SGE) pull information from well-structured, fast-loading pages. If your mobile site is slow or poorly structured, you’re less likely to appear in these AI-generated summaries that sit at the top of search results.
The principle stays the same: build fast, well-structured mobile experiences with complete, accurate content. The sites that do this well today will be the ones that adapt most easily to whatever Google rolls out next.
Take the First Step Today
You don’t need to fix everything at once. Start with the highest-impact items. Run PageSpeed Insights on your homepage and your top three landing pages. Note your LCP, INP, and CLS scores. Then tackle the biggest bottleneck first, usually images or render-blocking JavaScript.
If you want a proper technical audit of your mobile site’s performance and indexing health, that’s exactly what we do at Best SEO. We’ll crawl your site with both user agents, compare content parity, measure your Core Web Vitals against your competitors, and give you a prioritised fix list with expected impact estimates. No fluff, just the technical work that moves rankings.
Reach out to us at Best SEO Singapore and let’s look at your site together.