DEV Community: Chilam Chan

前端性能优化:15个工具页面首屏加载<2秒实践

Chilam Chan — Tue, 29 Sep 2026 01:12:51 +0000

Frontend Performance Optimization: Getting 15 Tool Pages to Load in <2 Seconds

Hey folks! I’m the solo dev behind TinyUtils – a suite of 15 free, no-signup, 100% in-browser utilities (think JSON formatters, password generators, unit converters). Since users come for quick tasks, performance isn’t just a nice-to-have – it’s the product. A slow load means they’ll bounce before even using the tool.

A few months back, my Lighthouse scores were… rough. Initial load times on 4G hovered around 4-5 seconds, and that was with only 10 tools. Adding 5 more? I knew I needed to get serious about optimization. Today, all 15 tools load in under 2 seconds on 4G, and I want to break down how I did it – no fluff, just concrete steps that worked for my stack (React + Vite, static hosting).

1. Code Splitting: Stop Shipping All 15 Tools at Once

The biggest mistake? Bundling all tool logic into a single main.js. Each tool has unique dependencies (e.g., date-fns for the timestamp converter, marked for the markdown previewer) – why make users download code for tools they’re not using?

Fix: Dynamic imports with React.lazy.

I refactored the app to load tool components only when needed. The main page (tool selector) is lightweight, and tools are fetched on demand. Here’s a simplified snippet:

// Before: Importing all tools upfront
import JSONFormatter from './tools/JSONFormatter';
import PasswordGenerator from './tools/PasswordGenerator';
// ... 13 more imports

// After: Lazy-loading tools
const JSONFormatter = React.lazy(() => import('./tools/JSONFormatter'));
const PasswordGenerator = React.lazy(() => import('./tools/PasswordGenerator'));

// In the router (React Router)
<Route 
  path="/json-formatter" 
  element={
    <Suspense fallback={<LoadingSpinner />}>
      <JSONFormatter />
    </Suspense>
  } 
/>

Result: Initial bundle size dropped from ~800KB to ~220KB (unminified). No more waiting for unused code!

2. Lazy-Load Non-Critical UI (Even the "Small" Stuff)

Not all content on a tool page is critical. Things like help text, examples, or secondary features can wait until the user scrolls near them.

Fix: Intersection Observer for non-essential elements.

For example, the "Usage Tips" section at the bottom of each tool page? I wrap it in a component that only renders when it’s 200px from the viewport:

function LazyLoad({ children }) {
  const [isVisible, setIsVisible] = useState(false);
  const ref = useRef();

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => setIsVisible(entry.isIntersecting),
      { rootMargin: '200px' } // Load 200px before it's visible
    );
    if (ref.current) observer.observe(ref.current);
    return () => observer.disconnect();
  }, []);

  return isVisible ? <div ref={ref}>{children}</div> : null;
}

// Usage in a tool page:
<LazyLoad>
  <div className="usage-tips">
    <h3>Pro Tips</h3>
    {/* ... */}
  </div>
</LazyLoad>

This kept initial render times snappy – the browser isn’t bogged down rendering offscreen content.

3. Image Optimization: Every KB Counts

TinyUtils uses icons (for tool categories) and a few screenshots (e.g., "how to use" examples). Even small images add up if unoptimized.

Fixes:

WebP/AVIF over PNG/JPG: Converted all icons to WebP (using Squoosh) – average size reduction of ~60% (e.g., a 40KB PNG icon became 15KB WebP).
Responsive images with srcset: For screenshots, served smaller versions to mobile users:

  <img 
    src="/screenshots/json-formatter-sm.webp" 
    srcset="/screenshots/json-formatter-sm.webp 400w, /screenshots/json-formatter-lg.webp 800w" 
    alt="JSON Formatter example"
  />

SVG for simple icons: Replaced some raster icons with inline SVGs (no network request, and infinitely scalable).

4. Trim Dependencies: Less is More

Third-party libraries are convenient, but they’re often bloated with features I don’t need. I audited package.json and axed bloat:

Replaced moment.js with date-fns: moment is ~240KB minified; date-fns is tree-shakable, so I only imported the 2-3 functions I needed (total ~10KB).
Ditched lodash for native methods: _.debounce? Replaced with a 10-line custom debounce function. _.cloneDeep? Used JSON.parse(JSON.stringify()) for simple objects (good enough for my use case).
Inlined small utilities: Instead of installing a library for "slugify" or "capitalize", wrote 2-line helpers.

Result: Bundle size dropped another ~150KB.

5. Vite Build Optimizations

I switched from Create React App to Vite early on, but I wasn’t leveraging its full power. Tweaking the Vite config squeezed out more gains:

// vite.config.js
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        // Split chunks for shared code (e.g., React, common utilities)
        manualChunks: {
          react: ['react', 'react-dom'],
          utils: ['date-fns', 'marked'] // Shared deps across tools
        }
      }
    },
    // Enable brotli compression (smaller than gzip)
    assetsDir: 'assets',
    compress: true
  },
  plugins: [
    // Auto-optimize images during build
    viteImagemin({
      gifsicle: { optimizationLevel: 7 },
      webp: { quality: 80 }
    })
  ]
});

Vite’s esbuild-based minification and tree-shaking also helped – my final JS/CSS assets are minified and compressed (brotli), so even the 220KB initial bundle becomes ~60KB over the wire.

The Result: <2s Loads (Finally!)

After these changes, Lighthouse performance scores went from "Poor" (50s) to "Good" (90s). On 4G, first contentful paint (FCP) is ~1.2s, and time to interactive (TTI) is ~1.8s – well under the 2s goal.

More importantly, users notice. I’ve had a few emails saying, "This site is so fast compared to others!" – and that’s the best metric.

Key Takeaways

If you’re building a multi-tool or content-heavy site, here’s what worked for me:

Split code aggressively: Load only what the user needs now.
Lazy-load everything non-critical: Use Intersection Observer for offscreen content.
Optimize images like your life depends on it: WebP, srcset, and SVG are your friends.
Audit dependencies: Most apps can trim 20-30% of bundle size by ditching bloat.

Performance is a never-ending battle, but these steps got me from "sluggish" to "snappy" with minimal effort. What’s your go-to performance win? Let me know in the comments!

(And if you need a quick utility, check out TinyUtils – it won’t make you wait.) 😊

How I built 15 browser tools with zero backend

Chilam Chan — Wed, 16 Sep 2026 04:06:18 +0000

Every "free online tool" I reached for wanted an upload, an account, or both. So I built 15 that need neither — and the constraint that made that possible turned out to be the best decision in the project: no backend at all.

Here's what runs where.

The browser can do more than we give it credit for

Image work (HEIC→JPG, compress, resize, strip EXIF): <canvas> + createImageBitmap, and WASM (heic2any) for formats the browser can't decode natively.
PDF split/merge: pdf-lib, entirely client-side.
QR codes, password generation, JSON formatting, word counting: plain JS + crypto.getRandomValues and Intl.Segmenter.

Nothing touches a server. "Your files never leave your device" isn't a privacy promise you have to trust — it's just how the thing works. Open DevTools → Network and watch: no request fires when you convert a file.

Why no-backend is a superpower for a solo dev

$0 to run. A zero-dependency static site generator emits plain HTML; Cloudflare Pages serves it free. 272 pages (15 tools × 16 languages + hub) cost nothing.
Nothing to operate. No servers, no uploads to secure, no data to leak, no scaling. The whole "ops" surface is a git push.
It's genuinely private, which is a real differentiator when every competitor uploads your file to "process" it.

The tradeoffs (being honest)

No accounts, no cross-device sync, no server-side history. For utilities, that's fine — you do one thing and leave.
Some formats (TIFF, exotic codecs) the browser just won't decode; you draw the line and say so.
SEO is the whole growth engine, since there's no viral loop. That's the part I'm still figuring out.

If you're sitting on a "should this be a SaaS or just a tool" decision: a surprising amount can be just a tool, and shipping it that way is faster, cheaper, and more private.

Tools are here if useful: https://boring-tools-6ip.pages.dev — happy to go deeper on any part of the stack in the comments.

Stop pasting sensitive JSON into random online formatters

Chilam Chan — Tue, 15 Sep 2026 17:04:58 +0000

Every developer has done it: you get an ugly one-line JSON blob back from an API, and you paste it into the first "JSON formatter online" result to make it readable.

Here's the problem. Half the time that blob is a real response from your system — it can contain access tokens, internal IDs, customer emails, signed URLs, session data. The moment you paste it into a random web tool, you've sent that data to a server you don't control. You don't know if it's logged, cached, or sitting in someone's analytics pipeline.

For a side project, maybe you shrug. Inside a company with a compliance team, that's the kind of thing that ends up in an incident review.

The fix: format JSON in the browser, not on a server

You don't need a server to pretty-print JSON. Everything — parsing, formatting, validating, minifying — can happen entirely client-side with JSON.parse / JSON.stringify. The data never has to leave the tab.

// This is the whole "backend" of a JSON formatter:
const pretty = JSON.stringify(JSON.parse(input), null, 2);

A tool built this way can even work offline once the page has loaded, because there's nothing to call home to.

How to check if a tool is actually client-side

Don't take a site's word for it. Open DevTools → Network tab, paste your JSON, hit format, and watch:

No new request fires → the work happened locally. Safe.
A request goes out with your JSON in the payload → your data just left the building.

Do this once with any "online" dev tool that eats sensitive input (JSON, JWT decoders, "beautifiers", diff tools). You'll be surprised how many phone home.

What I ended up using

I got tired of doing that Network-tab check every time, so I built a JSON formatter that's 100% client-side — format, validate, minify, nothing uploaded, no signup:

👉 https://boring-tools-6ip.pages.dev/json-formatter/

It's part of a small set of no-upload browser utilities I'm building solo. If you deal with sensitive payloads regularly, the "does this leave my machine?" habit is worth building regardless of which tool you land on.

What's your rule of thumb for pasting real data into third-party dev tools? Curious how others draw the line.