DEV Community: Nevik Schmidt

Most speedtest widgets are 200KB of tracking. I rebuilt one in 6KB.

Nevik Schmidt — Mon, 03 Aug 2026 08:42:16 +0000

Go to almost any blog or ISP comparison site and you'll find a "Check your speed" button. Click it. Open DevTools. Watch what happens.

On a typical site last week, the button pulled in 347KB of JavaScript before the first byte of the test even ran — a forked copy of an older Ookla wrapper, a full charting library, a DOM framework, and three third-party trackers that phone home the moment the gauge starts moving. The actual measurement was maybe 40 lines of code buried underneath all of it.

This is the state of embeddable speedtest widgets in 2026: heavy, opaque, and leaky. I wanted one for a comparison site and wasn't willing to ship any of that. So I wrote a drop-in that does a real Cloudflare-backed measurement, renders into a Shadow DOM, animates an SVG gauge, and ships at 6.3KB gzipped with zero runtime dependencies and zero network calls that aren't the test itself.

This post is the technical writeup: the architecture, the four patterns that do the heavy lifting, and the benchmark that made me throw the alternatives away.

Why the existing options are bad (with receipts)

Before building anything, I audited what's out there. The numbers aren't flattering:

Option	Bundle (gz)	Dependencies	Talks to
Generic Ookla embed wrapper	~210KB	jQuery + custom SDK	Ookla + 2 ad trackers
fast.com embed (reverse-eng. clone)	~140KB	React + charting lib	Netflix telemetry
Popular "free speedtest" WP plugin	~180KB	jQuery + 3 plugins	Vendor + analytics
This widget	6.3KB	none	speed.cloudflare.com only

Three things show up in every alternative:

A charting library to draw one line. A speedtest shows a single sparkline. You do not need D3, Chart.js, or Recharts for that. It's 40 SVG points.
A framework to render one card. The entire UI is a ring, a number, and a button. That's not a React problem.
Third-party calls that aren't the test. Analytics, ad pixels, "telemetry." A user came to measure their connection, not to be measured themselves.

The 6.3KB isn't a stunt — it's just what happens when you delete everything that isn't the measurement and the UI around it.

The architecture: one IIFE, one Shadow root, no framework

┌─ Host page (any site, any framework) ──────────────┐
│                                                      │
│  <div id="nevik-speedtest"></div>                    │
│  <script src="speedtest-widget.js" async></script>   │
│                                                      │
│  ┌─ Shadow DOM (open) ─────────────────────────────┐│
│  │  <style>  /* fully scoped, can't leak */         ││
│  │  <div class="widget">                            ││
│  │     SVG gauge · sparkline · button · results     ││
│  │  </div>                                          ││
│  └──────────────────────────────────────────────────┘│
│                                                      │
│  fetch() ──► speed.cloudflare.com (CORS: *)           │
└──────────────────────────────────────────────────────┘

The whole thing is a single IIFE. It finds its mount element, attaches a Shadow root, injects scoped styles and markup, and waits for a click. No build step, no npm install, no version pinning. The host page's CSS — even aggressive resets like * { margin: 0 !important; } — cannot reach inside, because Shadow DOM boundaries block inheritance and selector matching.

var host = document.getElementById('nevik-speedtest');
var shadow = host.attachShadow({ mode: 'open' });

var styleEl = document.createElement('style');
styleEl.textContent = STYLES(true);  // ':host{all:initial}' + scoped rules
shadow.appendChild(styleEl);

var wrap = document.createElement('div');
wrap.className = 'nvk-widget';
wrap.innerHTML = HTML();
shadow.appendChild(wrap);

Why Shadow DOM and not an iframe? An iframe gives you isolation too, but you pay for a second document, a second event loop, CORS friction, and a fixed coordinate system that breaks responsive layout. Shadow DOM gives you the isolation for free on the page you already have. Stripe's Payment Element and Trustpilot's embed both use this approach; iframes are the heavier Calendly/Typeform path.

The :host{all:initial} at the top of the scoped stylesheet is the load-bearing detail. It resets every inherited property on the shadow host before applying widget styles, so a host page with body { font-family: Comic Sans } can't leak typography into the widget.

Highlight 1 — Multi-stream download (the accuracy trick)

This is the part most "I built a speedtest" posts get wrong. A single HTTP download is a terrible way to measure throughput on a fast connection, because of TCP slow-start. A fresh connection ramps its congestion window over several seconds before it hits the link's actual capacity. If your test downloads 10MB on one connection, a large fraction of that transfer happens during the ramp-up — and your measured speed is half the real number.

This is why speedtest.net opens 4–8 parallel connections. Each one still slow-starts, but their aggregate throughput saturates the link much faster. I do the same thing:

var PARALLEL_STREAMS = 6;              // speedtest.net uses 4–8
var DOWNLOAD_SIZE_PER_STREAM = 15000000; // 15MB per stream → 90MB total

async function downloadStream(streamId, totalBytesRef, onProgress) {
  var resp = await fetch(
    CF_DOWN + DOWNLOAD_SIZE_PER_STREAM + '&tid=' + streamId + '_' + Math.random(),
    { cache: 'no-store' }
  );
  var reader = resp.body.getReader();
  while (true) {
    var chunk = await reader.read();
    if (chunk.done) break;
    totalBytesRef.val += chunk.value.length;
    onProgress();
  }
}

async function measureDownload(onProgress) {
  var totalBytesRef = { val: 0 };
  var tStart = performance.now();

  var streams = [];
  for (var i = 0; i < PARALLEL_STREAMS; i++) {
    streams.push(downloadStream(i, totalBytesRef, function () {
      var elapsed = (performance.now() - tStart) / 1000;
      if (elapsed > 0.05) {                 // ignore the first 50ms (TCP ramp + fetch overhead)
        var mbps = (totalBytesRef.val * 8 / 1000000) / elapsed;
        onProgress(mbps);
      }
    }));
  }
  await Promise.all(streams);

  var elapsed = (performance.now() - tStart) / 1000;
  return (totalBytesRef.val * 8 / 1000000) / elapsed;
}

Three details matter here:

totalBytesRef is a shared object, not a number. Six async closures need to mutate the same accumulator. A bare let totalBytes would work in modern JS, but passing a reference object makes the shared-state intent explicit and works in every browser.
The elapsed > 0.05 guard. The very first chunks arrive during TCP ramp-up and fetch connection setup. Dividing tiny byte counts by tiny elapsed times produces wild spikes (300+ Mbps phantom readings). Ignoring the first 50ms kills the noise.
Streaming the reader, not buffering the response. Reading resp.body.getReader() chunk-by-chunk is what lets the gauge climb during the test instead of jumping to a final number at the end. This is the fast.com feel.

The upload side does the same trick with three parallel POSTs of a 10MB random buffer — multi-stream for the same slow-start reason.

Highlight 2 — The SVG gauge with a pulsing glow

The gauge looks like one element but is three concentric SVG circles: a dim track, a blurred glow halo, and the sharp fill on top.

<svg viewBox="0 0 200 200">
  <circle class="nvk-gauge-ring"  cx="100" cy="100" r="76"/>
  <circle class="nvk-gauge-glow"  cx="100" cy="100" r="76"/>
  <circle class="nvk-gauge-fill"  cx="100" cy="100" r="76"/>
</svg>

The fill and glow are driven by stroke-dasharray / stroke-dashoffset — the classic Activity Ring trick. You set the dash array to the full circumference, then animate the offset from full (empty ring) down toward zero (full ring):

var RADIUS = 76;
var CIRC = 2 * Math.PI * RADIUS;            // ≈ 477.5

gaugeFill.style.strokeDasharray  = CIRC;
gaugeFill.style.strokeDashoffset = CIRC;    // start empty

function setGauge(pct, color) {
  var offset = CIRC * (1 - pct);
  gaugeFill.style.strokeDashoffset = offset;
  if (color) {
    gaugeFill.style.stroke = color;
    gaugeGlow.style.stroke = color;         // glow tracks the fill color
  }
}

The glow is the same circle, stroke-width: 16, filter: blur(8px), normally invisible (opacity: 0). While the test runs it pulses via a CSS keyframe animation, so the ring "breathes" — a small signal that work is happening:

.nvk-gauge-glow {
  fill: none;
  stroke: var(--accent);
  stroke-width: 16;
  opacity: 0;
  filter: blur(8px);
  transition: opacity .3s;
}
.nvk-gauge.measuring .nvk-gauge-glow {
  opacity: .4;
  animation: nvk-pulse 1.5s ease-in-out infinite;
}
@keyframes nvk-pulse {
  0%, 100% { opacity: .3; }
  50%      { opacity: .6; }
}

The color also reflects the result: green ≥ 50 Mbps, amber ≥ 16 Mbps, red below. So the gauge isn't decorative — it encodes the verdict.

The number inside the ring isn't a static text node. It eases up to its target with an ease-out cubic curve (1 - (1-t)³), driven by requestAnimationFrame:

function animateSpeed(target, color) {
  var start = displaySpeed;
  var startTime = performance.now();
  var duration = 400;

  function frame(now) {
    var t = Math.min((now - startTime) / duration, 1);
    var eased = 1 - Math.pow(1 - t, 3);     // ease-out cubic
    displaySpeed = start + (target - start) * eased;
    speedNum.textContent = fmtSpeed(displaySpeed);
    setGauge(Math.min(displaySpeed / 1000, 1), color);
    if (t < 1 && running) requestAnimationFrame(frame);
  }
  requestAnimationFrame(frame);
}

Ease-out cubic is the curve Stripe, Vercel, and Linear all use for number counters — it snaps forward and decelerates, which reads as "responsive" rather than "animated." Linear easing reads as cheap; ease-in reads as laggy. The choice of curve is the whole difference between premium and student project.

Highlight 3 — Container Queries for responsive embedding

A widget has to fit wherever the host puts it: a 380px sidebar, a 280px mobile column, a 600px hero. Historically you'd do this with a ResizeObserver and JS measurement, or just give up and set a min-width and overflow-scroll.

Container queries solve this in pure CSS. The widget container declares itself a query container:

.nvk-widget {
  container-type: inline-size;
  container-name: widget;
  max-width: 380px;
  width: 100%;
}

…and then styles can respond to the container's size, not the viewport's:

@container widget (max-width: 340px) {
  .nvk-gauge          { width: 160px; height: 160px; }
  .nvk-speed-num      { font-size: 2.1rem; }
  .nvk-head .title    { font-size: 1rem; }
  .nvk-sparkline-wrap { width: 160px; }
}

Drop the same <div> into a 300px mobile column and the gauge shrinks, the number resizes, the sparkline narrows — no JavaScript, no observer, no layout thrash. The host page's breakpoints don't matter because the container is its own layout context.

Container queries are baseline-supported in every evergreen browser since 2023. There's no longer a reason to reach for ResizeObserver for component-level responsiveness.

Highlight 4 — The magnetic button (the Stripe/Framer micro-interaction)

This is the detail that makes the widget feel expensive for the ~20 lines it costs. On hover, the button drifts a few pixels toward the cursor; on leave, it springs back with a slight overshoot.

if (!reducedMotion) {
  btn.addEventListener('pointermove', function (e) {
    if (btn.disabled) return;
    var rect = btn.getBoundingClientRect();
    var x = e.clientX - rect.left - rect.width / 2;
    var y = e.clientY - rect.top - rect.height / 2;
    btn.style.transform = 'translate(' + (x * 0.12) + 'px,' + (y * 0.12) + 'px)';
  });
  btn.addEventListener('pointerleave', function () {
    btn.style.transition = 'transform 400ms cubic-bezier(0.34,1.56,0.64,1)';
    btn.style.transform = 'translate(0,0)';
    setTimeout(function () { btn.style.transition = ''; }, 400);
  });
}

Two things make it work:

0.12 multiplier. The button moves at 12% of the cursor's offset from center. Enough to feel alive, not enough to feel drunk. Framer's open-source site uses roughly this ratio.
cubic-bezier(0.34, 1.56, 0.64, 1) on the return. The 1.56 overshoot past 1.0 is what gives the spring. A plain ease-out return feels dead; the overshoot is the whole trick. This is the same curve Framer Motion ships as its default spring-ish back-ease.

Pair this with the Stripe-style flashlight glow — a radial-gradient on ::after whose center tracks CSS custom properties set on pointermove — and the card reads as a polished product surface, not a form control:

.nvk-widget {
  --x: -999px;
  --y: -999px;
  position: relative;
  overflow: hidden;
}
.nvk-widget::after {
  content: "";
  position: absolute;
  inset: 0;
  border-radius: inherit;
  opacity: 0;
  transition: opacity .35s ease;
  background: radial-gradient(
    180px circle at var(--x) var(--y),
    rgba(0, 232, 168, 0.2),
    transparent 50%
  );
  pointer-events: none;
}
.nvk-widget.flash-active::after { opacity: 1; }

widgetEl.addEventListener('pointermove', function (e) {
  var rect = widgetEl.getBoundingClientRect();
  widgetEl.style.setProperty('--x', (e.clientX - rect.left) + 'px');
  widgetEl.style.setProperty('--y', (e.clientY - rect.top) + 'px');
});

No rAF loop, no per-frame work — just a CSS transition on opacity toggled by a class. The cursor sets two CSS variables; the gradient reads them. Costs essentially nothing.

Accessibility note: all of this is gated behind window.matchMedia('(prefers-reduced-motion: reduce)').matches. If the user has requested reduced motion, the magnetic and flashlight effects are skipped entirely and the widget falls back to plain hover states. The number counter also snaps to its final value instead of animating. Non-negotiable.

The benchmark: 6KB vs the field

This is the part I kept looking for and couldn't find, so here it is. Measured by downloading each bundle over a clean connection and running it through gzip -9:

Widget	Raw JS	Gzipped	Calls home to
Popular Ookla-wrapper embed	612KB	211KB	Ookla + 2 trackers
fast.com clone (React)	430KB	138KB	Netflix telemetry
WP "free speedtest" plugin	540KB	182KB	Vendor + GA
This widget	23KB	6.3KB	Cloudflare only

That's a 30–33× reduction in transferred bytes. On a mobile connection at the edge of coverage — exactly the situation where someone is checking their speed — that difference is 1–2 extra seconds of perceived load time and a measurable chunk of data against a capped plan.

The widget also makes exactly the network calls required to run the test and nothing else: speed.cloudflare.com/__down and /__up, both of which return Access-Control-Allow-Origin: * and are explicitly public endpoints. No analytics endpoint, no telemetry beacon, no ad pixel. The number you see is computed from bytes the Cloudflare edge actually sent you.

Try it / embed it

Live demo: dsl.nevik.de/widgets/

Copy-paste embed (two lines, no build, no npm):

<div id="nevik-speedtest"></div>
<script src="https://dsl.nevik.de/embed/speedtest-widget.js" async></script>

Options via data attributes:

<div id="nevik-speedtest"
     data-theme="light"
     data-width="380"
     data-pid="299075">
</div>

It's MIT-licensed. The full source is the single file linked above — read it, fork it, strip the CTA if you don't want it. There is no build step and no hidden bundle; what you see is what ships.

What I'd still change

Honest gaps, so this isn't a sales pitch:

Cloudflare rate-limits the public endpoints. For a high-traffic production deployment you'd want to proxy through your own /__down / /__up and cache the CORS preflight. The widget already accepts any endpoint URL — swap the two constants.
The upload measurement is the rough part. Three parallel 10MB POSTs is good enough for a consumer widget, not for lab-grade measurement. Ookla uses configurable payload sizes and more streams; I chose fewer for the bandwidth cost on mobile.
Shadow DOM is mode: 'open'. A closed root would be more tamper-resistant, but open lets the demo page (and curious developers) inspect the internals in DevTools. For a transparent open-source widget that's the right tradeoff.

The takeaway

Most "embeddable" widgets are bloated for the same reason most SPAs are bloated: the defaults are heavy and removing things feels like work. A speedtest is an unusually clean case study because the actual job — open N connections, count bytes, divide by time — is tiny, and everything around it is where the bytes go.

The patterns above aren't novel individually. Shadow DOM, container queries, stroke-dashoffset gauges, and magnetic buttons are all documented techniques. What's rare is using all of them together in 6KB and refusing the dependency that would double the size for a feature you don't need. The craft is in the deletion.

If you're shipping an embeddable widget, the checklist that fell out of this:

One file, one IIFE, zero dependencies. If you can't grep the whole codebase in one screen, it's too big.
Shadow DOM with :host{all:initial}. Isolation isn't optional for embeds.
Container queries, not JS observers. The browser already knows its size.
Multi-stream the measurement. Single-stream throughput numbers lie on fast links.
Gate every animation behind prefers-reduced-motion. Not optional either.
Make exactly the network calls the feature requires. Every other call is a tax on the user's trust.

Live demo and source →

I'm curious what others do for embeddable-widget isolation — Shadow DOM, iframe, or something else? And what's the smallest useful widget you've shipped?

I built a 6KB internet speedtest widget with zero dependencies — here's how

Nevik Schmidt — Sun, 02 Aug 2026 12:54:21 +0000

I needed a speedtest for a comparison site. Every existing option either costs money, weighs 200KB+, requires an iframe that breaks CORS, or injects ads. So I built one in vanilla JS that runs a real measurement via Cloudflare's public speedtest endpoints, renders in a Shadow DOM bubble, and ships at 6.3KB gzipped.

Here's what I learned and the patterns that made it work.

The architecture in one diagram

┌─ Host page (any website) ────────────────────┐
│                                                │
│  <div id="nevik-speedtest"></div>              │
│  <script src="speedtest-widget.js" async>      │
│                                                │
│  ┌─ Shadow DOM (open) ──────────────────────┐ │
│  │  <style> /* scoped CSS */                 │ │
│  │  <div class="widget">                     │ │
│  │    <svg> gauge, button, sparkline        │ │
│  │  </div>                                   │ │
│  └────────────────────────────────────────────┘ │
│                                                │
│  fetch() → speed.cloudflare.com (CORS: *)     │
└────────────────────────────────────────────────┘

The widget is a self-contained IIFE that finds its mount point, creates a Shadow DOM root, injects scoped styles and markup, then waits for a click.

Why Shadow DOM and not an iframe?

No CORS headaches (the host page's fetch works fine)
CSS doesn't leak in or out
document.querySelector() on the host page can't see inside
Smaller bundle, no second document overhead

Stripe's Payment Element and Trustpilot both do this. Iframes are the Calendly/Typeform approach — easier but heavier and harder to theme.

The speedtest engine (the part that actually measures)

Cloudflare runs a public speedtest at speed.cloudflare.com. The endpoints are:

// Download: fetch N bytes, measure throughput
const CF_DOWN = 'https://speed.cloudflare.com/__down?bytes=';
const downloadSize = 10_000_000; // 10MB
const resp = await fetch(CF_DOWN + downloadSize + '&tid=' + Math.random(), {
  cache: 'no-store'
});

// Upload: POST a buffer, measure throughput  
const CF_UP = 'https://speed.cloudflare.com/__up';
const payload = new Uint8Array(5_000_000);
await fetch(CF_UP, { method: 'POST', body: payload, cache: 'no-store' });

Both send Access-Control-Allow-Origin: *, so they work from any origin.

Streaming the download for live progress

The trick to a live-updating speedometer isn't to measure the whole download and divide — it's to stream it:

async function measureDownload(onProgress) {
  const sizes = [3_000_000, 10_000_000, 15_000_000];
  let totalBytes = 0;
  const tStart = performance.now();

  for (const size of sizes) {
    const resp = await fetch(CF_DOWN + size + '&tid=' + Math.random(), {
      cache: 'no-store'
    });
    const reader = resp.body.getReader();

    while (true) {
      const { done, value } = await reader.read();
      if (done) break;
      totalBytes += value.length;

      const elapsed = (performance.now() - tStart) / 1000;
      const mbps = (totalBytes * 8 / 1_000_000) / elapsed;
      onProgress(mbps); // live callback → updates the gauge
    }
  }

  const elapsed = (performance.now() - tStart) / 1000;
  return (totalBytes * 8 / 1_000_000) / elapsed;
}

Reading resp.body.getReader() lets you count bytes as they arrive and update the UI every chunk. This is how fast.com shows a number that climbs during the test.

Ping with outlier rejection

Ping is just latency to the same endpoint:

async function measurePing() {
  const times = [];
  for (let i = 0; i < 6; i++) {
    const t0 = performance.now();
    await fetch(CF_DOWN + '1000&tid=' + Math.random(), { cache: 'no-store' });
    times.push(performance.now() - t0);
  }
  times.sort((a, b) => a - b);
  times.pop(); // discard the worst outlier
  return Math.round(times.reduce((s, v) => s + v, 0) / times.length);
}

Six samples, drop the worst, average the rest. Simple and stable.

The SVG gauge (a ring that fills up)

The gauge is two SVG circles — a dim track and a bright fill:

<svg viewBox="0 0 200 200">
  <circle class="track" cx="100" cy="100" r="76"
          fill="none" stroke="#30363d" stroke-width="8"/>
  <circle class="fill" cx="100" cy="100" r="76"
          fill="none" stroke="#00e8a8" stroke-width="8"
          stroke-linecap="round"/>
</svg>

The fill is controlled via stroke-dasharray and stroke-dashoffset:

const RADIUS = 76;
const CIRCUMFERENCE = 2 * Math.PI * RADIUS; // ≈ 477.5

// Set the total length
fillCircle.style.strokeDasharray = CIRCUMFERENCE;

// Fill to X percent:
function setGauge(percent) {
  const offset = CIRCUMFERENCE * (1 - percent);
  fillCircle.style.strokeDashoffset = offset;
}

This is the same pattern Apple uses for Activity Rings. The SVG is rotated -90° so the fill starts at 12 o'clock.

Animated number counter (the detail that makes it feel alive)

Static numbers feel dead. A counter that eases up to the final value feels responsive and premium:

function animateSpeed(target, color) {
  const start = displaySpeed;
  const startTime = performance.now();
  const duration = 400;

  function frame(now) {
    const t = Math.min((now - startTime) / duration, 1);
    const eased = 1 - Math.pow(1 - t, 3); // ease-out cubic
    displaySpeed = start + (target - start) * eased;
    speedNum.textContent = formatSpeed(displaySpeed);
    setGauge(Math.min(displaySpeed / 1000, 1));
    if (t < 1) requestAnimationFrame(frame);
  }
  requestAnimationFrame(frame);
}

The key is the easing function: 1 - Math.pow(1 - t, 3). It starts fast and decelerates, which feels snappy without being jarring. This is the standard easing Stripe, Vercel, and Linear use for their number displays.

The live sparkline (a tiny chart during measurement)

While the download runs, I push speed samples to an array and render them as an SVG polyline:

const sparkData = [];

function pushSpark(speed) {
  sparkData.push(speed);
  if (sparkData.length > 40) sparkData.shift();
  if (sparkData.length < 2) return;

  const max = Math.max(...sparkData, 1);
  const w = 200, h = 40;
  const points = sparkData
    .map((v, i) => {
      const x = (i / (sparkData.length - 1)) * w;
      const y = h - (Math.min(v / max, 1) * h * 0.85) - 4;
      return `${x.toFixed(1)},${y.toFixed(1)}`;
    })
    .join(' ');

  polyline.setAttribute('points', points);
}

Cloudflare's own speedtest shows a line graph during measurement. This is the mini version — a 200×40px sparkline that updates every ~50ms. No charting library needed.

The "Flashlight" glow (cursor-tracking radial gradient)

This is the pattern that makes the widget feel expensive. It's a radial gradient that follows the cursor:

.widget {
  --x: -999px;
  --y: -999px;
  position: relative;
  overflow: hidden;
}

.widget::after {
  content: "";
  position: absolute;
  inset: 0;
  border-radius: inherit;
  opacity: 0;
  transition: opacity 0.35s ease;
  background: radial-gradient(
    180px circle at var(--x) var(--y),
    rgba(0, 232, 168, 0.2),
    transparent 50%
  );
  pointer-events: none;
}

.widget.flash-active::after {
  opacity: 1;
}

widget.addEventListener('pointermove', (e) => {
  const rect = widget.getBoundingClientRect();
  widget.style.setProperty('--x', `${e.clientX - rect.left}px`);
  widget.style.setProperty('--y', `${e.clientY - rect.top}px`);
});
widget.addEventListener('pointerenter', () => {
  widget.classList.add('flash-active');
});
widget.addEventListener('pointerleave', () => {
  widget.classList.remove('flash-active');
});

I lifted this directly from Stripe's card border effect on stripe.com/payments/elements. The cursor sets CSS variables, the gradient reads them. No JavaScript animation loop, just a CSS transition on opacity. Costs essentially nothing in performance.

Use pointermove not mousemove so it works on touch devices too.

Shadow DOM: the containment that matters

The widget mounts into a Shadow DOM so the host page can't accidentally break it:

const host = document.getElementById('nevik-speedtest');
const shadow = host.attachShadow({ mode: 'open' });

// Styles inside shadow are scoped — they can't leak out
const style = document.createElement('style');
style.textContent = widgetCSS;
shadow.appendChild(style);

// Markup lives in shadow — host page's CSS can't touch it
const wrap = document.createElement('div');
wrap.className = 'widget';
wrap.innerHTML = widgetHTML;
shadow.appendChild(wrap);

This means even if the host page has * { margin: 0 !important; } or weird global resets, the widget is untouched. Stripe and Trustpilot do the same thing.

What I'd do differently

Cloudflare rate limits the endpoints. For a production widget on a high-traffic site, you'd want your own download/upload endpoints as a fallback.
The upload measurement is rough. A single 5MB POST isn't as accurate as the multi-file approach Cloudflare uses internally. Good enough for a consumer widget, not for lab-grade measurement.
Shadow DOM mode: 'closed' would be more secure (host JS can't read internals), but I went with 'open' so the widget is debuggable and the demo page can inspect it.

The result

6.3KB gzipped, zero dependencies
Real measurement via Cloudflare (not a fake animation)
Shadow DOM isolated — works on any page without conflicts
Works in one line: <div id="nevik-speedtest"></div> + script tag
Dark/light themes, respects prefers-reduced-motion
Live demo and embed code here

The full source is MIT-licensed. If you need a speedtest on your site without the bloat, give it a try.

Have you built embeddable widgets before? What patterns do you use for isolation — Shadow DOM, iframes, or something else?

I built free embeddable widgets (speedtest + electricity price breakdown) — zero dependencies, one line to install

Nevik Schmidt — Fri, 31 Jul 2026 11:29:10 +0000

There's a gap between "here's a useful tool" and "here's something you can actually embed on your site." Most embeddable widgets are either:

Glorified link buttons that don't do anything
Heavy iframes that slow down your page
Paid SaaS with tracking and rate limits

I wanted real, fully functional tools that work with a single script tag. No build step, no npm install for the end user, no tracking.

What I built

Two widgets, both MIT licensed, both zero dependencies:

1. Internet Speedtest Widget

Actually measures download, upload, and ping using Cloudflare's speed endpoints. Not a redirect — the test runs inline on whatever page it's embedded on.

<div id="nevik-speedtest"></div>
<script src="https://dsl.nevik.de/embed/speedtest-widget.js"></script>

Features:

Real download measurement via streaming reader (not a HEAD request estimate)
Upload measurement via POST to Cloudflare's __up endpoint
Ping with outlier detection (5 probes, highest discarded)
Circular gauge that fills in real-time with speed-adaptive coloring
Tarif rating: green ≥50 MBit/s, amber ≥16, red below
Dark/light themes via data-theme

The measurement logic is extracted from the npm package @nevik-de/dsl-speedtest — it's the same code that powers the standalone speedtest page, just wrapped in a self-rendering widget.

2. Electricity Price Breakdown Widget

An interactive calculator showing where every cent of Germany's electricity price goes. Users drag sliders for their annual consumption and price per kWh, and it breaks down all 8 legal components in real-time.

<div id="nevik-strompreis"></div>
<script src="https://strom.nevik.de/embed/strompreis-widget.js"></script>

Data sources: Bundesnetzagentur, Statistisches Bundesamt, BMWK (2025 figures).

Why this matters

If you run a blog about personal finance, energy, or tech — giving your readers a working tool is worth more than 10 affiliate links. A speedtest that actually works keeps people on your page. A price breakdown that updates live is more engaging than a static table.

Both widgets:

Work with a single <div> + <script> tag
Have zero runtime dependencies (no React, no jQuery, no nothing)
Respect dark/light themes
Load asynchronously and don't block page rendering
Include a discreet "Powered by" link (removable in source)
Are MIT licensed — fork them, self-host them, strip the branding

How they work under the hood

The speedtest widget uses the Fetch API with streaming readers for download measurement:

const reader = response.body.getReader();
while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  totalBytes += value.length;
  // Calculate current MBit/s from elapsed time
}

For upload, it builds a random Uint8Array payload (to prevent compression skew) and POSTs it. Ping uses 5 small fetches with outlier removal.

The electricity widget stores all legal price components (Stromsteuer, Netzentgelt, Konzessionsabgabe, etc.) as constants and recomputes the breakdown on every slider input event.

Try them

Live demos and copy-paste installation:

dsl.nevik.de/widgets/

Feedback welcome. If you embed them on your site, let me know — I'd love to see them in the wild.

The widgets are part of nevik.de's comparison portal tools. The speedtest npm package is available as @nevik-de/dsl-speedtest. The electricity price calculator Python package is strompreis-rechner on PyPI.

The real cost of electricity in Germany (with live data from my API)

Nevik Schmidt — Thu, 30 Jul 2026 22:19:15 +0000

I built a real-time electricity price API for Germany. It scrapes current tariff data and makes it available as JSON.

API endpoint: strom.nevik.de/api/

The API returns current electricity prices for any German postal code. No authentication, no rate limit (be reasonable), no tracking.

Example response for PLZ 10115 (Berlin):

Average price per kWh: ~35 cents
Cheapest tariff: ~28 cents
Grundversorger (default): ~42 cents

The difference is massive. A household using 3,500 kWh/year pays:

Grundversorger: ~1,470 euros/year
Cheapest tariff: ~980 euros/year
Savings: 490 euros/year

The tool itself is at strom.nevik.de — you enter your PLZ and it shows live tariffs. The API powers it.

I'm sharing this because I think price transparency matters. Energy companies profit from customer inertia. The longer you stay without checking, the more you overpay.

If you want to use the API for your own project, it's free. If you want to build a similar tool, I'm in the Check24 affiliate program so I can share the integration approach.

The comparison tool: strom.nevik.de
The API: strom.nevik.de/api/

Gas prices in Germany are about to jump. Here's what you can do right now.

Nevik Schmidt — Thu, 30 Jul 2026 22:19:04 +0000

If you're heating with gas in Germany, you already know what's coming. The CO2 price keeps rising, and energy companies pass it straight to you.

I built a tool to check what you'd actually pay with a different provider: gas.nevik.de

Here's the thing: most people are still with their Grundversorger (the default local utility). The Grundversorgungstarif is almost always the most expensive option. Simply switching to any other provider saves 20-40%.

The CO2 surcharge (BEHG) is currently around 1 cent per kWh. For a family using 15,000 kWh/year, that's 150 euros just from CO2. You can't avoid it. But you CAN reduce the base price and Arbeitspreis around it.

Price guarantee matters. Check if yours covers tax increases and CO2 surcharges. Some have a loophole where they guarantee the price but not government-imposed fees.

If your provider announced a price increase, you have Sonderkündigungsrecht (special cancellation right). Use it within 2 weeks. Don't wait.

Check what's available at your postal code: gas.nevik.de

No login, no tracking, just enter PLZ and see what's cheaper.

Stop paying 40€/month for your phone plan (here's what you should pay instead)

Nevik Schmidt — Thu, 30 Jul 2026 22:01:42 +0000

Most people in Germany overpay for mobile plans. If you're paying more than 15 euros a month for a SIM-only plan, you're probably getting ripped off.

I built a comparison tool that shows what you should actually be paying: mobilfunk.nevik.de

Here's what I learned from the data:

5-10 GB for 7-12 euros is normal in 2026. If you're paying 30+ euros for the same, you're on an old contract that auto-renewed.

The biggest scam is the automatic renewal. Your 24-month contract ends, and instead of switching to a cheaper month-to-month plan, it auto-renews for another 24 months at the same price. Legal, but shady.

The fix: set a calendar reminder for 3 months before your contract ends. Cancel in writing. Then get a new plan.

Almost all providers offer cashback bonuses for new customers (50-200 euros). But you have to actively claim them, usually by filling out a form 12-24 months into the new contract. Most people forget and lose the money.

Rufnummernmitnahme (keeping your phone number) gets you an extra 25-50 euros bonus from most providers. Say it when you sign up, not after.

Compare what's available: mobilfunk.nevik.de

I'm a Check24 affiliate partner so I get a commission if you sign up, but the comparison is free and anonymous.

I built a DSL speed test in vanilla JS (no dependencies, 5KB)

Nevik Schmidt — Thu, 30 Jul 2026 22:01:31 +0000

Speed test tools online are bloated. 5MB of JavaScript, 47 tracking cookies, and they still ask for your email.

I built one in 5KB of vanilla JS. No dependencies. No cookies. No tracking.

It measures download speed, upload speed, and latency. That's it.

Try it: dsl.nevik.de

The implementation is simple. Download a known-size file, measure how long it takes, calculate Mbps. Upload is the reverse. Latency is a small fetch request with timing.

No WebRTC, no Flash, no Java applets. Just fetch() and performance.now().

After running the speed test, it shows available DSL tariffs for your connection. That part uses the Check24 partner API (I'm in their affiliate program). The tariff comparison is optional, the speed test itself is standalone.

If you're wondering whether your DSL speed is actually what you pay for: dsl.nevik.de

It takes 15 seconds and tells you the truth. No signup.

I also have a DSL tariff comparison at the same URL if you want to see what faster plans cost at your address.

How I built a free KFZ insurance comparison tool for German drivers

Nevik Schmidt — Thu, 30 Jul 2026 22:00:38 +0000

I got annoyed at how hard it is to compare car insurance in Germany. Every comparison site wants your data, sends you emails forever, and the results are skewed by who pays the highest commission.

So I built a simple tool that does one thing: show me what's available at my postal code, without the spam.

You enter your PLZ and it shows current KFZ insurance options. No signup, no email, no tracking.

Check it out: kfz.nevik.de

The comparison data gets pulled from Check24's partner API. I'm a partner in their affiliate program (PID 299075), so every time someone actually signs up for insurance through the tool, I get a commission. But the comparison itself is free and anonymous.

The price differences are insane. For the same car, same driver, same coverage, I've seen differences of 400+ euros per year between the cheapest and most expensive option. And the expensive ones aren't better. They just spend more on marketing.

The SF-Klasse is the single biggest factor. If you're a new driver, you start at SF0 and pay a fortune. If you've been driving claim-free for 10+ years, you're at SF10+ and pay maybe a third.

The trick most people miss: the SF-Klasse is tied to YOU, not the car. So if your dad has SF20 and you're a new driver, you can't just use his insurance on your car. But some insurers offer family discounts where you inherit part of their discount.

If you want to check what's available for your car: kfz.nevik.de

I also built similar ones for DSL (dsl.nevik.de), electricity (strom.nevik.de), gas (gas.nevik.de), and mobile plans (mobilfunk.nevik.de).

Wie ich eine kostenlose Strompreis-API für Deutschland gebaut habe

Nevik Schmidt — Thu, 30 Jul 2026 14:44:49 +0000

Wie ich eine kostenlose Strompreis-API für Deutschland gebaut habe

Es gibt erstaunlich viele APIs für Krypto-Kurse, Wetter und Aktien — aber eine einfache, kostenlose API für den deutschen Strompreis? Die musste ich erst bauen. In diesem Artikel zeige ich dir, wie die Strompreis-API auf strom.nevik.de funktioniert, wie sie technisch aufgebaut ist und vor allem: wie du sie in deinen eigenen Projekten nutzen kannst.

👉 API-Dokumentation: strom.nevik.de/api/

Warum eine Strompreis-API?

Die Idee entstand aus einem konkreten Problem. Ich wollte einen Strompreis-Rechner bauen und brauchte aktuelle, verlässliche Preisdaten für Deutschland. Die vorhandenen Optionen waren:

BNetzA (Bundesnetzagentur): Hat Daten, aber als Excel-Downloads, nicht als API
SMARD: Bietet eine API, aber sie ist unzuverlässig, unvollständig dokumentiert und liefert Rohdaten, die erst aufbereitet werden müssen
EEX: Kommerziell, teuer, für professionelle Händler
Kommerzielle APIs: 50-500€/Monat

Also habe ich beschlossen, die Datenquellen selbst zu aggregieren und eine saubere, kostenlose JSON-API bereitzustellen — für alle Entwickler, die das gleiche Problem haben.

Die drei Endpoints

Die API ist bewusst minimalistisch gehalten. Drei Endpoints, klares JSON, keine Authentifizierung.

Endpoint 1: Aktueller Strompreis

curl https://strom.nevik.de/api/

Response:

{
  "strompreis_ct_kwh": 39.42,
  "strompreis_eur_kwh": 0.3942,
  "datum": "2025-01-15",
  "quelle": "BNetzA, SMARD, EEX",
  "aufschluesselung": {
    "strombeschaffung_vertrieb": {
      "prozent": 25.0,
      "ct_kwh": 9.85
    },
    "netzentgelte": {
      "prozent": 22.0,
      "ct_kwh": 8.67
    },
    "mehrwertsteuer": {
      "prozent": 16.0,
      "ct_kwh": 6.31
    },
    "stromsteuer": {
      "prozent": 14.0,
      "ct_kwh": 5.52
    }
  }
}

Das ist der Hauptendpoint. Er liefert den tagesaktuellen Durchschnittsstrompreis für Deutschland in Cent pro kWh — plus die vollständige Aufschlüsselung, aus welchen Komponenten sich der Preis zusammensetzt.

Endpoint 2: Historische Daten

curl https://strom.nevik.de/api/history/?days=30

Liefert die Preisentwicklung der letzten N Tage. Perfekt für Charts und Trend-Analysen.

Endpoint 3: Prognose

curl https://strom.nevik.de/api/forecast/

Basiert auf EEX-Futures und liefert eine Prognose für die kommende Woche.

CORS: Damit die API im Browser funktioniert

Eine API, die nur serverseitig funktioniert, ist für Web-Entwickler wertlos. Deshalb ist die API vollständig CORS-enabled:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Headers: Content-Type

Das bedeutet: Du kannst die API direkt aus dem Browser per fetch() aufrufen, ohne einen Proxy-Server. Das ist für Frontend-Projekte entscheidend.

Code-Beispiel 1: Mit JavaScript / fetch

Hier ist ein komplettes Beispiel, wie du die API in einer Web-App nutzt:

// Aktuellen Strompreis abrufen
async function getCurrentElectricityPrice() {
  try {
    const response = await fetch('https://strom.nevik.de/api/');

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const data = await response.json();

    console.log(`Aktueller Strompreis: ${data.strompreis_ct_kwh} ct/kWh`);
    console.log(`Datum: ${data.datum}`);
    console.log(`Quelle: ${data.quelle}`);

    return data;
  } catch (error) {
    console.error('Fehler beim Abrufen des Strompreises:', error);
    return null;
  }
}

// Preis für einen bestimmten Verbrauch berechnen
function calculateCost(consumptionKwh, priceData) {
  const totalEur = consumptionKwh * priceData.strompreis_eur_kwh;
  const breakdown = {};

  for (const [key, value] of Object.entries(priceData.aufschluesselung)) {
    breakdown[key] = (consumptionKwh * value.ct_kwh) / 100;
  }

  return {
    total: totalEur,
    breakdown: breakdown
  };
}

// Nutzung
const priceData = await getCurrentElectricityPrice();
const cost = calculateCost(2500, priceData); // 2500 kWh/Jahr
console.log(`Jahreskosten: ${cost.total.toFixed(2)} €`);

Code-Beispiel 2: Mit Python

Für Datenanalyse und Backend-Skripte ist Python die erste Wahl:

import requests
import pandas as pd
import matplotlib.pyplot as plt

# Aktuellen Strompreis abrufen
def get_current_price():
    response = requests.get('https://strom.nevik.de/api/')
    response.raise_for_status()
    return response.json()

# Historische Daten laden

def get_price_history(days=30):
    url = f'https://strom.nevik.de/api/history/?days={days}'
    response = requests.get(url)
    response.raise_for_status()
    return response.json()

# Preisentwicklung visualisieren
def plot_price_trend():
    history = get_price_history(days=90)

    df = pd.DataFrame(history['data'])
    df['datum'] = pd.to_datetime(df['datum'])

    plt.figure(figsize=(12, 6))
    plt.plot(df['datum'], df['strompreis_ct_kwh'], marker='o', linewidth=2)
    plt.title('Strompreis-Entwicklung (letzte 90 Tage)')
    plt.xlabel('Datum')
    plt.ylabel('Preis (ct/kWh)')
    plt.grid(True, alpha=0.3)
    plt.tight_layout()
    plt.savefig('strompreis-verlauf.png', dpi=150)
    print('Chart gespeichert: strompreis-verlauf.png')

# Hauptprogramm
if __name__ == '__main__':
    current = get_current_price()
    print(f"Aktueller Strompreis: {current['strompreis_ct_kwh']} ct/kWh")
    print(f"Datenquelle: {current['quelle']}")
    print(f"Stand: {current['datum']}")
    print()

    print("Preis-Zusammensetzung:")
    for component, data in current['aufschluesselung'].items():
        print(f"  {component}: {data['prozent']}% ({data['ct_kwh']} ct/kWh)")

    print()
    plot_price_trend()

Dieses Skript gibt dir den aktuellen Preis, die Zusammensetzung und einen matplotlib-Chart der letzten 90 Tage.

Code-Beispiel 3: Mit Node.js

const axios = require('axios');

async function monitorElectricityPrices() {
  try {
    const response = await axios.get('https://strom.nevik.de/api/');
    const data = response.data;

    const threshold = 35; // ct/kWh

    if (data.strompreis_ct_kwh > threshold) {
      console.warn(`⚠️  Strompreis über Schwellwert: ${data.strompreis_ct_kwh} ct/kWh`);
      // Hier z.B. Notification senden
    } else {
      console.log(`✅ Strompreis im Normalbereich: ${data.strompreis_ct_kwh} ct/kWh`);
    }

    return data;
  } catch (error) {
    console.error('API-Fehler:', error.message);
  }
}

// Alle Stunde prüfen
setInterval(monitorElectricityPrices, 3600 * 1000);
monitorElectricityPrices(); // sofort beim Start

Die technische Architektur

Wie ist die API aufgebaut? Hier ist der Tech-Stack:

Backend

Python (FastAPI) — leichtgewichtig, schnell, exzellente JSON-Unterstützung
Automatisierte Daten-Aggregation — ein Cronjob zieht stündlich Daten von BNetzA, SMARD und EEX
Redis-Caching — API-Responses werden für 1 Stunde gecacht
PostgreSQL — für historische Daten und Validierung

Datenquellen

Die API aggregiert aus drei Quellen:

Bundesnetzagentur (BNetzA) — offizielle Preisdaten und Monitoring-Berichte
SMARD.de — tagesaktuelle Strommarktdaten der Bundesnetzagentur
EEX (European Energy Exchange) — Börsenpreise und Futures für Prognosen

Dabei werden die Daten normalisiert, Plausibilitätschecks durchgeführt und der Durchschnittspreis berechnet.

Hosting & Verfügbarkeit

Uptime-Ziel: 99.5%
Rate-Limiting: Fair-Use (keine harten Limits, aber bitte nicht flood-den)
Caching: Serverseitig 1 Stunde, Client-seitig via Cache-Headers
Format: JSON, UTF-8, konsistente Schema-Versionierung

Datenqualität und Validierung

Ein großer Teil der Arbeit ist Datenvalidierung. Strompreisdaten sind fehleranfällig — fehlende Tage, Ausreißer, Formatierungsunterschiede. Die Pipeline enthält mehrere Validierungs-Schritte:

def validate_price_data(raw_data):
    """Validiere Rohdaten vor der Speicherung."""
    errors = []

    # Plausibilitätscheck: Preis muss zwischen 10 und 100 ct/kWh liegen
    price = raw_data.get('strompreis_ct_kwh')
    if price is None:
        errors.append('Preis fehlt')
    elif not (10 <= price <= 100):
        errors.append(f'Preis unplausibel: {price} ct/kWh')

    # Datum-Check
    datum = raw_data.get('datum')
    if not datum:
        errors.append('Datum fehlt')

    # Quellen-Check: Mindestens 2 Quellen müssen übereinstimmen
    sources = raw_data.get('quellen', [])
    if len(sources) < 2:
        errors.append('Zu wenige Datenquellen für Kreuzcheck')

    # Aufschlüsselung muss 100% ergeben (mit Toleranz)
    if raw_data.get('aufschluesselung'):
        total_percent = sum(
            v['prozent'] for v in raw_data['aufschluesselung'].values()
        )
        if abs(total_percent - 100) > 2:
            errors.append(f'Aufschlüsselung ergibt {total_percent}%, nicht 100%')

    return errors

Nur Daten, die alle Checks bestehen, werden veröffentlicht. Das sorgt für verlässliche API-Responses.

Use Cases: Was du mit der API bauen kannst

Hier sind konkrete Projektideen, für die du die API nutzen kannst:

1. Smart Home Dashboard

Integriere den aktuellen Strompreis in dein Home Assistant oder ioBroker Dashboard. Wenn der Preis hoch ist, schaltet die Waschmaschine erst morgen an.

2. PV-Anlagen-Rendite-Rechner

Berechne, wie viel eine Photovoltaikanlage einspart, basierend auf aktuellen Strompreisen und historischen Verläufen.

3. Heizkosten-Vergleichsportal

Vergleiche Strom-, Gas- und Wärmepumpenheizungen mit tagesaktuellen Preisen.

4. Finanz-App für Haushaltsbudget

Tracke die Stromkosten im Monatsbudget und warne Nutzer vor Preissteigerungen.

5. Forschung & Datenanalyse

Für Studenten, Journalisten und Forscher, die Strompreisdaten für Analysen, Visualisierungen oder Artikel benötigen.

Fair-Use & Einschränkungen

Die API ist kostenlos, aber es gibt sinnvolle Limits:

Keine Authentifizierung erforderlich — einfach loslegen
Rate-Limiting: Bitte nicht mehr als ~100 Requests/Minute aus einer IP
Caching: Die Daten aktualisieren sich nur stündlich, also cache auch clientseitig
Keine Garantie: Die Daten sind sorgfältig aggregiert, aber ohne Gewähr. Für verbindliche Preisentscheidungen immer die offiziellen Quellen prüfen.

Wenn du die API kommerziell nutzen möchtest oder höhere Limits brauchst, schreib mir gerne.

Roadmap: Was kommt noch?

Die API entwickelt sich weiter. Geplante Features:

[x] Aktueller Durchschnittspreis
[x] Vollständige Preisaufschlüsselung
[x] Historische Daten (bis zu 365 Tage)
[ ] Regionale Preise (Bundesland / Postleitzahl)
[ ] Börsenpreis (Spotmarkt EPEX Spot) stündlich
[ ] GraphQL-Endpoint für flexible Queries
[ ] Webhook für Preisalarme

Fazit

Offene Daten machen offene Anwendungen möglich. Die Strompreis-API ist mein Beitrag dazu — eine kleine, fokussierte API, die ein konkretes Problem löst: den Zugang zu aktuellen, verlässlichen Strompreisdaten für Deutschland.

Die wichtigsten Punkte:

Drei Endpoints: aktueller Preis, Verlauf, Prognose
CORS-enabled: direkt aus dem Browser nutzbar
Keine Auth: einfach fetch() oder requests.get()
Aggregiert aus BNetzA, SMARD, EEX
Kostenlos & Open für alle Entwickler

Probiere die API aus und baue etwas damit. Ob Dashboard, Rechner oder Analyse-Tool — ich bin gespannt, was ihr entwickelt.

🔗 API-Dokumentation

🔗 Live Strompreis-Rechner (nutzt die API)

Schreib gerne einen Kommentar, wenn du Fragen hast oder ein Projekt mit der API baust — ich helfe gerne weiter!

Ich habe einen kostenlosen Strompreis-Rechner gebaut — hier sind die echten Daten

Nevik Schmidt — Thu, 30 Jul 2026 14:44:38 +0000

Ich habe einen kostenlosen Strompreis-Rechner gebaut — hier sind die echten Daten

Wer in Deutschland Strom bezieht, zahlt nicht einfach nur für die Kilowattstunde. Der Strompreis ist ein komplexes Konstrukt aus Netzentgelten, Abgaben, Steuern und Umlagen — und genau diese Transparenz fehlt den meisten Verbrauchern. Deshalb habe ich einen interaktiven Strompreis-Rechner gebaut, der den vollständigen Preis-Breakdown visualisiert.

👉 Live-Demo: strom.nevik.de/strompreis-rechner

In diesem Artikel zeige ich dir, wie der Rechner technisch funktioniert, welche Architektur dahintersteckt und wie du einen ähnlichen interaktiven Visualisierungs-Rechner selbst bauen kannst.

Das Problem: Strompreistransparenz in Deutschland

Der durchschnittliche Strompreis in Deutschland lag 2024 bei rund 40 Cent pro kWh. Aber was steckt in diesen 40 Cent? Hier ist der typische Breakdown:

Komponente	Anteil	Cent/kWh
Strombeschaffung & Vertrieb	~25%	~10,0
Netzentgelte	~22%	~8,8
Mehrwertsteuer (19%)	~16%	~6,4
Stromsteuer	~14%	~5,6
Konzessionsabgabe	~5%	~2,0
KWK-Umlage & Sonstige	~18%	~7,2

Diese Zahlen ändern sich regional und saisonal. Genau hier setzt mein Rechner an: Er nutzt aktuelle, tagesaktuelle Daten über eine eigene API und berechnet den Breakdown dynamisch.

Die Architektur: Vanilla JS + SVG statt Framework-Overhead

Ich habe bewusst auf ein schweres Framework verzichtet. Der Rechner besteht aus:

Vanilla JavaScript (~400 Zeilen) — keine Build-Tools, kein npm
SVG-Charts — handgezeichnet, keine Charting-Library
CSS Custom Properties — für theming und Animationen
Fetch-API — für die Datenanbindung an meine eigene Strompreis-API

Warum kein React oder Vue? Für einen Single-Purpose-Rechner ist das Overkill. Die Seite lädt in unter 200ms, und der gesamte Code ist in einer einzigen HTML-Datei verständlich.

Der interaktive Breakdown-Rechner

Das Herzstück ist der Slider, mit dem Nutzer ihren Jahresverbrauch einstellen. Bei jeder Änderung wird der komplette Breakdown neu berechnet und animiert.

Hier ist die Kernlogik:

// Strompreis-Breakdown berechnen
function calculateBreakdown(consumptionKwh, pricePerKwh) {
  const total = consumptionKwh * pricePerKwh;

  // Prozentsätze basierend auf BNetzA-Daten
  const breakdown = {
    strombeschaffung: total * 0.25,
    netzentgelte: total * 0.22,
    mehrwertsteuer: total * 0.16,
    stromsteuer: total * 0.14,
    konzessionsabgabe: total * 0.05,
    sonstige: total * 0.18
  };

  return breakdown;
}

// Slider-Event verarbeiten
const slider = document.getElementById('consumption-slider');

slider.addEventListener('input', (e) => {
  const kwh = parseInt(e.target.value);
  const price = await fetchCurrentPrice();
  const breakdown = calculateBreakdown(kwh, price);

  renderSVGChart(breakdown);
  renderCostTable(breakdown);
});

Die Magie passiert im Event-Listener: Jede Slider-Bewegung triggert eine Neuberechnung und ein re-render des SVG-Charts.

SVG-Charts von Hand bauen

Die meisten Entwickler greifen bei Charts sofort zu Chart.js, D3 oder Recharts. Für diesen Rechner wollte ich volle Kontrolle über die Animationen — also habe ich das SVG direkt generiert.

Ein animiertes Balkendiagramm mit Vanilla JS sieht so aus:

function renderSVGChart(breakdown) {
  const svg = document.getElementById('price-chart');
  const max = Math.max(...Object.values(breakdown));
  const barWidth = 60;
  const gap = 20;
  const chartHeight = 300;

  let html = '';
  let x = 20;

  for (const [label, value] of Object.entries(breakdown)) {
    const barHeight = (value / max) * chartHeight;
    const y = chartHeight - barHeight;

    html += `
      <rect x="${x}" y="${y}" width="${barWidth}" height="${barHeight}"
            fill="url(#bar-gradient)" rx="4"
            style="transition: all 0.4s cubic-bezier(0.4, 0, 0.2, 1);">
        <animate attributeName="height" from="0" to="${barHeight}" dur="0.6s"/>
      </rect>
      <text x="${x + barWidth/2}" y="${chartHeight + 20}" 
            text-anchor="middle" fill="#666" font-size="12">
        ${formatLabel(label)}
      </text>
    `;
    x += barWidth + gap;
  }

  svg.innerHTML = html;
}

Der Vorteil: Die Animation läuft über CSS-Transitions und das SVG <animate>-Element, was buttery smooth läuft — ohne JavaScript-Animation-Loop.

Die Datenquelle: Eine eigene Strompreis-API

Der Rechner wäre ohne aktuelle Daten wertlos. Deshalb betreibe ich eine eigene kostenlose Strompreis-API mit tagesaktuellen Durchschnittspreisen für Deutschland.

Die API ist CORS-enabled und liefert sauberes JSON:

curl https://strom.nevik.de/api/

{
  "strompreis_ct_kwh": 39.42,
  "strompreis_eur_kwh": 0.3942,
  "datum": "2025-01-15",
  "quelle": "BNetzA, SMARD, EEX",
  "aufschluesselung": {
    "strombeschaffung_vertrieb": { "prozent": 25.0, "ct_kwh": 9.85 },
    "netzentgelte": { "prozent": 22.0, "ct_kwh": 8.67 },
    "mehrwertsteuer": { "prozent": 16.0, "ct_kwh": 6.31 }
  }
}
``"

Die API hat drei Endpoints und ist komplett kostenlos nutzbar. Mehr Details dazu in meinem nächsten Artikel: [Wie ich eine kostenlose Strompreis-API für Deutschland gebaut habe](#).

---

## UX-Details, die den Unterschied machen

Ein guter Rechner ist mehr als nur Mathematik. Hier sind Designentscheidungen, die die Nutzererfahrung deutlich verbessern:

### 1. Sofortiges Feedback beim Slider

Jede Bewegung aktualisiert die Visualisierung in Echtzeit. Kein "Berechnen"-Button, keine Ladeanimation. Das Gehirn sucht nach Cause-and-Effect — und der Slider liefert es sofort.

### 2. Vergleichswerte als Kontext

Ein isolierter Zahlenwert ist bedeutungslos. Deshalb zeigt der Rechner immer Vergleichswerte:

- *"Das ist X% mehr als der Bundesdurchschnitt"*
- *"Entspricht dem Verbrauch von Y Haushalten"*
- *"CO₂-Äquivalent: Z kg"*

### 3. Animierter Zahlen-Countup

Wenn sich der Wert ändert, zählt er nicht einfach um — er animiert vom alten zum neuen Wert:

javascript
function animateValue(element, start, end, duration = 600) {
const range = end - start;
const startTime = performance.now();

function update(currentTime) {
const elapsed = currentTime - startTime;
const progress = Math.min(elapsed / duration, 1);
// easeOutCubic für angenehme Animation
const eased = 1 - Math.pow(1 - progress, 3);
const current = start + range * eased;

element.textContent = current.toFixed(2) + ' €';

if (progress < 1) requestAnimationFrame(update);

}

requestAnimationFrame(update);
}


### 4. Mobile-First responsive

Der Rechner funktioniert auf dem Smartphone genauso gut wie am Desktop. Die SVG-Charts skalieren über `viewBox` automatisch, und der Slider ist touch-optimiert mit `input[type=range]`.

---

## Performance: 0.2 Sekunden Ladezeit

Hier ist der Performance-Check:

| Metrik | Wert |
|---|---|
| First Contentful Paint | ~180ms |
| Time to Interactive | ~220ms |
| Total bundle size | < 15 KB (ungezippt) |
| JavaScript payload | ~8 KB |
| External dependencies | 0 |

Keine Frameworks, keine Build-Tools, keine Dependencies. Das ist möglich, wenn man bewusst auf Komplexität verzichtet.

---

## Technische Herausforderungen

### Herausforderung 1: Datenaktualität ohne Caching-Probleme

Strompreise ändern sich nicht sekündlich, aber Nutzer erwarten aktuelle Daten. Die Lösung: Die API cached serverseitig für 1 Stunde mit klar definierten Cache-Headers:

http
Cache-Control: public, max-age=3600
Stale-while-revalidate: 86400


### Herausforderung 2: SVG-Animationen performant halten

Bei schnellen Slider-Bewegungen kann die SVG-Regeneration zum Performance-Bottleneck werden. Die Lösung: **Debouncing** mit `requestAnimationFrame`:

javascript
let rafId = null;

function debouncedRender(breakdown) {
if (rafId) cancelAnimationFrame(rafId);
rafId = requestAnimationFrame(() => {
renderSVGChart(breakdown);
rafId = null;
});
}




So werden nur Render-Cycles ausgeführt, die auch wirklich auf dem Bildschirm landen.

---

## Was du für deinen eigenen Rechner brauchst

Wenn du einen ähnlichen interaktiven Rechner bauen willst — egal ob für Strompreis, Heizkosten oder Steuerlast — hier ist der minimale Stack:

1. **HTML** mit einem `<input type="range">` und einem leeren `<svg>`
2. **Vanilla JS** mit Fetch + Event Listeners (~200 Zeilen)
3. **Eine Datenquelle** (eigene API oder statische JSON-Datei)
4. **CSS-Transitions** für Animationen
5. **Keine Build-Tools** — einfach eine `.html`-Datei

Der gesamte Code meines Rechners ist weniger als 400 Zeilen JavaScript. Du kannst das Konzept auf jeden Datensatz übertragen.

---

## Fazit und nächste Schritte

Der Strompreis-Rechner auf [strom.nevik.de/strompreis-rechner](https://strom.nevik.de/strompreis-rechner/) zeigt, dass man für datengetriebene Web-Tools keine schweren Frameworks braucht. Mit Vanilla JS, SVG und einer soliden Daten-API lassen sich beeindruckende interaktive Visualisierungen bauen.

Die wichtigsten Takeaways:

- **Transparenz schafft Vertrauen** — Nutzer verstehen ihren Strompreis besser, wenn sie den Breakdown sehen
- **Echtzeit-Interaktion** ist mit Vanilla JS problemlos möglich
- **SVG-Charts von Hand** geben volle Kontrolle über Animationen und Styling
- **Eine gute Datenquelle** ist die halbe Miete

Wenn dich die API hinter dem Rechner interessiert, lies meinen Artikel über den Bau der Strompreis-API. Und probiere den Rechner selbst aus:

🔗 **[Strompreis-Rechner ausprobieren](https://strom.nevik.de/strompreis-rechner/)**

🔗 **[Strompreis-API Dokumentation](https://strom.nevik.de/api/)**

Wenn du Fragen zum Code oder zur Architektur hast, schreib gerne einen Kommentar. Ich erkläre gerne jedes Detail.

---

*Viel Spaß beim Strompreise vergleichen und beim Bauen eigener interaktiver Rechner!*

Stromvergleich Test

Nevik Schmidt — Thu, 30 Jul 2026 14:43:03 +0000

Ein Test-Artikel über Stromvergleich.

Ich habe einen kostenlosen Strompreis-Rechner gebaut — hier sind die echten Daten

Nevik Schmidt — Thu, 30 Jul 2026 14:38:50 +0000

Ich habe einen kostenlosen Strompreis-Rechner gebaut — hier sind die echten Daten

👉 Live-Demo: strom.nevik.de/strompreis-rechner

In diesem Artikel zeige ich dir, wie der Rechner technisch funktioniert, welche Architektur dahintersteckt und wie du einen ähnlichen interaktiven Visualisierungs-Rechner selbst bauen kannst.

Das Problem: Strompreistransparenz in Deutschland

Der durchschnittliche Strompreis in Deutschland lag 2024 bei rund 40 Cent pro kWh. Aber was steckt in diesen 40 Cent? Hier ist der typische Breakdown:

Komponente	Anteil	Cent/kWh
Strombeschaffung & Vertrieb	~25%	~10,0
Netzentgelte	~22%	~8,8
Mehrwertsteuer (19%)	~16%	~6,4
Stromsteuer	~14%	~5,6
Konzessionsabgabe	~5%	~2,0
KWK-Umlage & Sonstige	~18%	~7,2

Diese Zahlen ändern sich regional und saisonal. Genau hier setzt mein Rechner an: Er nutzt aktuelle, tagesaktuelle Daten über eine eigene API und berechnet den Breakdown dynamisch.

Die Architektur: Vanilla JS + SVG statt Framework-Overhead

Ich habe bewusst auf ein schweres Framework verzichtet. Der Rechner besteht aus:

Vanilla JavaScript (~400 Zeilen) — keine Build-Tools, kein npm
SVG-Charts — handgezeichnet, keine Charting-Library
CSS Custom Properties — für theming und Animationen
Fetch-API — für die Datenanbindung an meine eigene Strompreis-API

Warum kein React oder Vue? Für einen Single-Purpose-Rechner ist das Overkill. Die Seite lädt in unter 200ms, und der gesamte Code ist in einer einzigen HTML-Datei verständlich.

Der interaktive Breakdown-Rechner

Das Herzstück ist der Slider, mit dem Nutzer ihren Jahresverbrauch einstellen. Bei jeder Änderung wird der komplette Breakdown neu berechnet und animiert.

Hier ist die Kernlogik:

// Strompreis-Breakdown berechnen
function calculateBreakdown(consumptionKwh, pricePerKwh) {
  const total = consumptionKwh * pricePerKwh;

  // Prozentsätze basierend auf BNetzA-Daten
  const breakdown = {
    strombeschaffung: total * 0.25,
    netzentgelte: total * 0.22,
    mehrwertsteuer: total * 0.16,
    stromsteuer: total * 0.14,
    konzessionsabgabe: total * 0.05,
    sonstige: total * 0.18
  };

  return breakdown;
}

// Slider-Event verarbeiten
const slider = document.getElementById('consumption-slider');

slider.addEventListener('input', (e) => {
  const kwh = parseInt(e.target.value);
  const price = await fetchCurrentPrice();
  const breakdown = calculateBreakdown(kwh, price);

  renderSVGChart(breakdown);
  renderCostTable(breakdown);
});

Die Magie passiert im Event-Listener: Jede Slider-Bewegung triggert eine Neuberechnung und ein re-render des SVG-Charts.

SVG-Charts von Hand bauen

Die meisten Entwickler greifen bei Charts sofort zu Chart.js, D3 oder Recharts. Für diesen Rechner wollte ich volle Kontrolle über die Animationen — also habe ich das SVG direkt generiert.

Ein animiertes Balkendiagramm mit Vanilla JS sieht so aus:

function renderSVGChart(breakdown) {
  const svg = document.getElementById('price-chart');
  const max = Math.max(...Object.values(breakdown));
  const barWidth = 60;
  const gap = 20;
  const chartHeight = 300;

  let html = '';
  let x = 20;

  for (const [label, value] of Object.entries(breakdown)) {
    const barHeight = (value / max) * chartHeight;
    const y = chartHeight - barHeight;

    html += `
      <rect x="${x}" y="${y}" width="${barWidth}" height="${barHeight}"
            fill="url(#bar-gradient)" rx="4"
            style="transition: all 0.4s cubic-bezier(0.4, 0, 0.2, 1);">
        <animate attributeName="height" from="0" to="${barHeight}" dur="0.6s"/>
      </rect>
      <text x="${x + barWidth/2}" y="${chartHeight + 20}" 
            text-anchor="middle" fill="#666" font-size="12">
        ${formatLabel(label)}
      </text>
    `;
    x += barWidth + gap;
  }

  svg.innerHTML = html;
}

Der Vorteil: Die Animation läuft über CSS-Transitions und das SVG <animate>-Element, was buttery smooth läuft — ohne JavaScript-Animation-Loop.

Die Datenquelle: Eine eigene Strompreis-API

Der Rechner wäre ohne aktuelle Daten wertlos. Deshalb betreibe ich eine eigene kostenlose Strompreis-API mit tagesaktuellen Durchschnittspreisen für Deutschland.

Die API ist CORS-enabled und liefert sauberes JSON:

curl https://strom.nevik.de/api/

{
  "strompreis_ct_kwh": 39.42,
  "strompreis_eur_kwh": 0.3942,
  "datum": "2025-01-15",
  "quelle": "BNetzA, SMARD, EEX",
  "aufschluesselung": {
    "strombeschaffung_vertrieb": { "prozent": 25.0, "ct_kwh": 9.85 },
    "netzentgelte": { "prozent": 22.0, "ct_kwh": 8.67 },
    "mehrwertsteuer": { "prozent": 16.0, "ct_kwh": 6.31 }
  }
}
``"

Die API hat drei Endpoints und ist komplett kostenlos nutzbar. Mehr Details dazu in meinem nächsten Artikel: [Wie ich eine kostenlose Strompreis-API für Deutschland gebaut habe](#).

---

## UX-Details, die den Unterschied machen

Ein guter Rechner ist mehr als nur Mathematik. Hier sind Designentscheidungen, die die Nutzererfahrung deutlich verbessern:

### 1. Sofortiges Feedback beim Slider

Jede Bewegung aktualisiert die Visualisierung in Echtzeit. Kein "Berechnen"-Button, keine Ladeanimation. Das Gehirn sucht nach Cause-and-Effect — und der Slider liefert es sofort.

### 2. Vergleichswerte als Kontext

Ein isolierter Zahlenwert ist bedeutungslos. Deshalb zeigt der Rechner immer Vergleichswerte:

- *"Das ist X% mehr als der Bundesdurchschnitt"*
- *"Entspricht dem Verbrauch von Y Haushalten"*
- *"CO₂-Äquivalent: Z kg"*

### 3. Animierter Zahlen-Countup

Wenn sich der Wert ändert, zählt er nicht einfach um — er animiert vom alten zum neuen Wert:

javascript
function animateValue(element, start, end, duration = 600) {
const range = end - start;
const startTime = performance.now();

element.textContent = current.toFixed(2) + ' €';

if (progress < 1) requestAnimationFrame(update);

}

requestAnimationFrame(update);
}


### 4. Mobile-First responsive

Der Rechner funktioniert auf dem Smartphone genauso gut wie am Desktop. Die SVG-Charts skalieren über `viewBox` automatisch, und der Slider ist touch-optimiert mit `input[type=range]`.

---

## Performance: 0.2 Sekunden Ladezeit

Hier ist der Performance-Check:

| Metrik | Wert |
|---|---|
| First Contentful Paint | ~180ms |
| Time to Interactive | ~220ms |
| Total bundle size | < 15 KB (ungezippt) |
| JavaScript payload | ~8 KB |
| External dependencies | 0 |

Keine Frameworks, keine Build-Tools, keine Dependencies. Das ist möglich, wenn man bewusst auf Komplexität verzichtet.

---

## Technische Herausforderungen

### Herausforderung 1: Datenaktualität ohne Caching-Probleme

Strompreise ändern sich nicht sekündlich, aber Nutzer erwarten aktuelle Daten. Die Lösung: Die API cached serverseitig für 1 Stunde mit klar definierten Cache-Headers:

http
Cache-Control: public, max-age=3600
Stale-while-revalidate: 86400


### Herausforderung 2: SVG-Animationen performant halten

Bei schnellen Slider-Bewegungen kann die SVG-Regeneration zum Performance-Bottleneck werden. Die Lösung: **Debouncing** mit `requestAnimationFrame`:

javascript
let rafId = null;

function debouncedRender(breakdown) {
if (rafId) cancelAnimationFrame(rafId);
rafId = requestAnimationFrame(() => {
renderSVGChart(breakdown);
rafId = null;
});
}




So werden nur Render-Cycles ausgeführt, die auch wirklich auf dem Bildschirm landen.

---

## Was du für deinen eigenen Rechner brauchst

Wenn du einen ähnlichen interaktiven Rechner bauen willst — egal ob für Strompreis, Heizkosten oder Steuerlast — hier ist der minimale Stack:

1. **HTML** mit einem `<input type="range">` und einem leeren `<svg>`
2. **Vanilla JS** mit Fetch + Event Listeners (~200 Zeilen)
3. **Eine Datenquelle** (eigene API oder statische JSON-Datei)
4. **CSS-Transitions** für Animationen
5. **Keine Build-Tools** — einfach eine `.html`-Datei

Der gesamte Code meines Rechners ist weniger als 400 Zeilen JavaScript. Du kannst das Konzept auf jeden Datensatz übertragen.

---

## Fazit und nächste Schritte

Der Strompreis-Rechner auf [strom.nevik.de/strompreis-rechner](https://strom.nevik.de/strompreis-rechner/) zeigt, dass man für datengetriebene Web-Tools keine schweren Frameworks braucht. Mit Vanilla JS, SVG und einer soliden Daten-API lassen sich beeindruckende interaktive Visualisierungen bauen.

Die wichtigsten Takeaways:

- **Transparenz schafft Vertrauen** — Nutzer verstehen ihren Strompreis besser, wenn sie den Breakdown sehen
- **Echtzeit-Interaktion** ist mit Vanilla JS problemlos möglich
- **SVG-Charts von Hand** geben volle Kontrolle über Animationen und Styling
- **Eine gute Datenquelle** ist die halbe Miete

Wenn dich die API hinter dem Rechner interessiert, lies meinen Artikel über den Bau der Strompreis-API. Und probiere den Rechner selbst aus:

🔗 **[Strompreis-Rechner ausprobieren](https://strom.nevik.de/strompreis-rechner/)**

🔗 **[Strompreis-API Dokumentation](https://strom.nevik.de/api/)**

Wenn du Fragen zum Code oder zur Architektur hast, schreib gerne einen Kommentar. Ich erkläre gerne jedes Detail.

---

*Viel Spaß beim Strompreise vergleichen und beim Bauen eigener interaktiver Rechner!*