Forem: hieu.dev

Next.js Static Sites and SEO: What I Learned Building Two Tools from Zero to Google Page 1

hieu.dev — Tue, 19 May 2026 10:00:00 +0000

I built two free browser tools — compressimg.pro (image compressor) and click-thumb.com (thumbnail maker) — and got both ranking on Google within weeks using Next.js static export. Here's the exact SEO setup I used.

Why static export?

Next.js output: 'export' generates a fully static site with no server-side rendering. For tool sites that don't need personalization or real-time data, this is the best SEO choice:

Fastest possible LCP — HTML is pre-rendered, no server wait
Free hosting on Vercel — static assets served from CDN edge nodes
No hydration mismatch errors — pure HTML from the start

// next.config.mjs
const nextConfig = {
  output: 'export',
  compress: true,
  trailingSlash: true, // consistent canonical URLs
  images: { unoptimized: true }, // required for static export
}

trailingSlash: true is important — without it, Next.js generates both /page and /page/ depending on how you link internally. Google treats these as separate URLs and splits impression data between them.

Metadata API — the right way

Next.js 14 Metadata API is much cleaner than manually placing <meta> tags. The key fields that actually matter for SEO:

// app/layout.tsx — site-wide defaults
export const metadata: Metadata = {
  metadataBase: new URL('https://compressimg.pro'),
  title: {
    default: 'Compress Image Online Free | CompressImg',
    template: '%s | CompressImg', // appended to every page title
  },
  robots: {
    index: true,
    follow: true,
    'max-snippet': -1,
    'max-image-preview': 'large',
  },
}

// app/compress-image/layout.tsx — page-specific
export const metadata: Metadata = {
  title: 'Compress Image Online Free – Reduce JPG, PNG, WebP Size',
  description:
    'Free online image compressor. Reduce image file size up to 90% without losing quality.',
  alternates: {
    canonical: 'https://compressimg.pro/compress-image/',
  },
  openGraph: {
    type: 'website',
    url: 'https://compressimg.pro/compress-image/',
    images: [{ url: '/og-image.png', width: 1200, height: 630 }],
  },
}

metadataBase in the root layout lets you use relative image URLs in child layouts — Next.js resolves them to absolute URLs automatically.

Always use a layout.tsx per route for metadata, not page.tsx. The layout approach keeps metadata co-located with the route and makes it easy to add JSON-LD in the same file.

Canonical URLs — the one thing you can't skip

Every page needs a canonical tag. Without it, if Google indexes both https://example.com/page and https://example.com/page/, your impressions and link equity get split.

alternates: {
  canonical: 'https://compressimg.pro/compress-image/',
}

With trailingSlash: true in next.config, Vercel auto-redirects the non-slash version to the slash version. The canonical confirms which URL is authoritative.

JSON-LD structured data

Structured data is the highest-ROI SEO investment for tool sites. Three schemas I use on every page:

WebApplication — tells Google this is a free tool:

{
  "@type": "WebApplication",
  "name": "CompressImg — Free Online Image Compressor",
  "applicationCategory": "MultimediaApplication",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
}

FAQPage — targets featured snippet positions:

{
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Are my images uploaded to a server?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. All compression happens 100% in your browser. Your images never leave your device."
      }
    }
  ]
}

BreadcrumbList — improves how your URL appears in search results:

{
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://compressimg.pro" },
    { "@type": "ListItem", "position": 2, "name": "Compress Image", "item": "https://compressimg.pro/compress-image/" }
  ]
}

Render all three as a single <script type="application/ld+json"> in the layout:

export default function Layout({ children }: { children: React.ReactNode }) {
  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      {children}
    </>
  )
}

The script loading mistake that killed LCP

My first deployment had LCP of 7.1s on mobile 3G. Lighthouse pointed to GA4 and AdSense blocking the critical rendering path.

The fix was a single word change:

// Before: runs when page becomes interactive — competes with LCP paint
<Script src="...gtag/js" strategy="afterInteractive" />

// After: runs only when browser is idle — LCP drops to 2.0s
<Script src="...gtag/js" strategy="lazyOnload" />

afterInteractive sounds safe but it fires during the same period the browser is trying to paint your LCP element. lazyOnload defers to genuine idle time. For analytics and ads, there's no reason to load earlier than idle.

robots.txt and sitemap

For a static site, these are static files in /public:

# public/robots.txt
User-agent: *
Allow: /

Sitemap: https://compressimg.pro/sitemap.xml

For large sites (65+ pages), split into a sitemap index:

<!-- public/sitemap.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://compressimg.pro/sitemap-0.xml</loc>
  </sitemap>
</sitemapindex>

Submit sitemap.xml to Google Search Console immediately after deploy. Google will crawl all listed URLs within a few days.

Font loading — `display: optional` vs `swap`

const inter = Inter({
  subsets: ['latin'],
  variable: '--font-inter',
  display: 'optional', // not 'swap'
})

display: swap causes a FOUT (flash of unstyled text) — the browser renders with a fallback font, then swaps to Inter once loaded. This contributes to CLS.

display: optional tells the browser to use Inter only if it loads before the first paint. If it doesn't, use the system font. No FOUT, no CLS contribution. For body text at normal sizes, users rarely notice the difference.

What actually moves rankings

After 6 weeks:

compressimg.pro: 157 keywords ranking, 6 clicks/week, avg position 37
click-thumb.com: 40+ pages indexed, first clicks appearing

The technical SEO setup gets you indexed fast and prevents common penalties. But positions 1–10 require content depth (1,000+ words per page, 8+ FAQs) and inbound links from other domains.

The structured data is worth doing from day 1 — it's a one-time setup that Google can use for featured snippets on any question-format query in your niche.

Checklist

✅ output: 'export' in next.config
✅ trailingSlash: true
✅ canonical on every page
✅ metadataBase in root layout
✅ JSON-LD: WebApplication + FAQPage + BreadcrumbList
✅ Script strategy: lazyOnload for analytics/ads
✅ robots.txt with Sitemap URL
✅ sitemap.xml submitted to Search Console
✅ Inter font with display: optional

Full examples live at compressimg.pro and click-thumb.com.

Building a Browser-Based Thumbnail Maker with Fabric.js and Next.js

hieu.dev — Sat, 16 May 2026 10:00:00 +0000

I built click-thumb.com — a free YouTube thumbnail maker that runs entirely in the browser. No backend, no uploads, no account. Here's the technical breakdown of the interesting problems I ran into using Fabric.js inside a Next.js static site.

Why Fabric.js over raw Canvas API?

The raw Canvas API is great for rendering but painful for interactivity — you have to manually implement hit testing, object selection, drag handles, and text editing. Fabric.js gives you all of that out of the box.

For a thumbnail maker, the key Fabric.js features I needed:

IText — inline text editing with double-click
object:moving events for clamped dragging
toDataURL() with a multiplier for full-resolution export
canvas.sendToBack() for layer ordering

The SSR problem

Fabric.js uses document and window directly — it breaks Next.js server-side rendering immediately. The fix is next/dynamic with ssr: false:

// CanvasToolClient.tsx
const CanvasEditor = dynamic(() => import('./CanvasEditor'), {
  ssr: false,
  loading: () => (
    <div className="w-full h-64 bg-surface rounded-xl animate-pulse" />
  ),
})

The loading fallback prevents layout shift while Fabric.js loads. Without it you get a blank space that jumps to the canvas size — a visible CLS hit.

The scaling challenge

YouTube thumbnails are 1280×720px. Rendering a canvas that large directly would overflow on any mobile screen. The solution: render at full resolution internally, but display at a smaller size using CSS transform: scale().

// CanvasEditor.tsx
const { w: displayW, h: displayH } = getDisplayDimensions(platform)
const scale = displayW / platform.width // e.g. 640/1280 = 0.5

// Canvas renders at full 1280×720
const canvas = new fabric.Canvas(canvasRef.current, {
  width: displayW,   // display width (e.g. 640px)
  height: displayH,  // display height (e.g. 360px)
})

// CSS scales the wrapper to fit screen
<div style={{
  transformOrigin: 'top left',
  transform: `scale(${cssScale})`,
}}>
  <canvas ref={canvasRef} />
</div>

All text positions and font sizes in templates are stored at full resolution, then multiplied by scale when applied to the canvas. This keeps templates resolution-independent.

Exporting at full resolution

This tripped me up initially. canvas.toDataURL() by default exports at the display size, not the full 1280×720px. The fix is the multiplier parameter:

const multiplier = platform.width / displayW // e.g. 1280/640 = 2

const dataUrl = canvas.toDataURL({
  format: 'jpeg',
  quality: 0.92,
  multiplier, // scales up to full resolution on export
})

// Convert dataURL to Blob for download
const blob = await fetch(dataUrl).then((r) => r.blob())

The fetch(dataUrl).then(r => r.blob()) pattern is a clean way to convert a data URL to a Blob without manual base64 parsing.

Constraining drag to canvas bounds

By default, Fabric.js lets users drag objects completely off the canvas edge. For a thumbnail tool, that's a bad experience — text disappearing off-screen is confusing. I added clamping in object:moving:

canvas.on('object:moving', (e) => {
  const obj = e.target
  if (obj.type === 'i-text' || obj.type === 'text') {
    const hw = obj.getScaledWidth() / 2
    const hh = obj.getScaledHeight() / 2
    obj.left = Math.max(hw, Math.min(displayW - hw, obj.left))
    obj.top = Math.max(hh, Math.min(displayH - hh, obj.top))
  }

  if (obj.type === 'image') {
    // Background image: clamp so no black edges show
    const sw = obj.getScaledWidth()
    const sh = obj.getScaledHeight()
    obj.left = Math.max(displayW - sw, Math.min(0, obj.left))
    obj.top = Math.max(displayH - sh, Math.min(0, obj.top))
  }
})

Text is clamped by its own half-width/height so it stays fully visible. Background images are clamped inversely — they must always cover the canvas edges so no black border shows.

The black border bug from loadFromJSON

Early on, I used canvas.loadFromJSON() to reset templates. This caused a visible black border flash on every reset. After debugging, I found that loadFromJSON briefly clears the canvas and repaints — and during that repaint frame, the background is black.

The fix: instead of rebuilding the canvas on reset, directly mutate the existing objects' properties:

const handleReset = () => {
  const textObjs = canvas.getObjects()
    .filter(obj => obj.type === 'i-text' || obj.type === 'text')

  template.texts.forEach((preset, i) => {
    const obj = textObjs[i]
    if (!obj) return
    obj.set({
      text: preset.text,
      left: preset.left * scale,
      top: preset.top * scale,
    })
    obj.setCoords() // required after .set() for hit testing to update
  })

  canvas.renderAll()
}

No flash, no repaint cycle, just a clean synchronous update.

Ctrl+Z without an undo stack

Full undo/redo is complex to implement with Fabric.js. For this tool, the main reset use case is "I messed up the layout, go back to default." So instead of tracking state history, I map Ctrl+Z directly to the template reset:

useEffect(() => {
  const handler = (e: KeyboardEvent) => {
    if ((e.ctrlKey || e.metaKey) && e.key === 'z' && !e.shiftKey) {
      e.preventDefault()
      handleReset()
    }
  }
  window.addEventListener('keydown', handler)
  return () => window.removeEventListener('keydown', handler)
}, [handleReset])

This covers 95% of the actual undo use cases without the complexity of a full history stack.

Dynamic import of Fabric inside the effect

Fabric.js is ~300KB gzipped — too large to block initial page load. Even with ssr: false, if you import it at the top of the file it gets bundled with the component and loaded immediately when the component mounts.

Instead, import it lazily inside the useEffect:

useEffect(() => {
  let mounted = true

  ;(async () => {
    const fabric = (await import('fabric')).fabric
    if (!mounted || !canvasRef.current) return

    const canvas = new fabric.Canvas(canvasRef.current, { ... })
    // ...
  })()

  return () => {
    mounted = false
    if (fabricRef.current) {
      fabricRef.current.dispose() // important: releases canvas memory
      fabricRef.current = null
    }
  }
}, [platform.id])

The mounted flag prevents state updates if the component unmounts before the async import resolves. The dispose() call in cleanup releases Fabric's internal canvas resources — without it, switching between tools leaks memory.

Result

The tool loads fast, exports at correct resolution, and handles the edge cases that trip up most canvas implementations. Try it at click-thumb.com — currently supports YouTube, gaming (CS2, Minecraft, Fortnite, Roblox), TikTok, Instagram, and more.

Happy to answer questions about any of the implementation details in the comments.

How I Built a Browser-Based Image Compressor with Next.js (No Server Required)

hieu.dev — Wed, 13 May 2026 16:43:35 +0000

I wanted to build a free image compressor — no uploads to a server, no account required, just drop an image and get a compressed file back instantly. Here's what I learned building compressimg.pro.

Why browser-based?

Most image compression tools send your file to a server, compress it there, and send it back. That means:

Your image leaves your device (privacy concern)
You need a backend to maintain
Latency on every compression

The browser can handle this entirely client-side using the Canvas API and Web Workers. No server, no cost, no privacy issue.

The stack

Next.js 14 with output: 'export' (static site — deployed free on Vercel)
browser-image-compression — handles the heavy lifting
TypeScript throughout

The static export is key. Since there's no server-side logic, the entire site builds to static HTML/JS and deploys in seconds.

// next.config.mjs
const nextConfig = {
  output: 'export',
  compress: true,
  trailingSlash: true,
}

The compression logic

The core is surprisingly simple:

// lib/compress.ts
export async function compressImage(
  file: File,
  options: CompressOptions
): Promise<CompressResult> {
  // Dynamic import — keeps initial bundle small
  const { default: imageCompression } = await import('browser-image-compression')

  const compressed = await imageCompression(file, {
    maxWidthOrHeight: options.maxDimensionPx ?? 1920,
    useWebWorker: true,           // keeps main thread unblocked
    initialQuality: options.quality / 100,
    fileType: file.type,
    alwaysKeepResolution: true,
  })

  return {
    blob: compressed,
    originalSize: file.size,
    compressedSize: compressed.size,
    previewUrl: URL.createObjectURL(compressed),
    format: file.type.split('/')[1] ?? 'jpeg',
  }
}

Two things worth noting:

useWebWorker: true — This is the most important flag. Without it, compression runs on the main thread and freezes the UI for 1–3 seconds on large files. With it, the browser spawns a worker thread and the UI stays responsive throughout.

Dynamic import — browser-image-compression is ~50KB gzipped. Importing it at the top of the file adds it to the initial bundle and hurts LCP. Importing it inside the handler means it only loads when the user actually selects a file.

The upload UX — state machine approach

The upload box has 5 states: idle, dragging, processing, done, error. Defining these upfront made the component much cleaner than the typical boolean-flag soup:

type UploadState = 'idle' | 'dragging' | 'processing' | 'done' | 'error'

The component handles three input methods — click, drag & drop, and Ctrl+V paste:

const handlePaste = useCallback((e: ClipboardEvent<HTMLDivElement>) => {
  const item = Array.from(e.clipboardData.items)
    .find((i) => i.type.startsWith('image/'))
  if (!item) return
  const file = item.getAsFile()
  if (file) validateAndSelect(file)
}, [validateAndSelect])

Paste support is underrated — power users (designers, developers) paste screenshots constantly. Adding it took 10 lines and made the tool noticeably more useful.

The performance mistake that cost me LCP 7.1s → 2.0s

My first deploy had LCP of 7.1s on mobile. After running Lighthouse, the culprit was Google Analytics and AdSense loaded with strategy="afterInteractive".

Switching both to strategy="lazyOnload" dropped LCP to 2.0s instantly:

// Before — blocks LCP
<Script src="https://www.googletagmanager.com/gtag/js"
  strategy="afterInteractive" />

// After — deferred until idle
<Script src="https://www.googletagmanager.com/gtag/js"
  strategy="lazyOnload" />

The lesson: any third-party script with afterInteractive runs as soon as the page is interactive — which is right when the browser is trying to paint your LCP element. lazyOnload waits until the browser is genuinely idle.

Blob URL memory management

One thing that bites people: URL.createObjectURL() creates a reference that persists in memory until you explicitly release it. After the user downloads their file:

export function triggerDownload(blob: Blob, filename: string) {
  const url = URL.createObjectURL(blob)
  const a = document.createElement('a')
  a.href = url
  a.download = filename
  a.click()
  // Release after 1s to ensure download started
  setTimeout(() => URL.revokeObjectURL(url), 1000)
}

Without revokeObjectURL, compressing many files in one session leaks memory progressively.

What I'd do differently

HEIC support is tricky. iOS devices often produce .heic files that browser-image-compression can't handle natively. I ended up adding a separate HEIC-to-JPEG conversion step before compression, which added complexity I didn't expect.

Target file size is hard. Users often want "compress to under 100KB" rather than "compress at quality 80." Hitting a target size requires binary search over the quality parameter — doable, but not something the library handles out of the box.

Try it

The full tool is live at compressimg.pro — free, no account, no upload limits. Supports JPG, PNG, WebP, HEIC, and GIF.

If you're building something similar, the browser-image-compression library does 90% of the hard work. The remaining 10% is UX — handling all the edge cases around file validation, state management, and performance.

Happy to answer questions in the comments.

How I built a privacy-first image compressor that runs entirely in the browser

hieu.dev — Tue, 28 Apr 2026 05:45:33 +0000

Most online image compressors have one thing in common: your files go to their server. You upload a private photo, it travels across the internet, gets processed on someone else's machine, and comes back. That always felt wrong to me.

So I built CompressImg — an image compressor that does everything in your browser. Your files never leave your device.

Here's how it works under the hood.

The core: browser-image-compression + Web Worker

The heavy lifting is done by the browser-image-compression library, but the key is where it runs:

// compress.ts
export async function compressImage(file, options) {
  const { default: imageCompression } = await import('browser-image-compression')

  return imageCompression(file, {
    maxSizeMB: undefined,        // don't limit by size, use quality instead
    initialQuality: options.quality / 100,
    alwaysKeepResolution: true,  // never upscale
    maxWidthOrHeight: 1920,      // cap at screen resolution
    useWebWorker: true,          // off main thread
  })
}

Two things matter here:

Dynamic import — browser-image-compression is only loaded when the user actually compresses an image. It's not in the initial bundle.
useWebWorker: true — compression runs off the main thread. The UI stays responsive even for large files.

The stack

Next.js 14 with output: 'export' — generates a pure static site. No server, no API routes, nothing to scale.
Vercel — serves the static files from a global CDN. Handles any amount of concurrent users automatically.
Cloudflare — DNS only (gray cloud). Vercel manages SSL.

The PageSpeed problem

My first PageSpeed score on mobile was LCP 7.1s. Way off the < 2.5s target.

The culprit turned out to be three things stacking up:

1. Font loading

// Before
const inter = Inter({ subsets: ['latin'], display: 'swap' })

// After
const inter = Inter({ subsets: ['latin'], display: 'optional' })

With display: swap, the browser renders text with a fallback font, then swaps to Inter when it loads. On mobile simulation (slow 4G), Inter was loading at ~5s — and LCP was measured at the swap moment.

With display: optional, if the font isn't immediately available, the browser uses the system font and never swaps. LCP is measured right away.

2. Third-party scripts competing for bandwidth

AdSense (231 KiB) and GA4 (140 KiB) were loading with afterInteractive, which fires right after hydration. On mobile, this competed with the LCP element for bandwidth.

// Before
strategy="afterInteractive"

// After
strategy="lazyOnload"

lazyOnload defers until the browser is truly idle — after LCP has already painted.

3. ContentSection as a client component

I had added 'use client' to the ContentSection (1000+ words of SEO text) to handle the FAQ accordion. This caused all that static text to be bundled as JavaScript instead of static HTML.

Fix: extract the interactive part (accordion toggle) into its own tiny client component, let the rest be server-rendered HTML.

// FAQItem.tsx — only this needs 'use client'
'use client'
export default function FAQItem({ question, answer }) {
  const [open, setOpen] = useState(false)
  // ...
}

After all three fixes: LCP dropped from 7.1s to 2.0s.

Privacy by design

The architecture makes privacy the default, not a feature:

Static export = no server to log requests
Compression via Canvas API = no data transmission
No cookies, no session storage, no user tracking beyond GA4 page views
ads.txt published for AdSense transparency

What's next

The tool is live at compressimg.pro. Next steps are adding more tools (resize, format conversion) once the SEO for image compression establishes a baseline.

If you're building something similar, the main lesson: measure PageSpeed early and often. The LCP issue would have been invisible without it.

Built with Next.js, deployed on Vercel. Questions welcome in the comments.

It's been about 3 weeks since I published this post. Here's what I learned.

The formats people actually need

I thought JPG and PNG would cover 95% of use cases. I was wrong.

The first thing users asked about was HEIC — iPhone photos that Windows
can't open natively. Added HEIC to JPG conversion
using heic2any with a dynamic import so it doesn't bloat the main bundle:


ts
const heic2any = await import('heic2any')
const blob = await heic2any.default({ blob: file, toType: 'image/jpeg' })
Then came GIF. Animated GIF compression is a completely different problem —
you can't just run it through Canvas. I ended up with gifuct-js to decode
frames and gif.js with a Web Worker to re-encode. The worker file has to
live in /public/gif.worker.js — took me an embarrassing amount of time to
figure that out.

Also added TIFF (via utif), AVIF (native Canvas in Chrome), and BMP.

The SEO side
The compression logic was the easy part. The harder problem: how do you get
Google to care about a new free tool?

I ended up building 72 static pages with Next.js output: 'export' — one
for each format, platform, and use case. Pages like
compress image to 100KB
target very specific long-tail queries ("compress photo for government form",
"image under 100kb for email attachment") that have real search volume and
almost no competition from the big tools.

Three weeks in: 534 impressions on Google Search Console, pages ranking
between position 8–15 for terms like "does Microsoft Teams compress images"
and "compress image for LinkedIn". No clicks yet — that comes when you break
into the top 5. But the trajectory is there.

The key technical decision that made this work: every page is fully static
(SSG, no SSR), with its own layout.tsx containing JSON-LD structured data
(WebApplication + FAQPage schema). Google indexes these instantly compared
to client-rendered pages.

What's next
The tool is live at compressimg.pro — still
100% free, no account, no uploads to any server.

If you're building something similar, the biggest lesson: pick client-side
processing from day one. Not just for privacy — it makes the whole
architecture simpler. No server to maintain, no storage costs, no GDPR
headaches, free hosting on Vercel forever.

Happy to answer questions about any of the implementation details below.


---

Forem: hieu.dev

Next.js Static Sites and SEO: What I Learned Building Two Tools from Zero to Google Page 1

Why static export?

Metadata API — the right way

Canonical URLs — the one thing you can't skip

JSON-LD structured data

The script loading mistake that killed LCP

robots.txt and sitemap

Font loading — display: optional vs swap

What actually moves rankings

Checklist

Building a Browser-Based Thumbnail Maker with Fabric.js and Next.js

Why Fabric.js over raw Canvas API?

The SSR problem

The scaling challenge

Exporting at full resolution

Constraining drag to canvas bounds

The black border bug from loadFromJSON

Ctrl+Z without an undo stack

Dynamic import of Fabric inside the effect

Result

How I Built a Browser-Based Image Compressor with Next.js (No Server Required)

Why browser-based?

The stack

The compression logic

The upload UX — state machine approach

The performance mistake that cost me LCP 7.1s → 2.0s

Blob URL memory management

What I'd do differently

Try it

How I built a privacy-first image compressor that runs entirely in the browser

The core: browser-image-compression + Web Worker

The stack

The PageSpeed problem

Privacy by design

What's next

The formats people actually need

Font loading — `display: optional` vs `swap`