{ "version": "https://jsonfeed.org/version/1.1", "title": "Bora Ocaker — Notes from the workbench", "home_page_url": "https://boraocaker.com/en/blog", "feed_url": "https://boraocaker.com/feed.json", "description": "Short technical notes about React, performance, GSAP and the messy reality of shipping web work.", "language": "en-US", "authors": [ { "name": "Bora Ocaker", "url": "https://boraocaker.com" } ], "items": [ { "id": "https://boraocaker.com/en/blog/og-images-with-satori", "url": "https://boraocaker.com/en/blog/og-images-with-satori", "title": "Generating OG images at build time with Satori", "summary": "Every post on this site gets its own 1200×630 social card, rendered from JSX to PNG at build time with Satori and resvg. No headless Chrome, no screenshot service, no runtime cost.", "content_text": "When you paste a link into LinkedIn or WhatsApp, the preview card is the first — often only — impression. A site that ships one static `og-image.jpg` for every page is leaving that impression on the table.\n\nI wanted a unique card per blog post, with the title, date, and reading time baked in. The options were: a screenshot service (slow, costs money, another dependency to babysit), headless Chrome in CI (heavy, flaky), or render the image myself. I picked the last one.\n\n## The pipeline\n\nThe whole thing is one Node script that runs before the build:\n\n```\nfrontmatter parse → satori(JSX-as-object) → SVG string → resvg → PNG → disk\n```\n\n[Satori](https://github.com/vercel/satori) takes a tree of elements with a flexbox subset of CSS and gives you back an SVG. [`@resvg/resvg-js`](https://github.com/yisibl/resvg-js) rasterizes that SVG to a PNG buffer. Neither needs a browser.\n\n## JSX without React\n\nSatori accepts JSX, but I didn't want to pull React into a build script. It turns out Satori only needs a plain object tree — `{ type, props: { children } }` — so a four-line helper is enough:\n\n```js\nfunction el(type, props, ...children) {\n return { type, props: { ...props, children: children.length === 1 ? children[0] : children } };\n}\n```\n\nNow the card template is just nested `el(...)` calls. Zero framework dependencies — the script runs on a bare Node install.\n\n## The font gotcha\n\nSatori needs the font as raw bytes — an `ArrayBuffer`, not a `woff2` URL. The trick is hitting the Google Fonts CSS endpoint with a desktop User-Agent so it serves you a `.ttf`:\n\n```js\nconst css = await fetch(\n `https://fonts.googleapis.com/css2?family=${family}:wght@${weight}&display=swap`,\n { headers: { \"User-Agent\": \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...\" } }\n).then((r) => r.text());\nconst ttfUrl = css.match(/url\\((https:\\/\\/[^)]+\\.ttf)\\)/)[1];\n```\n\nI cache the downloaded TTF to `scripts/.fonts/` so subsequent builds skip the network entirely. First build pays the round-trip once.\n\n> [!warn] Satori only supports a flexbox subset\n> No `grid`, no `position: absolute` in older versions, every element needs an explicit `display: flex`. If a card renders blank, it's almost always a missing `display`.\n\n## Making a feed read as a series\n\nThe detail I'm happiest with: each post gets a signature accent colour, assigned by **issue number** — oldest post is issue 01, and the number never changes. Six harmonised accents on the same dark ink base. A column of these cards on someone's LinkedIn feed reads as a series, not six random recolours.\n\nThe issue numbering has to be deterministic, so I sort by date ascending and index from there. The exact same palette lives in `src/utils/blog-palette.ts` and drives the on-site post list too — one source of truth for both.\n\n## What it costs\n\nNothing at runtime. The PNGs land in `public/og/blog//.png`, Vite copies them into `dist/`, and they're served as static files. Adding a post regenerates one image in a couple hundred milliseconds. No service to pay for, nothing to break in production.\n\nIf you're on a framework with a built-in OG route (Next's `ImageResponse` is literally Satori under the hood), use that. If you're on a hand-rolled Vite SPA like I am, 120 lines of build script gets you the same result.\n", "date_published": "2026-06-01T00:00:00.000Z", "date_modified": "2026-06-01T00:00:00.000Z", "image": "https://boraocaker.com/og/blog/en/og-images-with-satori.png", "tags": [ "og", "satori", "build", "seo" ], "language": "en-US" }, { "id": "https://boraocaker.com/en/blog/prerendering-a-vite-spa", "url": "https://boraocaker.com/en/blog/prerendering-a-vite-spa", "title": "Prerendering a Vite SPA for SEO without going SSR", "summary": "My site is a client-rendered React SPA. To a crawler that's a near-empty body. Here's the 200-line post-build script that writes real HTML per route — without adopting Next or a server.", "content_text": "A Vite SPA ships one `index.html` and a JavaScript bundle. The router lives in the client. Open the page in a browser and React fills the `#root` div — but the *file on disk* has an empty body. Google can run JS now, but it's slower, racier, and you're betting your indexing on the crawler being patient.\n\nI didn't want to migrate the whole thing to Next just to get HTML in front of crawlers. So I wrote a post-build step that prerenders every route to a static file.\n\n## The shape of it\n\nAfter `vite build`, I have `dist/index.html` — the fully-built shell, with fonts, favicons, analytics, and the base meta tags already in place. I treat that as a **template** and, for every route the app knows about, write a real `dist//index.html` with route-specific content swapped in.\n\nCloudflare Pages serves `//index.html` when a request comes in for `/`. So the prerendered file gets served first; the SPA catch-all redirect is only hit when no per-route file exists. Free per-route HTML, no server.\n\n## What gets swapped per route\n\nEach route overrides only what varies:\n\n- `` — `en` or `tr`\n- `` and `<meta name=\"description\">`\n- `<link rel=\"canonical\">` + hreflang alternates\n- Open Graph / Twitter title, description, and (for posts) image\n- Route-specific JSON-LD: `BlogPosting`, `Service`, `LocalBusiness`\n\nThe swaps are plain string `.replace()` against the shell. No DOM parser — regex on a known-shape template is faster and has zero dependencies:\n\n```js\nhtml = html.replace(/<title>[^<]*<\\/title>/, `<title>${escapeHtml(title)}`);\n```\n\n## The part that actually matters for blog posts\n\nMeta tags help, but for an *article* the crawler wants the body. So for each post I render the markdown to HTML with [`marked`](https://marked.js.org/) and inject it straight into `#root`:\n\n```js\nhtml = html.replace('
', `
${bodyContent}
`);\n```\n\nNow the file on disk contains the full article text. Here's the trick that makes it safe: **React wipes and re-renders on hydration.** The user mounts the SPA, React clears `#root`, and they get the exact same client app they always did. The prerendered HTML exists purely for the crawler that never runs the JS.\n\n> [!note] This is \"prerender\", not SSR\n> There's no server rendering React. I render markdown to HTML with a different library at build time, purely as crawler bait. The two never need to match byte-for-byte because the user never sees the prerendered version.\n\n## Routes, enumerated\n\nThe script loops over a known route list — home, about, projects, blog list, every blog slug × 2 languages, services, and the Turkish Antalya landing page. Because the routes are an enum, not a filesystem convention, I just iterate them explicitly. ~20 files written in well under a second.\n\n## What I'd watch out for\n\n- **Keep the regexes anchored to the shell's exact markup.** If you change the meta tag format in `index.html`, the replace silently no-ops. I'd add an assertion that each replace actually changed the string.\n- **The hydration wipe means a flash is possible** if your JS is slow — the crawler HTML shows, then React blanks it, then re-renders. On a fast bundle it's imperceptible; on a heavy one, prerender the *real* layout, not a simplified one.\n\nFor a portfolio with a dozen routes, this beats dragging in a meta-framework. For fifty routes that change hourly, you want real SSR or ISR. Match the tool to the blast radius.\n", "date_published": "2026-05-31T00:00:00.000Z", "date_modified": "2026-05-31T00:00:00.000Z", "image": "https://boraocaker.com/og/blog/en/prerendering-a-vite-spa.png", "tags": [ "seo", "vite", "prerender" ], "language": "en-US" }, { "id": "https://boraocaker.com/en/blog/markdown-blog-with-vite-glob", "url": "https://boraocaker.com/en/blog/markdown-blog-with-vite-glob", "title": "A markdown blog with no CMS — just import.meta.glob", "summary": "This blog has no database, no headless CMS, no content API. Posts are markdown files in a folder, pulled into the bundle at build time by one Vite feature. Here's the whole setup.", "content_text": "I write posts in my editor, commit them, and they're live. No CMS login, no content API to rate-limit me, nothing to migrate when the SaaS pivots. The posts are just markdown files:\n\n```\nsrc/content/blog/en/.md\nsrc/content/blog/tr/.md\n```\n\nThe entire loader is one Vite feature plus a tiny frontmatter parser.\n\n## import.meta.glob does the heavy lifting\n\nVite can eagerly import every file matching a glob, at build time, as a record of `path → contents`:\n\n```ts\nconst EN_FILES = import.meta.glob(\n \"../content/blog/en/*.md\",\n { eager: true, query: \"?raw\", import: \"default\" }\n) as Record;\n```\n\n`eager: true` means it's inlined into the bundle — no runtime `fetch`, no waterfall. `query: \"?raw\"` gives me the raw string instead of a transformed module. The path key (`../content/blog/en/hello.md`) is where I derive the slug and language.\n\n## Frontmatter without a dependency\n\nI didn't want `gray-matter` in the client bundle for what is, realistically, four field types. So I parse a YAML subset by hand — string, ISO date, boolean, and inline arrays:\n\n```ts\nif (trimmed === \"true\" || trimmed === \"false\") fm[key] = trimmed === \"true\";\nelse if (trimmed.startsWith(\"[\") && trimmed.endsWith(\"]\"))\n fm[key] = trimmed.slice(1, -1).split(\",\").map((s) => s.trim()).filter(Boolean);\nelse fm[key] = stripQuotes(trimmed);\n```\n\nThat's the whole parser. It handles `tags: [react, vite]`, `draft: true`, and quoted strings. If I ever need nested YAML I'll regret this — but I won't, because frontmatter shouldn't be nested.\n\n## Things you get almost for free\n\nOnce every post is an object in memory, the \"features\" are just array methods:\n\n- **Reading time** — `Math.ceil(words / 200)`, floored at 1 minute.\n- **Sorting** — newest first, honouring an optional `updated` field over `date` so a meaningfully edited post bubbles back up.\n- **Related posts** — score by shared tags (×2 each) and shared series (×5), sort, slice. ~15 lines.\n- **Prev / next** — find the slug's index in the sorted list, return neighbours.\n\nNo queries, no joins. It's all `Array.prototype`.\n\n## The translation fallback\n\nThe one bit of real logic: a Turkish post that hasn't been written yet should fall back to English, so the TR blog index is never half-empty.\n\n```ts\nconst trBySlug = new Map(TR_POSTS.map((p) => [p.slug, p]));\nconst merged = EN_POSTS.map((p) => trBySlug.get(p.slug) ?? p);\n```\n\nWrite the TR file when you have time; until then the EN version shows with a small \"not translated yet\" note. Partial translation is a valid state.\n\n> [!tip] Drafts in dev, hidden in prod\n> A `draft: true` frontmatter flag, gated on `import.meta.env.PROD`, lets me iterate on unpublished posts locally while keeping them out of the live build and the feeds.\n\n## When this breaks down\n\nThis is great up to maybe a few hundred posts — past that, `eager: true` inlining everything into the bundle starts to hurt, and you'd want lazy globs or a real content layer. For a personal blog measured in dozens of posts, the simplest thing that could possibly work *is* the right thing. No CMS is a feature.\n", "date_published": "2026-05-30T00:00:00.000Z", "date_modified": "2026-05-30T00:00:00.000Z", "image": "https://boraocaker.com/og/blog/en/markdown-blog-with-vite-glob.png", "tags": [ "vite", "markdown", "react" ], "language": "en-US" }, { "id": "https://boraocaker.com/en/blog/trimming-syntax-highlighter", "url": "https://boraocaker.com/en/blog/trimming-syntax-highlighter", "title": "The 700 KB I never shipped — trimming a syntax highlighter", "summary": "react-syntax-highlighter will happily bundle every Prism grammar it ships with. That's hundreds of kilobytes of languages I'll never use. Here's how I registered only the handful this blog needs.", "content_text": "Code blocks need highlighting. The obvious move is `react-syntax-highlighter`, import the `Prism` component, done. Except the default `Prism` import drags in *every* language grammar Prism ships — Verilog, Prolog, COBOL, the lot. That's the better part of 700 KB of grammars for a blog that writes TypeScript, a little CSS, and the occasional shell command.\n\n## Use the Light build, register by hand\n\nThe library ships a `PrismLight` (and `Light`) build that registers **nothing** by default. You opt into exactly the languages you use:\n\n```ts\nimport { PrismLight as SyntaxHighlighter } from \"react-syntax-highlighter\";\nimport tsx from \"react-syntax-highlighter/dist/esm/languages/prism/tsx\";\nimport bash from \"react-syntax-highlighter/dist/esm/languages/prism/bash\";\nimport css from \"react-syntax-highlighter/dist/esm/languages/prism/css\";\n\nSyntaxHighlighter.registerLanguage(\"tsx\", tsx);\nSyntaxHighlighter.registerLanguage(\"bash\", bash);\nSyntaxHighlighter.registerLanguage(\"css\", css);\n```\n\nEach grammar is a ~3–5 KB module. I register about a dozen — including the aliases (`sh` and `shell` both point at `bash`, `ts` and `typescript` at the same grammar) so fenced blocks tagged either way Just Work. Total cost: a few tens of KB instead of a few hundred.\n\n## Why aliases matter\n\nMarkdown authors are inconsistent — sometimes I write ` ```ts `, sometimes ` ```typescript `. Rather than normalise in the parser, I register both names against the same imported grammar:\n\n```ts\nSyntaxHighlighter.registerLanguage(\"ts\", typescript);\nSyntaxHighlighter.registerLanguage(\"typescript\", typescript);\nSyntaxHighlighter.registerLanguage(\"js\", javascript);\nSyntaxHighlighter.registerLanguage(\"javascript\", javascript);\n```\n\nCosts nothing extra — it's the same module reference — and saves me from \"why isn't this block highlighted\" later.\n\n## The theme is the other half\n\nA theme (I use `one-dark`) is just an object. Importing it from the `esm` path keeps it tree-shakeable:\n\n```ts\nimport oneDark from \"react-syntax-highlighter/dist/esm/styles/prism/one-dark\";\n```\n\nEverything from `dist/esm/...` so the bundler can actually shake what I don't reference. The CJS paths defeat that.\n\n> [!note] Measure, don't guess\n> I only caught the bloat because the bundle analyzer showed a single chunk ballooning. The default `Prism` import gives no warning — it just quietly ships a dictionary's worth of languages. `PrismLight` makes the cost opt-in and visible.\n\n## The wider lesson\n\nThis is the same lesson as lazy-loading a carousel or deferring a contact-form script: **the cheapest kilobyte is the one you never send.** A convenience import that bundles \"everything just in case\" is a tax every visitor pays for a feature almost none of them use. Read what your dependencies pull in. The Light/selective-registration pattern shows up all over the ecosystem — `lodash-es`, icon libraries, date locales — and it's almost always worth the three extra lines.\n", "date_published": "2026-05-29T00:00:00.000Z", "date_modified": "2026-05-29T00:00:00.000Z", "image": "https://boraocaker.com/og/blog/en/trimming-syntax-highlighter.png", "tags": [ "performance", "bundle", "react" ], "language": "en-US" }, { "id": "https://boraocaker.com/en/blog/hand-rolling-rss-and-json-feeds", "url": "https://boraocaker.com/en/blog/hand-rolling-rss-and-json-feeds", "title": "Hand-rolling RSS and JSON feeds at build time", "summary": "RSS isn't dead, it's just quiet. Adding a feed to this blog took one build script, no library, and about an hour of reading two specs. Here's what I learned writing RSS 2.0 and JSON Feed by hand.", "content_text": "Every blog should have a feed. RSS readers still exist, people genuinely use them, and a feed is the polite way to let someone follow you without an algorithm in the middle. The cost is almost nothing: one script that reads my markdown posts and writes two files.\n\nI write both — `rss.xml` (RSS 2.0, what most readers expect) and `feed.json` ([JSON Feed 1.1](https://www.jsonfeed.org/), nicer to generate and parse). Per language: `dist/rss.xml`, `dist/feed.json`, `dist/tr/rss.xml`, `dist/tr/feed.json`.\n\n## RSS 2.0 is just XML you concatenate\n\nThere's no magic. An item is a string template:\n\n```js\nconst items = posts.map((p) => ` \n ${escapeXml(p.fm.title)}\n ${url}\n ${url}\n ${rfc822(p.fm.date)}\n ${escapeXml(p.fm.description)}\n \n ${(p.fm.tags || []).map((t) => `${escapeXml(t)}`).join(\"\\n\")}\n`).join(\"\\n\");\n```\n\nTwo things bite you if you skip the spec:\n\n1. **`pubDate` must be RFC 822**, not ISO 8601. Luckily JavaScript's `Date.prototype.toUTCString()` produces exactly the right format, so the helper is a one-liner.\n2. **Escape everything.** A stray `&` or `<` in a title makes the whole feed invalid XML — readers reject it wholesale, not gracefully. A five-replace `escapeXml` covers `& < > \" '`.\n\nI also attach the post's OG image as an `` so readers that show thumbnails get the same card the social previews use.\n\n## JSON Feed is the easy one\n\nIf you've ever built an API response, you already know JSON Feed. It's an object you `JSON.stringify`:\n\n```js\n{\n version: \"https://jsonfeed.org/version/1.1\",\n title, home_page_url, feed_url, description,\n authors: [{ name, url }],\n items: posts.map((p) => ({\n id: url, url, title: p.fm.title,\n summary: p.fm.description,\n content_text: p.body,\n date_published: new Date(p.fm.date).toISOString(),\n tags: p.fm.tags || [],\n })),\n}\n```\n\nNo escaping to think about, dates are plain ISO, and `content_text` lets me ship the full post body for readers that want it. If I were only doing one feed, it'd be this one — but RSS still has the wider reader support, so I do both.\n\n## Sorting and drafts\n\nSame rules as the on-site list, because it reads the same files: newest first, `updated` beats `date`, and `draft: true` posts are filtered out so an unfinished draft never leaks into someone's reader.\n\n```js\n.filter((p) => !p.fm.draft)\n.sort((a, b) => ((a.fm.updated || a.fm.date) < (b.fm.updated || b.fm.date) ? 1 : -1));\n```\n\n> [!tip] Point your `` at the feed\n> A feed nobody can discover is useless. Add `` to your head so browser extensions and readers auto-detect it.\n\n## Why build-time, not a library\n\nI could have pulled in a feed-generator package. But the whole script is ~160 lines, has zero dependencies, and runs in the same post-build step as the prerender and OG generation. When the inputs are local markdown and the output is a static file, a library is just a layer of indirection between me and two specs I can read in an afternoon. Fewer dependencies, fewer surprises on the next `npm audit`.\n", "date_published": "2026-05-28T00:00:00.000Z", "date_modified": "2026-05-28T00:00:00.000Z", "image": "https://boraocaker.com/og/blog/en/hand-rolling-rss-and-json-feeds.png", "tags": [ "rss", "build", "seo" ], "language": "en-US" }, { "id": "https://boraocaker.com/en/blog/react-i18n-without-routing", "url": "https://boraocaker.com/en/blog/react-i18n-without-routing", "title": "Adding i18n to a React site without breaking the router", "summary": "How I added Turkish to my portfolio in an afternoon — react-i18next, a fixed top-left toggle, and zero new dependencies on the router.", "content_text": "A portfolio without language support is fine — until you start sending the link to a Turkish founder and realize they bounce off \"Marketing site.\" in 8 seconds.\n\nThis is the path I took to add Turkish, with the constraints I refused to break.\n\n## The constraints\n\n1. **No new router.** The site uses a hand-rolled enum-based router (`\"home\" | \"projects\" | \"about\"`). I wasn't going to drag in React Router just for `i18n`.\n2. **No SEO regression.** ``, hreflang, and the rendered text all had to stay in sync.\n3. **No flash of English** when a Turkish visitor lands. Detection on first load, cached for the next visit.\n\n## The stack I picked\n\n- **`react-i18next`** — battle-tested, tiny runtime once you exclude the loader bundles.\n- **`i18next-browser-languagedetector`** — reads `localStorage` first, then `navigator.language`.\n- **Two JSON files**, one per language, organized by section (`hero`, `services`, `process`, …).\n\nThat's it. No CMS, no extraction script. The build pulls both JSON files into the bundle (~6 KB gzipped combined).\n\n## The toggle nobody can miss but everyone can ignore\n\nI started with a top-right toggle. Bad call: on the Projects page there was already a top-right meta badge (\"Infinity canvas · 34 projects · ∞\"), and on About there was \"About · Bora Ocaker.\" They collided on mobile.\n\nMoved it top-left, offset 72px down to clear the back-button row. Now it's a quiet `EN / TR` pill in monospace — the kind of UI element you only see once you're looking for it.\n\n## What I learned\n\n**`returnObjects: true` is the trick.** For arrays of strings (the FAQ list, the toolkit pills, the \"facts\" section), don't write one key per item. Write the array as JSON and pull it out as a typed list:\n\n```ts\nconst facts = t(\"about.panel4.facts\", { returnObjects: true }) as string[];\n```\n\n**Don't translate everything.** Reference site titles (\"Linear\", \"Vercel\", \"Stripe\") stay in English. Brand names stay in English. The hero's personal name stays in English. Translate the *prose*, leave the *proper nouns* alone.\n\n**Test the longest string.** \"Front-End Specialist\" is 21 chars. \"Front-End Uzmanı\" is 16 chars. Lucky. But \"Have an idea? Let's build it.\" becomes \"Bir fikrin mi var? Hadi inşa edelim.\" — 36 chars vs 28. If your hero uses `whiteSpace: nowrap`, this *will* break on a small phone. Audit every `nowrap` you have.\n\n## The part I'd do differently\n\nI shipped with **localStorage-only** language preference, not URL-based (`/tr/`, `/en/`). A shared link doesn't carry the language. For a portfolio it's fine. For a marketing site you actually want indexed in two languages, do URL routing from day one.\n\nIf you're starting fresh, this is the order I'd recommend:\n\n1. Set up `react-i18next` with two empty JSON files.\n2. Add the toggle and confirm it switches on a single test string.\n3. *Only then* start moving real strings into the JSONs, section by section.\n\nResist the urge to wrap every string at once. You will get tired, miss strings, and the diff will be unreviewable.\n", "date_published": "2026-05-26T00:00:00.000Z", "date_modified": "2026-05-26T00:00:00.000Z", "image": "https://boraocaker.com/og/blog/en/react-i18n-without-routing.png", "tags": [ "react", "i18n", "vite" ], "language": "en-US" }, { "id": "https://boraocaker.com/en/blog/hero-lcp-fetchpriority", "url": "https://boraocaker.com/en/blog/hero-lcp-fetchpriority", "title": "One attribute that cut my hero LCP in half", "summary": "A background-image div is invisible to the preload scanner. An with fetchpriority=\"high\" isn't. Here's what changed when I made the swap.", "content_text": "My Cloudflare Analytics had been telling me a quiet story for weeks:\n\n- **LCP P75: 2,200 ms** — borderline \"Needs Improvement\"\n- **LCP P90: 4,604 ms** — somebody on a slow connection was waiting almost five seconds for the hero\n\nThe hero is one image. An 87 KB WebP. There is no reason it should take that long.\n\n## The mistake\n\nLike a lot of designers-turned-developers, I had been writing this for years:\n\n```tsx\n
\n```\n\nLooks fine. Performs fine on my machine. Quietly miserable on a real phone.\n\n## Why a `
` background is slow\n\nThe browser has a **preload scanner** that runs before HTML parsing finishes. It walks the raw HTML looking for assets it can start fetching immediately — images, fonts, scripts.\n\nThe preload scanner can see:\n- ``\n- ``\n- ``\n\nThe preload scanner **cannot** see:\n- CSS `background-image: url(...)` — it has to parse CSS first\n- Inline-style `backgroundImage` — same problem, deferred\n\nSo my hero image waited for: HTML parse → React mount → component render → style application → *now* fetch the image. On a 3G connection that chain is brutal.\n\n## The fix\n\n```tsx\n
\n \n
\n```\n\nThree things happening:\n\n1. **`` is visible to the preload scanner.** Fetch starts within the first 50ms of the response.\n2. **`fetchpriority=\"high\"`** tells the browser this is the LCP candidate — push it ahead of below-fold images and non-critical scripts.\n3. **`decoding=\"async\"`** keeps decode off the main thread once bytes arrive.\n\n`alt=\"\"` + `aria-hidden=\"true\"` keeps it semantically a background — screen readers ignore it, exactly as they would a CSS background.\n\n## What it cost\n\nZero. No library, no build step, no React refactor. One JSX swap.\n\n## What I'm watching for\n\nCloudflare Web Analytics aggregates over 24 hours, so I'll know the real-world delta tomorrow. My local Lighthouse went from LCP 1.4s → 0.9s. The interesting number is the **P90** — that's where the change matters most, because it tells you what your worst real users feel.\n\n## The broader lesson\n\nTreat **background-image as a design tool, not a delivery mechanism.** If a pixel is decorative and below the fold, fine — use CSS background. If a pixel is the first thing the user is meant to see, ship it as `` and let the browser do its job.\n", "date_published": "2026-05-24T00:00:00.000Z", "date_modified": "2026-05-24T00:00:00.000Z", "image": "https://boraocaker.com/og/blog/en/hero-lcp-fetchpriority.png", "tags": [ "performance", "lighthouse", "react" ], "language": "en-US" }, { "id": "https://boraocaker.com/en/blog/lazy-third-party-scripts", "url": "https://boraocaker.com/en/blog/lazy-third-party-scripts", "title": "The 80 KB I removed from my critical path with one observer", "summary": "hCaptcha and Web3Forms only matter when someone actually submits the contact form. Here's how I delayed both until the form was on screen — and what that did to my Lighthouse score.", "content_text": "My contact form sits at the bottom of the page. Maybe 1 in 20 visitors scrolls to it. The other 19 never touch it.\n\nYet on every single page load, every visitor — including the ones who close the tab after 3 seconds — was downloading and parsing:\n\n- `js.hcaptcha.com/1/api.js` (~50 KB)\n- `web3forms.com/client/script.js` (~30 KB)\n\nThat's 80 KB of JavaScript blocking nothing in particular, but blocking the main thread, blocking the connection budget, and getting in the way of LCP.\n\n## The lazy approach\n\nTwo things needed to happen:\n\n1. **Remove the scripts from `index.html`.** They no longer load on first paint.\n2. **Load them only when the contact form is about to be visible.** `IntersectionObserver` is the cleanest primitive for this — it's free, native, and well-supported.\n\nThe trick is the second part. You can't just load on `useEffect`, because the form is at the bottom of the page; loading on mount defeats the whole point. You also can't load on focus, because hCaptcha needs to be parsed and initialized before the user can interact.\n\nThe sweet spot is loading when the form enters the viewport, with a generous `rootMargin` so the scripts arrive a half-screen before the form does.\n\n```ts\nuseEffect(() => {\n const el = wrapperRef.current;\n if (!el) return;\n const io = new IntersectionObserver((entries) => {\n if (entries.some((e) => e.isIntersecting)) {\n loadScript(\"https://js.hcaptcha.com/1/api.js\");\n loadScript(\"https://web3forms.com/client/script.js\");\n io.disconnect(); // one-shot — once they're in, leave them in\n }\n }, { rootMargin: \"200px\" });\n io.observe(el);\n return () => io.disconnect();\n}, []);\n```\n\n`loadScript` is a four-line helper that appends a `