DEV Community: Daniel Cheong

How we cut INP from 480ms to under 200ms on a legacy site (no rewrite)

Daniel Cheong — Sun, 07 Jun 2026 07:25:32 +0000

Most "make it faster" advice assumes you can rebuild. On real small-business sites — a clinic on WordPress, a retailer on a 2018 theme — you usually can't. Here's how we cut Interaction to Next Paint (INP) on a legacy site from ~480ms to under 200ms without a rewrite.

1. Find the slow interactions, don't guess

INP measures the worst interaction, not the average. Pull real-user data first:

import { onINP } from 'web-vitals';
onINP((metric) => {
  // ship to your analytics endpoint
  navigator.sendBeacon('/vitals', JSON.stringify({
    value: metric.value,
    target: metric.attribution?.interactionTarget,
  }));
});

The interactionTarget tells you which element is slow — usually a menu toggle, a filter, or an "add to cart".

2. Break up long tasks

The usual culprit is a single handler doing too much synchronously. Yield to the main thread:

async function handleClick() {
  updateUIImmediately();           // cheap, visible feedback first
  await scheduler.yield?.() ?? new Promise(r => setTimeout(r));
  doExpensiveWork();               // the rest, after paint
}

3. Defer third-party scripts

Chat widgets, pixels and analytics are the silent INP killers. Load them after first interaction or on idle:

<script>
  addEventListener('load', () => requestIdleCallback(() => {
    const s = document.createElement('script');
    s.src = 'https://widget.example.com/chat.js';
    document.body.append(s);
  }));
</script>

4. Measure again

After these three changes, the legacy site moved from a failing INP to passing — no framework migration, no redesign.

If you want this run against your own legacy site, we do exactly this for Singapore SMEs at SGBP — performance and AI work on the site you already have. Happy to take a look — drop us a line.

— Daniel

I shipped 14 AI features to production in 2025. Here's the checklist nobody talks about.

Daniel Cheong — Tue, 26 May 2026 02:00:31 +0000

I run engineering at a small Singapore agency. Over 2025 we shipped 14 AI features into production websites — RAG chatbots, AI search, summary generators, document Q&A, agentic form fillers. None of them were "throw GPT-4 at it" demos. All had real users, real bills, real complaints.

This post is the checklist we use now, distilled from things that went wrong in the first 8 features. It's deliberately not aspirational. It's the boring operational layer most LLM tutorials skip.

If you're about to ship an AI feature past prototype, read this first.

The 7 failure modes that bit us, in order of pain

1. The "happy path demo" trap

The first 4 features all looked great on day one of QA. Three of them broke production within two weeks because the demo path is ~5% of real user traffic.

Real users:

Paste 8 KB of nested HTML when asked for a name
Ask "where is the chicken curry" to a real-estate chatbot
Trigger 14 concurrent requests by holding down the send button
Run the chatbot in an iframe inside an Outlook email preview pane

Fix: Before launch, run a "weirdness simulation" — script 200 inputs scraped from your existing customer-support transcripts, plus 50 deliberately broken inputs (emoji floods, SQL-injection-shaped strings, opposite-language Unicode). Don't ship until your tracing dashboard shows graceful handling for ≥95% of them.

2. Cost runaways from one bad page

Feature #5 (a "summarise this page" button on a documentation site) burned through three months of our LLM budget in 11 days. Why: one page that nobody had read in months had a 200,000-token rendered HTML output because of an infinite-recursion bug in their CMS.

Fix: Token budgets per request, enforced server-side. Always. Plus rate-limiting by IP+session, not just by API key. Plus a daily $-cap circuit breaker that pages you (literally) at 80% of budget.

// One example — Cloudflare Worker enforcing per-request input cap
const MAX_INPUT_TOKENS = 8000;
const inputTokens = await tokenizer.encode(userInput).length;
if (inputTokens > MAX_INPUT_TOKENS) {
  return new Response("Input too long. Please trim and retry.", { status: 413 });
}

3. "It works on Gemini Flash 2.5" doesn't mean it works on Gemini Flash 2.5

Two features that ran perfectly in our staging Gemini Flash 2.5 deployment started returning truncated answers in prod. Reason: regional capacity changes, Google was silently routing some prod requests to the older Flash 2.0 endpoint, which has tighter output limits.

Fix: Pin model versions explicitly (gemini-2.5-flash-001, not gemini-2.5-flash). Log the model that actually served each request from the response metadata. Alert if it deviates.

4. RAG retrieval drift after content updates

Feature #7 was a customer-service chatbot for a clinic. They updated their service-hours page in October. We didn't re-embed for 11 days. Customers kept being told outdated hours by the bot. Three angry phone calls before we figured it out.

Fix: Tie retrieval-index updates to your CMS publish webhook, not a cron. The CMS knows when content changes; cron only knows the time. We use a Cloudflare Workers webhook receiver that triggers re-embedding within ~30 seconds of a CMS publish.

5. The hallucination tax on "trustworthy" outputs

For feature #8 (a property-listing assistant), we used careful system prompts and grounding. The bot still confidently invented a 3-bedroom unit at a $X price that didn't exist. The agency that licensed it got a real customer enquiry for that imaginary unit.

Fix: Always show the source with the answer. If you can't cite, don't answer. Concretely: every chatbot response includes a sources: [] array linking to the retrieved chunks. The frontend renders them inline as [1] [2] markers. Users self-police when they can see sources are weak.

6. The "but what if they ask about competitors" question

Feature #9 was a chatbot for a regional bank. Marketing asked midway through QA: "What if a user asks 'is OCBC better than DBS?'" Nobody had thought about this. The bot, helpfully, answered with hallucinated comparative facts.

Fix: Topic-routing guards. Before the LLM call, classify the user query against a fixed list of allowed topics for that deployment. Off-topic queries get a polite deflection ("I can only help with X, Y, Z — try our search bar for general questions.") This is a 50ms classifier call. The savings on PR risk are huge.

7. Streaming UI looks fast but feels broken

We launched feature #11 with streamed token output. Beautiful in our office. In production, users on flaky mobile connections (60% of our traffic) saw text appear, pause for 3 seconds, then keep going. They thought it had crashed and refreshed. Refresh = start over = bad UX.

Fix: Streaming UX needs:

A "thinking" indicator that's separate from the streamed text (so users see something happens during gaps)
Heartbeat events every 500ms so the connection doesn't appear dead
A non-streaming fallback if the client supports it (mobile gets fallback by default in our setup)

The production checklist (the part most people scroll for)

Before any AI feature touches real users, we now run through this. It's saved us 3 weeks of post-launch firefighting per feature on average.

Inputs

[ ] Per-request input token cap, enforced server-side, returns 413 not 500
[ ] Per-user rate limit (cookie+IP), separate from per-API-key
[ ] "Weirdness simulation" run of 250 inputs passed before launch
[ ] Input is sanitized of HTML/script before logging (you WILL log inputs — don't log XSS)
[ ] Multi-language behaviour tested if your audience isn't 100% English

Costs

[ ] Daily $-budget circuit breaker that pages on-call at 80%
[ ] Per-tenant budget if multi-tenant (one customer can't burn the others' allocation)
[ ] Logged cost per request, with attribution tag (feature, userId, tenant)
[ ] Free-tier downgrade path: if budget exceeded, system serves cached/template responses instead of failing

Models

[ ] Pin model version explicitly (-001 suffix, not the moving alias)
[ ] Log the model that served each request (from response metadata)
[ ] Alert on model-version drift in production
[ ] Tested with the worst model in your fallback chain (some traffic will route there)
[ ] Temperature locked at the lowest value that doesn't break the use case (we default to 0.2)

Grounding & truthfulness

[ ] Every answer cites its sources, in the response payload
[ ] Frontend renders sources visibly with the answer
[ ] Retrieval index re-builds on CMS publish webhook, NOT on a daily cron
[ ] "I don't know" path tested — does the bot actually defer when context is weak?
[ ] Topic-routing guard before LLM call (fixed allowlist per deployment)

[ ] Streaming has separate "thinking" indicator from streamed content
[ ] Heartbeat events keep the connection alive for slow networks
[ ] Non-streaming fallback for clients/networks that need it
[ ] Loading states for the first 200ms (don't show empty boxes)
[ ] Error states clearly say "try again" with what went wrong, not "something happened"

Compliance & ethics

[ ] User data sent to LLM provider is logged in your privacy policy
[ ] DPA in place with the LLM provider for PII regions (Singapore PDPA, EU GDPR, etc.)
[ ] No PII in retraining or vendor analytics pipelines (check the small print)
[ ] User-facing disclaimer that this is AI-generated where it matters (medical, legal, financial)

Monitoring

[ ] Every request logged with: timestamp, tenant, latency, tokens-in, tokens-out, $, model, source IPs
[ ] Hallucination canaries — synthetic queries with known correct answers, run hourly, alert on drift
[ ] User feedback widget on every response ("Was this helpful? Y/N + free text")
[ ] Weekly review of low-rated responses → manual triage → prompt updates

What didn't make this list

A few things I expected to matter but didn't, in practice:

Model fine-tuning — every time we considered it, prompt iteration + better RAG got us there faster. Save fine-tuning for genuinely specialized domains.
GPU local inference — interesting at scale, but for our SMB clients the API cost is rarely the actual bottleneck. Engineering complexity is.
Embeddings choice — we tried 5 embedding models. text-embedding-004 and text-embedding-3-small were both fine. Pick one and move on.
Chunking strategy debates — 300-600 char chunks with sentence boundaries, overlap of 50 chars. Stop reading chunking blog posts. Ship.

The bigger pattern

AI features are now ~20% of new builds we ship at SGBP — Singapore Build Partners. The pattern that's emerged: the LLM part is the easiest 30% of the work. The other 70% is the boring operational scaffolding above. That's where the actual product-readiness lives.

If you're an in-house dev or agency about to ship your first production AI feature, save this checklist. The version I keep in our internal wiki has another ~40 items, but the ones above cover 80% of the pain.

If your team is staring at a "we should add AI to this" mandate from leadership and isn't sure where to start, we do this for clinics, retailers, and SaaS teams across Singapore — happy to talk through your specific stack.

Otherwise — ship slowly, log everything, and never trust the happy path.

Daniel Cheong is a Senior Frontend Engineer at SGBP. He writes about web performance, AI in production, and the boring infrastructure that makes web products actually work.

How to add a Gemini-powered chatbot to any legacy site in ~2 hours (with code)

Daniel Cheong — Sun, 24 May 2026 13:43:20 +0000

A clinic in Singapore came to us last month with a familiar problem: a 7-year-old WordPress site, no budget for a full rebuild, but their front desk was drowning in repeat phone questions. "Are you open on weekends?" "Do you do paediatric vaccinations?" "How do I book an MRI?"

They wanted an AI chatbot that knew their actual content — opening hours, services, doctor profiles — and could answer in English or Malay without making things up. Total spend cap: under S$20/month at their traffic.

I shipped it in one afternoon. This post is the actual walk-through, with code you can lift directly. No rewrites, no React migration, no Webflow. Just plain JavaScript + Gemini.

If you're staring at a legacy CMS and wondering how to add an AI helper without burning weeks, read on.

What we built (the 30-second version)

A floating chat widget that:

Loads as a single <script> tag at the bottom of the site (no plugin install, no template edit).
Pulls answers from a small RAG (Retrieval-Augmented Generation) index built from the clinic's own pages.
Hands off to a human (WhatsApp link) when confidence is low or the topic is medical.
Costs ~S$3-5/month at their traffic (a few hundred sessions/week).

Stack:

Gemini 2.5 Flash for the LLM (free tier covers most of their traffic; Flash is plenty smart for "what are your hours")
Cloudflare Workers as the proxy + RAG retriever (zero cold start, $0 at this scale)
Cloudflare Vectorize as the embedding store (free up to 5M dimensions; we used ~15K)
Vanilla JS + a tiny shadow-DOM widget for the UI

No framework dependency on the client side. Works on WordPress, Webflow, Shopify, a static HTML site from 2014 — anywhere you can drop a script tag.

Step 1 — Crawl your own site and chunk it

You can't RAG against pages you haven't indexed. The first job is pulling the site's content into clean chunks.

// scripts/crawl.mjs — run once locally
import { JSDOM } from "jsdom";

const SEED = "https://clinic.example.com";
const visited = new Set();
const chunks = [];

async function crawl(url) {
  if (visited.has(url) || visited.size > 200) return;
  visited.add(url);
  const html = await fetch(url).then(r => r.text());
  const dom = new JSDOM(html);
  const doc = dom.window.document;

  // Strip nav/footer/scripts — keep the body content only
  doc.querySelectorAll("nav, footer, script, style, .menu, .sidebar").forEach(el => el.remove());
  const text = doc.body.textContent.replace(/\s+/g, " ").trim();

  // Chunk by ~400 chars on sentence boundaries
  const sentences = text.match(/[^.!?]+[.!?]+/g) || [text];
  let buf = "";
  for (const s of sentences) {
    if ((buf + s).length > 400) {
      if (buf) chunks.push({ url, text: buf.trim() });
      buf = s;
    } else {
      buf += " " + s;
    }
  }
  if (buf) chunks.push({ url, text: buf.trim() });

  // Follow internal links
  const links = [...doc.querySelectorAll("a[href]")]
    .map(a => new URL(a.getAttribute("href"), url).toString())
    .filter(u => u.startsWith(SEED));
  for (const l of links) await crawl(l);
}

await crawl(SEED);
console.log(`Crawled ${visited.size} pages, ${chunks.length} chunks`);
await Deno.writeTextFile("chunks.json", JSON.stringify(chunks, null, 2));

For our clinic, this produced 143 chunks from 38 pages in under 90 seconds. The total token count after chunking was ~9,000 — well within free-tier embedding budgets.

Step 2 — Embed the chunks with Gemini

Gemini's text-embedding-004 model is free at modest volumes and gives 768-dim vectors that work fine for short docs.

// scripts/embed.mjs
import chunks from "./chunks.json" assert { type: "json" };

const KEY = process.env.GEMINI_API_KEY;
const out = [];
for (const c of chunks) {
  const r = await fetch(
    `https://generativelanguage.googleapis.com/v1beta/models/text-embedding-004:embedContent?key=${KEY}`,
    {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        model: "models/text-embedding-004",
        content: { parts: [{ text: c.text }] },
      }),
    }
  ).then(r => r.json());
  out.push({ ...c, embedding: r.embedding.values });
}
await Deno.writeTextFile("embedded.json", JSON.stringify(out));

143 embedding calls, free tier, ~40 seconds. Push the resulting vectors to Cloudflare Vectorize:

npx wrangler vectorize create clinic-rag --dimensions=768 --metric=cosine
node scripts/upsert-vectors.mjs   # iterates embedded.json → vectorize upsert

That's the entire offline build. Re-run the crawl + embed monthly (or via a CI cron) and you're never stale.

Step 3 — The Worker (the actual brain)

This is the only piece that runs in production. ~80 lines.

// worker.js — deployed via Wrangler
export default {
  async fetch(req, env) {
    const { question, history = [] } = await req.json();

    // 1. Embed the user question
    const qEmb = await embed(question, env.GEMINI_KEY);

    // 2. Retrieve top-5 chunks from Vectorize
    const hits = await env.VECTORIZE.query(qEmb, { topK: 5, returnMetadata: true });
    const context = hits.matches
      .map(m => `[Source: ${m.metadata.url}]\n${m.metadata.text}`)
      .join("\n\n");

    // 3. Decide whether to defer to a human
    if (hits.matches[0].score < 0.55 || /pain|emergency|chest|bleeding|dizzy/i.test(question)) {
      return json({
        answer: "I can't reliably answer that — please WhatsApp our front desk at +65 6815 4321 for the fastest response.",
        defer: true,
      });
    }

    // 4. Ask Gemini, grounded on the retrieved context
    const prompt = `You are a helpful assistant for ${env.CLINIC_NAME}. Answer ONLY from the context below. If unsure, say "Please call the clinic directly."

Context:
${context}

Conversation so far:
${history.map(h => `${h.role}: ${h.text}`).join("\n")}

User: ${question}
Assistant:`;

    const llm = await fetch(
      `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent?key=${env.GEMINI_KEY}`,
      {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
          contents: [{ parts: [{ text: prompt }] }],
          generationConfig: { temperature: 0.2, maxOutputTokens: 400 },
        }),
      }
    ).then(r => r.json());

    return json({ answer: llm.candidates[0].content.parts[0].text, sources: hits.matches.map(m => m.metadata.url) });
  },
};

async function embed(text, key) {
  const r = await fetch(
    `https://generativelanguage.googleapis.com/v1beta/models/text-embedding-004:embedContent?key=${key}`,
    { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ model: "models/text-embedding-004", content: { parts: [{ text }] } }) }
  ).then(r => r.json());
  return r.embedding.values;
}

const json = (data) => new Response(JSON.stringify(data), { headers: { "Content-Type": "application/json", "Access-Control-Allow-Origin": "*" } });

Three production lessons that mattered:

The score < 0.55 defer threshold is gold. Tuned downward from 0.7 after the first 3 days — embeddings on short clinic content cluster low. Without this, the bot tried to answer "do you take Medisave for IVF" with hallucinations.
Hard-coded keyword defer for anything medical-symptomy. Legal cover. The bot will never try to diagnose, even when it could.
temperature: 0.2 keeps answers boring and factual. Anything higher and Gemini started inventing clinic hours that don't exist.

Step 4 — The 80-line frontend widget

This is the only thing the legacy site ever loads. Drop it in the footer, no other changes.

<script>
(() => {
  const WORKER = "https://clinic-bot.your-worker.workers.dev";
  const host = document.createElement("div");
  const root = host.attachShadow({ mode: "open" });
  root.innerHTML = `
    <style>
      :host { all: initial; }
      .fab { position: fixed; bottom: 24px; right: 24px; width: 56px; height: 56px; border-radius: 28px; background: #0EA5E9; color: white; display: grid; place-items: center; cursor: pointer; box-shadow: 0 4px 12px rgba(0,0,0,.15); font: 600 14px system-ui; z-index: 9999; }
      .panel { position: fixed; bottom: 96px; right: 24px; width: 360px; height: 480px; background: white; border-radius: 12px; box-shadow: 0 8px 24px rgba(0,0,0,.18); display: none; flex-direction: column; font: 14px/1.4 system-ui; }
      .panel.open { display: flex; }
      .msgs { flex: 1; overflow-y: auto; padding: 12px; }
      .msg { padding: 8px 12px; margin: 6px 0; border-radius: 12px; max-width: 80%; }
      .msg.user { background: #0EA5E9; color: white; margin-left: auto; }
      .msg.bot { background: #F1F5F9; color: #0F172A; }
      .input { display: flex; padding: 8px; border-top: 1px solid #E2E8F0; }
      .input input { flex: 1; padding: 8px; border: 1px solid #CBD5E1; border-radius: 6px; font: 14px system-ui; }
      .input button { margin-left: 6px; padding: 8px 14px; background: #0EA5E9; color: white; border: none; border-radius: 6px; cursor: pointer; }
    </style>
    <div class="fab" id="fab">Chat</div>
    <div class="panel" id="panel">
      <div class="msgs" id="msgs"><div class="msg bot">Hi! Ask about our hours, services, or how to book an appointment.</div></div>
      <form class="input" id="form"><input id="q" placeholder="Type a question…" required><button>Send</button></form>
    </div>
  `;
  document.body.appendChild(host);
  const $ = (s) => root.getElementById(s);
  const history = [];
  $("fab").onclick = () => $("panel").classList.toggle("open");
  $("form").onsubmit = async (e) => {
    e.preventDefault();
    const q = $("q").value.trim(); if (!q) return;
    $("q").value = "";
    $("msgs").insertAdjacentHTML("beforeend", `<div class="msg user">${escapeHtml(q)}</div>`);
    history.push({ role: "user", text: q });
    const r = await fetch(WORKER, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ question: q, history }) }).then(r => r.json());
    $("msgs").insertAdjacentHTML("beforeend", `<div class="msg bot">${escapeHtml(r.answer)}</div>`);
    history.push({ role: "assistant", text: r.answer });
    $("msgs").scrollTop = $("msgs").scrollHeight;
  };
  function escapeHtml(s) { return s.replace(/[&<>"']/g, c => ({ "&": "&amp;", "<": "&lt;", ">": "&gt;", "\"": "&quot;", "'": "&#39;" }[c])); }
})();
</script>

Shadow DOM means it can't conflict with the host site's CSS — and we tested it against three increasingly broken WordPress themes without a single style collision. The whole script is 3.2 KB gzipped.

What it cost the clinic, real numbers

After 3 weeks running:

Item	Usage	Cost
Gemini 2.5 Flash	~4,200 requests	$0 (free tier)
Gemini text-embedding-004	~4,500 calls	$0 (free tier)
Cloudflare Workers	~9,000 invocations	$0 (free tier)
Cloudflare Vectorize	15K dimensions stored, ~9K queries	$0 (free tier)
Total monthly		S$0

At their projected scale (3× current traffic), they'd cross into paid tier — estimated S$3-5/month. Compare to a SaaS chatbot at S$50-100/month with worse grounding.

What I'd do differently next time

Crawl with sitemaps first, fall back to link-following. The link crawler hit two infinite calendar pages and ate 12 minutes before I added depth limits.
Store the embedded markdown source, not the stripped text. When the LLM cites a source URL, having clean markdown in the context lets it format lists/tables properly in answers.
Tag chunks by section (services, hours, doctors). Routing high-confidence intents directly to a deterministic answer skips the LLM call entirely for ~30% of traffic.

The bigger pattern

This same approach works for clinics, restaurants, professional services, real estate listings, any business with structured public content. The legacy-site constraint is actually a feature: you don't have to convince ops to change anything, just paste a script tag.

If you're an agency or in-house dev looking at a WordPress/Webflow site and getting asked "can we add AI?" — the answer in 2026 is yes, in an afternoon, for ~S$5/month. The model quality has crossed the line where you can ship grounded answers without a research team behind you.

At our agency SGBP — Singapore Build Partners we've rolled this same pattern out for clinics, hawker chains, and B2B service firms across Singapore — happy to compare notes if you're sizing one up. Drop your repo or stack in the comments and I'll share the version we used for that vertical.

Otherwise — go ship it. Three hours of your weekend, one less plugin invoice for your client.

Daniel Cheong is a Senior Frontend Engineer at SGBP. He writes about Vue, Astro, AI integrations, and the boring infrastructure that makes web products actually fast.