Building a High-Performance Site Analyzer with Astro, React, and Node.js Performance Hooks

Pere — Sun, 22 Feb 2026 22:28:26 +0000

Precision Diagnostics: How We Built the Deltum Site Checker

Most website "health checkers" are either bloated, marketing-heavy, or hide their most valuable data behind a sign-up wall. At Deltum, we believe that digital systems should be transparent and built to last.

To support this, we built a Site Checker—a real-time diagnostic tool designed to give developers and founders an immediate, high-fidelity look at their site’s connectivity, security, and performance.

Here is a look at the technical architecture behind it.

The Goal: Accuracy Without Overhead

We needed the tool to be three things:

Instant: No waiting for full page renders.
Accurate: Measuring raw server response, not just browser-level "perceived" speed.
Informative: Auditing security headers that actually matter (CSP, HSTS, etc.).

The Tech Stack

Following our core principle of "Fewer dependencies, stronger systems," we utilized our standard stack:

Framework: Astro (using SSR mode on Vercel)
UI Architecture: React Islands (hydrated only when the tool is in use)
Styling: Tailwind CSS + daisyUI
Backend: Node.js http/https modules & performance hooks

Technical Implementation: Microsecond Timing

To get the most accurate network timings, we avoided high-level fetch libraries which can add unnecessary overhead. Instead, we used Node.js's native performance hooks within a serverless API route.

1. The HEAD Request Strategy

Instead of a GET request (which downloads the entire HTML body), we perform a HEAD request. This respects the target server’s resources and allows us to inspect headers and timings with minimal data transfer.

import { performance } from 'perf_hooks';

export async function GET({ request }) {
  const start = performance.now();

  // We measure the request lifecycle:
  // DNS -> TCP Handshake -> TLS -> TTFB

  const response = await fetch(targetUrl, { method: 'HEAD' });
  const end = performance.now();

  const ttfb = end - start; 
  // ... more detailed timing logic
}

2. The React Island

The UI is a React component integrated into an Astro page. We use framer-motion for subtle state transitions—ensuring the tool feels "premium" and responsive without cluttering the global site bundle.

---
import SiteChecker from '../components/SiteChecker.tsx';
---
<SiteChecker client:load />

Security Posture Audit

Performance is only half the story. A "stable system" is a secure one. The tool automatically parses the response headers to check for:

Content-Security-Policy (CSP): To prevent injection.
HSTS: To ensure encrypted connections.
X-Frame-Options: To mitigate clickjacking.

Why We Built This

At Deltum, we treat websites as infrastructure, not decoration. This tool is a small piece of our philosophy: providing clarity and structure to the digital systems we manage.

Try the tool here: https://www.deltum.io/en/tools/site-checker

I’d love to hear how you handle server-side performance monitoring. Do you prefer HEAD requests for health checks, or do you find GET more reliable for certain edge cases?

Built by Deltum — Digital systems, built to last.

Websites are systems, not deliverables

Pere — Mon, 02 Feb 2026 17:00:07 +0000

Launching a website often feels like crossing a finish line.

Design approved, code deployed, project done!

In practice, launch day is the moment a website enters its most complex phase.

Once public, a website operates in a hostile environment: the open internet. It receives real traffic, real content changes, real dependency updates, and real security pressure. Over time, small decisions compound — for better or worse.

This is why treating websites as one-off deliverables is risky.

The problem with “finished” websites

When a website is treated as something to be delivered and forgotten, a predictable pattern appears:

Dependencies age and become harder to update
Performance slowly degrades
Content structure becomes brittle
Small changes feel increasingly expensive

Eventually, the system reaches a point where the only perceived option is a full rewrite.

This cycle is common, and costly.

Not because teams are careless, but because the system was never designed to evolve.

Thinking in systems changes everything

A system is something that:

evolves over time
requires maintenance
accumulates value or debt
responds to change

When a website is treated as a system, decisions shift.

Instead of optimizing for launch speed, you optimize for:

clear structure
small surface area
understandable dependencies
separation between content and presentation

These choices don’t eliminate change — they make change survivable.

Stability is not the absence of change

Stability is often misunderstood as stagnation.

In reality, stable systems change constantly. The difference is how they change.

Deliberate change:

is incremental
respects existing structure
avoids unnecessary rewrites
compounds value over time

Undisciplined change does the opposite.

The long-term payoff

Systems designed for longevity tend to:

require fewer emergency fixes
be cheaper to maintain
adapt more easily to new needs
inspire more confidence in the teams that use them

These benefits aren’t always visible on launch day, but they matter far more on day two — and day two hundred.

Closing thought

Websites don’t fail because they change.
They fail because they were never designed to change.

Treating websites as systems is not about doing more work upfront.
It’s about making different decisions and taking responsibility for what happens after launch.

Pere
Founder at Deltum
Digital systems, built to last.
deltum.io

DEV Community: Pere