If your website feels sluggish the moment someone tries to click a button or fill in a form, you have a First Input Delay problem. And it’s costing you visitors, conversions, and rankings. I’ve seen Singapore e-commerce sites lose 23% of their mobile conversions simply because their FID score crept above 250 milliseconds. The fix isn’t magic. It’s methodical.
This guide walks you through exactly how to improve First Input Delay, from diagnosis to execution. No fluff, just the technical steps that actually move the needle.
What First Input Delay Actually Measures
First Input Delay (FID) captures the gap between a user’s first interaction with your page and the moment the browser actually processes that interaction. We’re talking about clicks, taps, and key presses. Not scrolling, which is a separate concern.
Here’s what makes FID tricky: the delay isn’t caused by your server being slow. It’s caused by your browser’s main thread being occupied with something else, usually JavaScript execution. When a visitor taps “Add to Cart” on your site and the browser is busy parsing a 400KB analytics bundle, that tap just sits in a queue. The user sees nothing happen. They tap again. Still nothing. Then they leave.
FID only measures the delay of the first interaction, which makes it a snapshot metric. But it’s a revealing one, because it tells you whether your page is genuinely interactive or just visually loaded.
FID vs INP: A Quick Clarification
Google officially replaced FID with Interaction to Next Paint (INP) as a Core Web Vital in March 2026. INP measures responsiveness across all interactions, not just the first one. However, the optimisation techniques for both metrics overlap almost entirely. If you fix your FID, you’re fixing your INP too. Everything in this guide applies to both.
What Counts as a Good FID Score
Google’s thresholds are straightforward. Under 100 milliseconds is good. Between 100ms and 300ms needs improvement. Over 300ms is poor.
To put that in context, 100 milliseconds is roughly the threshold where a human perceives a response as “instant.” Go above that, and your site starts to feel laggy. For Singapore users on mobile devices, where network conditions and device processing power vary widely, hitting that sub-100ms target matters even more. A visitor browsing your site on an older Android phone while connected to MRT Wi-Fi is not getting the same experience as someone on a MacBook Pro with fibre broadband.
When I audit sites for local businesses here, I always check FID on mid-range mobile devices. That’s where the real story is.
How to Measure Your Current FID
Before you fix anything, you need accurate data. There are two types of FID measurement: field data (from real users) and lab data (simulated). You need both.
Field Data Tools
Google Search Console’s Core Web Vitals report is your starting point. It shows FID data aggregated from real Chrome users visiting your site over the previous 28 days. You’ll see which URLs are “good,” “needs improvement,” or “poor.” This is the data Google actually uses for ranking signals, so treat it as your source of truth.
The Chrome User Experience Report (CrUX) provides the same underlying dataset but lets you query it more flexibly. If you’re comfortable with BigQuery, you can pull granular FID percentile data segmented by device type and connection speed.
For custom tracking, install Google’s Web Vitals JavaScript library. It’s lightweight (about 1.5KB gzipped) and lets you send FID measurements to your own analytics. I recommend this for any site doing more than 10,000 monthly sessions. You’ll catch page-specific issues that aggregated reports miss.
Lab Data Tools
Google PageSpeed Insights combines field data with a Lighthouse lab audit. Run your key landing pages through it and look at the “Diagnostics” section. It won’t give you a literal FID score in lab mode (FID requires real user interaction), but it reports Total Blocking Time (TBT), which correlates strongly with FID.
Chrome DevTools’ Performance panel is where you do the deep work. Record a page load, then examine the main thread flame chart. Look for long tasks, any task exceeding 50 milliseconds. Those long tasks are what block your FID.
How to Improve First Input Delay: 7 Technical Steps
1. Audit and Reduce JavaScript Execution Time
JavaScript is responsible for FID problems in about 90% of the cases I see. Open Chrome DevTools, go to the Performance tab, and record a page load. Sort tasks by duration. You’re looking for anything on the main thread that runs longer than 50ms.
Common culprits I find on Singapore business sites: oversized jQuery libraries still loaded for a single carousel, full lodash imports when only one function is used, and unminified custom scripts from the original developer who built the site in 2019.
Actionable steps:
- Run
Coveragein Chrome DevTools (Ctrl+Shift+P, type “Coverage”) to see what percentage of your JS is actually executed on page load. I regularly find 60-70% of loaded JavaScript goes unused. - Remove dead code. If a script isn’t firing, delete it.
- Minify and compress remaining scripts using Terser or your bundler’s built-in minification.
2. Break Up Long Tasks with Code Splitting
Even necessary JavaScript can cause FID issues if it runs as one monolithic block. The browser’s main thread can only do one thing at a time. A 300ms JavaScript task means the browser is completely unresponsive for 300ms.
Code splitting breaks your JavaScript into smaller chunks that load on demand. If you’re using React, Vue, or Next.js, dynamic imports make this straightforward:
const HeavyComponent = React.lazy(() => import('./HeavyComponent'));
For WordPress sites (which make up a large portion of the Singapore SME market), plugins like Asset CleanUp or Perfmatters let you disable scripts on pages where they aren’t needed. Your WooCommerce checkout scripts don’t need to load on your blog posts.
3. Defer and Async Non-Critical Scripts
Every script tag without async or defer blocks the parser. That means the browser stops everything to download and execute that script before it can respond to user input.
Add defer to scripts that need to run in order but aren’t needed immediately. Add async to independent scripts like analytics. For third-party scripts you can’t modify, wrap them in a setTimeout or load them after user interaction:
document.addEventListener('scroll', () => { loadChatWidget(); }, { once: true });
This technique alone dropped FID from 280ms to 65ms on a client’s property listing site. The chatbot widget was loading a 180KB script on every page load, blocking the main thread for 200ms. Loading it on first scroll solved the problem completely.
4. Tame Third-Party Scripts
Third-party scripts are the silent killers of FID. Analytics, ad networks, live chat, social media embeds, heatmap tools. Each one adds main thread work.
Here’s my process: list every third-party script on your page using Chrome DevTools’ Network tab filtered by “Third-party.” For each one, ask: is this generating revenue or critical data? If not, remove it. If yes, can it load after the page is interactive?
I worked with a Singapore F&B brand running seven third-party scripts on their menu page. We removed two (abandoned A/B testing tools), deferred three (Facebook Pixel, Google Analytics, and a review widget), and kept two loading normally (payment gateway and booking system). FID dropped from 340ms to 78ms.
5. Implement Server-Side Rendering or Static Generation
If your site is built with a JavaScript framework like React or Vue, the browser has to download, parse, and execute your entire application before the page becomes interactive. This is client-side rendering, and it’s brutal for FID.
Server-Side Rendering (SSR) sends pre-rendered HTML from the server, so the browser can display content immediately while JavaScript hydrates in the background. Static Site Generation (SSG) goes further by pre-building pages at deploy time, eliminating server processing entirely.
For content-heavy sites, SSG with frameworks like Next.js or Nuxt is the gold standard. Pages load as fast as static HTML because they are static HTML. The JavaScript layer adds interactivity after the initial render, keeping FID minimal.
6. Reduce Main Thread Work Beyond JavaScript
JavaScript gets most of the blame, but layout thrashing and excessive DOM size also contribute to main thread congestion.
If your page has more than 1,500 DOM elements, the browser spends significant time on style calculations and layout. Simplify your HTML structure. Remove unnecessary wrapper divs. Flatten deeply nested components.
Also check for forced synchronous layouts. This happens when JavaScript reads a layout property (like offsetHeight) and then immediately writes to the DOM, forcing the browser to recalculate layout mid-script. Batch your DOM reads and writes separately.
7. Offload Heavy Computation to Web Workers
Web Workers run JavaScript on a separate thread, completely independent of the main thread. If your site does any heavy computation, such as data processing, complex filtering, or real-time calculations, move that work to a Web Worker.
A practical example: a Singapore fintech client had a loan calculator that ran complex amortisation calculations on every input change. Each calculation took 80ms on the main thread. Moving it to a Web Worker made the input fields feel instant because the main thread was free to handle user interactions while the Worker crunched numbers in the background.
The syntax is simple:
const worker = new Worker('calculator.js');
worker.postMessage(loanData);
worker.onmessage = (e) => { displayResults(e.data); };
CSS and Font Optimisation: The Often-Overlooked Piece
While CSS doesn’t directly cause FID in the way JavaScript does, render-blocking CSS delays the point at which the page becomes interactive. If the browser is still downloading and parsing your stylesheets, it won’t process user input.
Inline your critical CSS (the styles needed for above-the-fold content) and load the rest asynchronously. Tools like Critical or Critters automate this extraction.
For fonts, use font-display: swap in your @font-face declarations. This tells the browser to show text immediately using a system font, then swap in your custom font once it’s loaded. Your visitors see content faster, and the page reaches interactivity sooner.
Monitoring FID After Optimisation
Fixing FID once isn’t enough. New features, plugin updates, and content changes can reintroduce delays. Set up ongoing monitoring.
At minimum, check your Search Console Core Web Vitals report monthly. Better yet, use the Web Vitals library to send real-time data to your analytics platform. Set alerts for when FID (or INP) crosses the 100ms threshold on any high-traffic page.
If you’re running an e-commerce site or lead generation funnel, correlate your FID data with conversion rates. I’ve seen cases where a 50ms FID improvement on a checkout page increased completed transactions by 8%. That’s real revenue, not a vanity metric.
Frequently Asked Questions
Is FID Still Relevant Now That Google Uses INP?
FID as a Core Web Vital was replaced by INP in March 2026. But the optimisation techniques are nearly identical. Fix your FID, and your INP improves too. Think of this guide as applicable to both metrics.
Does FID Affect My Google Rankings?
Yes. Page experience signals, including Core Web Vitals, are a confirmed ranking factor. A poor FID (or INP) score won’t tank your rankings overnight, but it creates a disadvantage against competitors with faster sites, especially in competitive Singapore search markets.
My FID Is Fine on Desktop but Poor on Mobile. Why?
Mobile devices have less processing power than desktops. The same JavaScript that executes in 30ms on a laptop might take 150ms on a mid-range phone. Always optimise for mobile first, and test on real devices, not just Chrome’s device emulation.
Can WordPress Sites Achieve Good FID Scores?
Absolutely. But it requires discipline with plugins. Every plugin adds JavaScript. Audit your plugins quarterly, remove what you don’t use, and use a script management plugin to control what loads where. I’ve gotten WordPress sites to sub-50ms FID with careful optimisation.
How Long Does It Take to See FID Improvements in Search Console?
Search Console’s Core Web Vitals report uses a rolling 28-day window of field data. After deploying fixes, expect to wait 4 to 6 weeks before the report fully reflects your improvements.
Need Help Getting Your Site’s Performance Right?
If you’ve gone through these steps and your FID (or INP) is still stubbornly above 100ms, there’s likely something deeper going on. Maybe a complex third-party integration, a legacy codebase, or a hosting environment that’s working against you.
At BestSEO, we run full Core Web Vitals audits as part of our technical SEO work. We don’t just flag the problems. We fix them, test the results on real devices, and monitor them over time. If you want a clear diagnosis and a practical fix, book a free strategy session and we’ll take a look together.