Forem: Andrés Clúa

Web Performance Is an Architecture Decision, Not a Last-Minute Fix

Andrés Clúa — Mon, 13 Apr 2026 14:08:51 +0000

I work at a digital agency and lead the tech side. One thing we try to get right from day one is performance. Not because we're obsessed with Lighthouse scores. Because we've learned that performance problems don't come from bad code. They come from bad decisions made early in the project.

The CMS you choose. How you handle third-party scripts. Whether you serve videos as raw iframes or defer them. How your CSS is loaded. Where your assets live.

These are architecture decisions. And once they're made, they're expensive to undo.

The Pattern We Try to Avoid

Here's what happens on a lot of projects across the industry. A site launches. The design looks great. Then someone runs a Lighthouse audit and the score is 43. Panic. Everyone wants to "fix performance" like it's a bug you can patch on a Friday afternoon.

It's not a bug. It's the consequence of choices nobody questioned months ago.

We try not to end up there. That means asking the uncomfortable questions at the kickoff, not at the QA stage. It means pushing back sometimes. And it means being honest about what certain tools and platforms cost you in performance before you commit to them.

Your CMS Choice Is a Performance Decision

This is the one that doesn't get enough attention. People choose a CMS based on features, familiarity, or client preference. Performance rarely enters the conversation. But it should. Because some platforms give you a head start and others put you in a hole from the beginning.

A headless CMS like Sanity, Contentful, or Storyblok gives you full control over the frontend. You decide what gets loaded, when, and how. There's no theme layer injecting scripts you didn't ask for. No plugin ecosystem silently adding database queries and stylesheets on every page load.

WordPress can absolutely be fast. I've built fast WordPress sites. But it takes discipline. The default experience is a theme that loads everything everywhere, a page builder that inlines CSS for every block variation, and a plugin for every feature that each adds its own JavaScript and stylesheet. Out of the box, a typical WordPress site with a popular theme, a form plugin, an SEO plugin, and a slider is already shipping 2MB+ of assets before you add any actual content.

That doesn't mean WordPress is bad. It means you have to fight harder for performance on WordPress than on a headless setup. And if you're not aware of that going in, you'll end up with a 43 on Lighthouse wondering what happened.

The honest breakdown from what I've seen:

Headless CMS (Sanity, Contentful, Storyblok): You own the frontend. Performance is in your hands. The CMS doesn't inject anything into your build. If it's slow, it's your fault. That's actually a good thing.

WordPress: Can be fast, but requires intentional architecture. Block themes perform better than classic themes. Avoid heavy page builders if performance matters. Audit every plugin. Know what each one adds to the page weight.

Monolithic platforms (Drupal, AEM, Sitecore): Similar challenges to WordPress but at enterprise scale. More moving parts. More potential for bloat. Performance is achievable but requires dedicated effort and expertise.

Static site generators (Astro, Nuxt, Next.js in SSG mode): The fastest option by default because you're serving pre-built HTML. But the moment you start adding client-side interactivity and third-party scripts, you can still ruin it.

The point is not that one CMS is better than another. The point is that the CMS decision is a performance decision, and it should be evaluated as one.

The YouTube Embed Problem

Here's a concrete example that comes up constantly. A client site scoring poorly on Core Web Vitals. We investigate. The biggest offender? YouTube embeds.

A standard YouTube iframe loads around 800KB of JavaScript before the user even clicks play. That's one embed. Put four on a page and the browser is downloading over 3MB of scripts for videos most visitors will never watch.

LCP tanks. INP suffers because the main thread is busy parsing scripts nobody asked for. The page feels slow because it is slow.

The fix: don't load the iframe until the user wants to watch. Show a placeholder. Load on click. Reserve the space with aspect-ratio: 16/9 so there's no layout shift.

This is one of the things I built Boostify.js to solve. Instead of dropping a raw YouTube iframe in your markup, you set up a container and let Boostify handle the deferred loading:

<div
  class="js--boostify-embed"
  style="aspect-ratio: 16/9;"
  data-url-youtube="https://www.youtube.com/embed/dQw4w9WgXcQ">
</div>

const bstf = new Boostify();

document.querySelectorAll('.js--boostify-embed').forEach(element => {
  bstf.videoEmbed({
    url: element.getAttribute('data-url-youtube'),
    autoplay: true,
    appendTo: element,
    style: { height: "auto" }
  });
});

Zero bytes of YouTube JavaScript loaded until the user interacts. The space is reserved so no layout shift. The page loads as if the video isn't there. When the user clicks, the embed loads instantly.

This needs to be a default in your component library, not a fix applied after someone complains about the Lighthouse score.

Third-Party Scripts: The Invisible Weight

YouTube is obvious because you can see it. But the worst offenders are invisible.

Google Analytics. Facebook Pixel. Hotjar. Microsoft Clarity. HubSpot tracking. LinkedIn Insight Tag. Cookie consent banners. Chat widgets. A/B testing tools.

On a typical site, I've counted 8 to 12 third-party scripts loading on every page. Each one competes for the main thread. Each one makes network requests. Each one adds weight.

None of these are critical for the user's first interaction. The user came to read content, check services, fill out a form. They didn't come so Hotjar could record their session before the page renders.

But these scripts are usually dropped straight into the <head>. Render-blocking. Loading before your actual content.

<!-- What I see on most sites when I open the source -->
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"></script>
<script src="https://connect.facebook.net/en_US/fbevents.js"></script>
<script src="https://static.hotjar.com/c/hotjar-XXXXX.js"></script>
<!-- The page hasn't started rendering yet -->

With Boostify, you mark your tracking scripts with type="text/boostify" instead of type="text/javascript". The browser ignores them on load. Boostify picks them up and loads them only after the user interacts with the page (mouse move, scroll, touch).

<!-- Deferred until user interaction -->
<script type="text/boostify" src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"></script>

const bstf = new Boostify();

bstf.onload({
  worker: true,
  callback: (result) => {
    console.log('Third-party scripts loaded after user interaction');
  }
});

Your content renders immediately. Analytics loads quietly in the background when the user is already engaged. You might lose tracking on 1-2% of ultra-fast bounces, but your site is faster, which typically increases conversions overall.

My recommendation: consolidate everything into a single Google Tag Manager container, mark that one script with type="text/boostify", and let GTM handle all your tags internally. One deferred script instead of twelve blocking ones.

Loading the Right Thing at the Right Time

The onload trigger handles the global stuff like analytics and tracking. But a real page has more than that. It has a slider halfway down. A contact form with a map at the bottom. An interactive widget in a section most users never scroll to.

This is where Boostify's scroll and observer triggers come in, and where things get interesting when you combine them.

Scroll trigger: fire a callback when the user scrolls past a certain distance. Good for loading resources that you know the user will need soon, like a slider component just below the fold.

bstf.scroll({
  distance: 200,
  callback: async () => {
    // Load slider CSS and JS only when user starts scrolling
    await bstf.loadStyle({
      url: 'https://cdnjs.cloudflare.com/ajax/libs/tiny-slider/2.9.4/tiny-slider.css',
      attributes: ['media=all'],
      appendTo: 'head'
    });
    await bstf.loadScript({
      url: 'https://cdnjs.cloudflare.com/ajax/libs/tiny-slider/2.9.2/min/tiny-slider.js',
      attributes: ['type="text/javascript"'],
      appendTo: 'body'
    });

    // Initialize once loaded
    tns({
      container: '.my-slider',
      items: 3,
      slideBy: 'page',
      autoplay: true
    });
  }
});

Observer trigger: fire a callback when a specific element enters the viewport. This uses the Intersection Observer API under the hood. Perfect for content further down the page that may or may not be reached.

bstf.observer({
  options: {
    root: null,
    rootMargin: '0px',
    threshold: 0.01
  },
  element: document.querySelector('.contact-section'),
  callback: async () => {
    // Load the map embed only when the contact section is visible
    bstf.videoEmbed({
      url: 'https://www.google.com/maps/embed?pb=YOUR_MAP_EMBED',
      appendTo: document.querySelector('.map-container'),
      style: { height: '400px' }
    });
  }
});

The real power is using all three together. Think about a typical landing page:

const bstf = new Boostify();

// 1. Analytics and tracking: defer until first user interaction
bstf.onload({ worker: true });

// 2. Below-the-fold slider: load when user starts scrolling
bstf.scroll({
  distance: 300,
  callback: async () => {
    await bstf.loadStyle({ url: '/css/slider.css', appendTo: 'head' });
    await bstf.loadScript({ url: '/js/slider.js', appendTo: 'body' });
  }
});

// 3. YouTube video in the middle: load when its section is visible
bstf.observer({
  element: document.querySelector('.video-section'),
  options: { threshold: 0.01 },
  callback: () => {
    bstf.videoEmbed({
      url: 'https://www.youtube.com/embed/dQw4w9WgXcQ',
      autoplay: true,
      appendTo: document.querySelector('.video-container'),
      style: { height: 'auto' }
    });
  }
});

// 4. Contact form with map: load only if user reaches the bottom
bstf.observer({
  element: document.querySelector('.contact-section'),
  options: { threshold: 0.01 },
  callback: async () => {
    await bstf.loadScript({ url: '/js/form-validation.js', appendTo: 'body' });
    await bstf.loadStyle({ url: '/css/form.css', appendTo: 'head' });
  }
});

On initial page load, the browser downloads your HTML, your critical CSS, and your above-the-fold content. That's it. Everything else loads exactly when it's needed.

This isn't micro-optimization. On a page with a slider, two video embeds, a map, and eight tracking scripts, the difference between loading everything upfront and loading it progressively can be 4-5MB of JavaScript. That's the difference between a 2-second load and an 8-second load on mobile.

And it's an architecture decision. You set it up once in your component system. Every page benefits from it automatically.

CLS: Where Your CMS Shows Its True Colors

Cumulative Layout Shift exposes bad architecture more clearly than any other metric.

You know the experience. You're about to click a button and the page jumps because something loaded above it. A font swaps in and the layout shifts. An image loads without dimensions and pushes everything down.

This is where CMS choice really matters. A good CMS setup enforces constraints that prevent CLS. A bad one lets editors do whatever they want and hopes for the best.

If your CMS lets editors drop iframes anywhere without aspect ratio containers, you'll have CLS problems. If your theme doesn't enforce image dimensions, you'll have CLS problems. If your font loading strategy is "link to Google Fonts in the head," you'll have CLS problems.

The fix isn't a CSS hack after launch. It's building the system so these issues can't happen.

/* Defaults that should exist in every project */
img, video {
  max-width: 100%;
  height: auto;
}

.embed-container {
  aspect-ratio: 16 / 9;
  width: 100%;
}

On a headless setup, you control the component layer. You can enforce these patterns at the component level. On WordPress, you need to be more careful with theme defaults and block output. On page builder-heavy setups, good luck.

INP: The Metric That Exposes JavaScript Bloat

Interaction to Next Paint replaced First Input Delay in 2024. It's harder to pass because it measures the responsiveness of all interactions, not just the first one.

That hamburger menu that takes 400ms to respond? INP catches it. The accordion that freezes before opening? INP catches that too.

In 2026, pages at position 1 on Google show a 10% higher Core Web Vitals pass rate than those at position 9. Only 47% of sites reach Google's "good" thresholds across all three metrics. More than half the web is failing.

The most common INP killer is too much JavaScript on the main thread. Not just third-party scripts. First-party JavaScript too. Heavy page builders that inline JS for every component. Animations running on the main thread. Event listeners doing too much work synchronously.

This is another place where CMS architecture matters. A site built with a lightweight frontend framework on top of a headless CMS will naturally ship less JavaScript than a WordPress site running a page builder with 40 registered block types, each loading its own script.

And this is exactly why progressive loading matters. If you defer everything that's not immediately needed (using the onload, scroll, and observer pattern described above), the main thread is free to handle user interactions without competing for resources. INP improves because the browser isn't busy parsing tracking scripts and slider libraries while the user is trying to click things.

Performance Budgets at the Kickoff

I've never seen a creative brief that includes a performance budget. Not once across any project in any agency.

Nobody says "this page should load in under 2.5 seconds on a mid-range Android phone on 4G." But that's how Google evaluates your site. Mobile performance is the primary ranking signal. Even for desktop results.

53% of mobile visitors abandon a site that takes more than 3 seconds to load. A one-second delay reduces conversions by 7%. For a site generating $100K/month, that's $84K lost per year. For one second.

These numbers belong in every project kickoff. We try to set targets early:

LCP under 2.5s on mobile
INP under 200ms
CLS under 0.1
Total page weight under 1.5MB
No more than 3 third-party scripts loading before first paint

These aren't aggressive. They're the thresholds Google considers "good." Most sites don't hit them because nobody set them as a goal.

Field Data vs Lab Data

One more thing. Stop obsessing over Lighthouse scores in isolation.

Lighthouse is lab data. It runs in a simulated environment. It's useful for diagnostics. But Google ranks you based on field data. Real users on real devices with real network conditions.

Your Lighthouse score might be 90 because you tested on your MacBook with fiber internet. But your field data in Search Console might show real users on mid-range phones getting an LCP of 4.2 seconds.

Field data is what matters. Check your Core Web Vitals report in Search Console. That's the real score.

The Takeaway

Performance is not a task at the end. It's not a sprint before launch. It's not a plugin.

It starts with the CMS you choose and how you set it up. It continues with how you handle scripts, images, fonts, and video. It lives in your component architecture, your loading strategy, your defaults.

Some platforms make this easier. Some make it harder. Neither is inherently wrong, but you need to know the tradeoffs before you commit.

By the time someone opens DevTools and says "why is this so slow," the answer is usually "because we never decided it should be fast."

Make that decision early. Make it part of the architecture. Hold every choice accountable to it.

Boostify.js is free and open source. All the loading patterns described in this article (deferred third-party scripts, scroll triggers, observer-based loading, video embed placeholders) are available out of the box. Check it out on GitHub.

EmDash Is Not Your Next CMS. It Might Be the One After That

Andrés Clúa — Mon, 06 Apr 2026 17:20:55 +0000

Everyone is talking about EmDash. Serverless, sandboxed plugins, AI-first. Cool. I get it.

I work at a digital agency. We've been building on WordPress for years. Also Sanity, Contentful, Storyblok, Drupal, AEM. We've tried a lot. So when something new shows up, I don't get hyped that fast. I just want to know: can I use this for a real project?

We don't pick favorites

There's no "best CMS." Every project is different.

WordPress is a great tool, we build custom plugins, custom post types, REST API endpoints, tailored admin panels. It's not a blogging platform for us. It's a framework. So when people compare WordPress to newer tools by pointing at Gutenberg or starter themes... they're looking at one layer. That's not how we work with it.

Sanity is great when content modeling gets complex. Storyblok has a really nice visual editor that clients actually enjoy using. Contentful works when the client needs a clean API-first layer and doesn't want to deal with hosting. Drupal taught us a lot about structured content before headless was even a thing.

AEM is enterprise. Enterprise scale, enterprise money. It solves problems that other platforms don't even try to solve.

We picked each one for a reason.

What I like about EmDash

There are some ideas in EmDash that are genuinely interesting.

Serverless by default. No more dealing with PHP memory limits or server configs. That's nice.

Sandboxed plugins. Plugins run in isolation. No more "one plugin broke the whole site" at 2am. That alone is a big deal.

AI built into the core. Not a plugin wrapping an API. AI is part of the architecture. That opens up real possibilities for content generation and automation.

I like where this is going.

What makes me wait

But when I think about using #EmDash for a client project right now, there are a few things.

The ecosystem is basically empty. WordPress has thousands of plugins. Sanity and Contentful have mature integrations. EmDash is starting from zero. When you have a client deadline, that matters a lot.

It's developer-first. TypeScript, Astro, edge functions. And look, I love Astro. I still smile every time I see a project we built for UNDP in the Astro showcase. My team can work with all of that. But we also need to hand things over to marketing teams. They need to update pages and publish content without calling us every time. WordPress and Contentful have been refining that for years. EmDash hasn't.

It's tied to Cloudflare. WordPress runs on any hosting. Sanity and Contentful are SaaS. EmDash depends on the Cloudflare ecosystem. That's a dependency I'd think twice about for client work.

It takes longer to ship. We can go from kickoff to a working WordPress site with custom content types in days. With a new platform, there's always a learning curve. When a client has a launch date, that time gap is real.

It's not about good or bad

I'm not saying EmDash is bad. I think it's one of the most interesting things I've seen in the CMS space in a while. The architecture makes sense. The vision is clear.

But picking a CMS for client work is not just about architecture. It's about ecosystem, team readiness, how easy it is for the client, and whether this thing will still work in three years. Those things take time.

Where I'd try it

Internal projects. A proof of concept. Something where we control the timeline and the scope. That's how we've always adopted new tools. We learn them in low-risk contexts first.

If you care about developer experience, EmDash is worth exploring now. Not for your next client project. As a sandbox. Play with the serverless model, the plugin patterns, the AI workflows. The best time to learn a tool is before you need it on a deadline.

If the ecosystem grows, I can see EmDash sitting next to WordPress, Sanity, and Contentful in our toolkit. The ideas are solid. It just needs time.

One more thing

If you haven't tried Sanity, Contentful, Storyblok, or Drupal, go try them. Seriously. Yeah, 80% of content modeling feels the same across platforms. But that other 20% is where you learn things you wouldn't learn otherwise. Each one gives you a different perspective on how content should work.

AEM too, if you can afford the license. I'd say try it on something small, a personal project, just to see what's inside.

And here's something that would have sounded crazy two years ago: building your own CMS is actually possible now. With AI and a small team of solid developers who know how to use it, you can build exactly what you need. Your integrations. Your workflows. Ship features when you want, not when a vendor decides.

We're doing it. And once you have that freedom, it's hard to go back.

Maybe EmDash gets there. Maybe WordPress keeps evolving. Or maybe you just build your own thing. The point is we have more options than ever. And that's a good place to be.

WebGPU for Frontend Devs: A Practical First Project

Andrés Clúa — Wed, 18 Mar 2026 21:16:48 +0000

Most WebGPU tutorials go deep into theory or jump straight into 3D engines. If you are a frontend developer like me, that feels like learning to drive by reading the car manual.

This article is the opposite. We will build something visual, step by step, with zero GPU knowledge. By the end, you will have a real-time animated gradient running on your GPU — and you will understand every line.

What is WebGPU (in 30 seconds)

WebGPU lets your JavaScript talk directly to the GPU. Think about it like this:

Imagine you need to paint a wall. Your CPU is one very talented painter — fast, smart, and precise. But it paints one brushstroke at a time.

Your GPU is a team of 5,000 painters. Each one can only do simple strokes, but they all paint at the same time. Give them a wall with 2 million pixels? They split the work and finish in one pass.

WebGPU is the phone call that lets your browser hire that team of painters.

Browser support (March 2026)

Before we start — can your browser do this?

Browser	Status
Chrome/Edge	✅ Supported (since v113)
Firefox	✅ Supported (since v141)
Safari	✅ Supported (since 18.2)

Good news: all modern browsers support it now. For production, always check first:

if (!navigator.gpu) {
  alert("WebGPU is not supported in your browser");
}

What we are building

A full-screen animated gradient where the GPU decides the color of every pixel, 60 times per second. It looks like a lava lamp made of math.

No libraries. No frameworks. Just HTML, JavaScript, and a few lines of GPU code.

Step 1: The HTML (simple but necessary)

<!DOCTYPE html>
<html>
<head>
  <title>My First WebGPU Project</title>
  <style>
    body { margin: 0; overflow: hidden; }
    canvas { display: block; width: 100vw; height: 100vh; }
  </style>
</head>
<body>
  <canvas id="canvas"></canvas>
  <script src="main.js"></script>
</body>
</html>

Nothing new here — just a full-screen canvas. This is our "empty wall" that the GPU painters will fill.

Step 2: Connect to the GPU

Before the painters can work, you need to call the agency, confirm they are available, and give them the address. That is what this step does.

// main.js

async function init() {
  // 1. Check support
  if (!navigator.gpu) {
    throw new Error("WebGPU not supported");
  }

  // 2. Get an adapter (your physical GPU)
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) {
    throw new Error("No GPU adapter found");
  }

  // 3. Get a device (your logical connection to it)
  const device = await adapter.requestDevice();

  // 4. Connect the canvas
  const canvas = document.getElementById("canvas");
  canvas.width = window.innerWidth;
  canvas.height = window.innerHeight;

  const context = canvas.getContext("webgpu");
  const format = navigator.gpu.getPreferredCanvasFormat();

  context.configure({ device, format });

  return { device, context, format, canvas };
}

What just happened — using our painting analogy:

adapter = finding the painting agency (your physical GPU)
device = signing the contract with them (your app's private connection)
context = giving them the key to the room where the wall is (connecting canvas to GPU)

This setup code is the same for every WebGPU project. Write it once, copy it forever.

Step 3: Write a shader (the fun part)

Now we need to give instructions to our painters. In GPU world, these instructions are called shaders — small programs written in WGSL (WebGPU Shading Language). The syntax looks like Rust, but simpler.

Think of a shader like a recipe card you give to each painter. Every painter gets the same recipe, but they each know their own position on the wall. So painter #4500 reads: "I am at position (200, 300). Based on this recipe, my color should be blue." All 5,000 painters follow the recipe at the same time, and the wall is painted in one pass.

For our gradient, we need a fragment shader — a recipe that takes a pixel position and returns a color.

const shaderCode = /* wgsl */`

  // A uniform is data we send from JavaScript to the GPU
  @group(0) @binding(0) var<uniform> time: f32;
  @group(0) @binding(1) var<uniform> resolution: vec2f;

  // Vertex shader: positions a full-screen triangle
  @vertex
  fn vertexMain(@builtin(vertex_index) i: u32) -> @builtin(position) vec4f {
    // A clever trick: 3 vertices that cover the entire screen
    let pos = array<vec2f, 3>(
      vec2f(-1.0, -1.0),
      vec2f( 3.0, -1.0),
      vec2f(-1.0,  3.0)
    );
    return vec4f(pos[i], 0.0, 1.0);
  }

  // Fragment shader: runs once PER PIXEL
  @fragment
  fn fragmentMain(@builtin(position) pos: vec4f) -> @location(0) vec4f {
    // Normalize coordinates to 0.0 - 1.0
    let uv = pos.xy / resolution;

    // Animated color channels using sine waves
    let r = sin(uv.x * 3.0 + time) * 0.5 + 0.5;
    let g = sin(uv.y * 3.0 + time * 0.7) * 0.5 + 0.5;
    let b = sin((uv.x + uv.y) * 2.0 + time * 1.3) * 0.5 + 0.5;

    return vec4f(r, g, b, 1.0);
  }
`;

Let me explain each part:

@vertex fn vertexMain — This draws a giant triangle that covers the entire screen. Think of it as stretching a canvas over the wall. It is a standard trick you will reuse in every full-screen effect.
@fragment fn fragmentMain — This is the recipe card. It runs once for every pixel. Each pixel receives its position and returns a color.
sin() with time — The sin function creates smooth waves. Adding time makes them move. Different speeds per color channel (red, green, blue) create that organic, shifting look.
uv — The pixel position, but normalized to a range of 0 to 1. Like a percentage: top-left is (0, 0), bottom-right is (1, 1). This way, the shader works on any screen size.

If you have used CSS gradients before, the idea is similar — but this one updates 60 times per second and you control everything with math.

Step 4: Set up the pipeline

We have the painters (GPU), the wall (canvas), and the recipe (shader). Now we need to put everything together — like a manager organizing the work before it starts. That is what the pipeline does.

It tells the GPU: "Here is the recipe, and here is the data you will need."

function createPipeline(device, format, shaderCode) {
  const shaderModule = device.createShaderModule({ code: shaderCode });

  // Create buffers for our uniform data (time + resolution)
  const timeBuffer = device.createBuffer({
    size: 4, // f32 = 4 bytes
    usage: GPUBufferUsage.UNIFORM | GPUBufferUsage.COPY_DST,
  });

  const resolutionBuffer = device.createBuffer({
    size: 8, // vec2f = 2 × 4 bytes
    usage: GPUBufferUsage.UNIFORM | GPUBufferUsage.COPY_DST,
  });

  // Bind group layout: tells the GPU what data to expect
  const bindGroupLayout = device.createBindGroupLayout({
    entries: [
      { binding: 0, visibility: GPUShaderStage.FRAGMENT, buffer: { type: "uniform" } },
      { binding: 1, visibility: GPUShaderStage.FRAGMENT, buffer: { type: "uniform" } },
    ],
  });

  // Bind group: connects our buffers to the shader's @binding slots
  const bindGroup = device.createBindGroup({
    layout: bindGroupLayout,
    entries: [
      { binding: 0, resource: { buffer: timeBuffer } },
      { binding: 1, resource: { buffer: resolutionBuffer } },
    ],
  });

  // The render pipeline
  const pipeline = device.createRenderPipeline({
    layout: device.createPipelineLayout({
      bindGroupLayouts: [bindGroupLayout],
    }),
    vertex: {
      module: shaderModule,
      entryPoint: "vertexMain",
    },
    fragment: {
      module: shaderModule,
      entryPoint: "fragmentMain",
      targets: [{ format }],
    },
  });

  return { pipeline, bindGroup, timeBuffer, resolutionBuffer };
}

Yes, this is a lot of code. That is the most common complaint about WebGPU. But if you look closely, it is just connecting things — like plugging cables into the right ports:

Compile the recipe → shaderModule
Create two small envelopes (buffers) to pass data to the painters: current time and screen size
Label the envelopes so the painters know which is which (bindGroup)
Put it all together in one package (pipeline)

The good news? This wiring is almost the same for every project. The creative part is always the shader.

Step 5: The render loop

Time to paint. But we do not paint once — we paint 60 times per second. Each frame, we update the time (so the colors move), tell the GPU to run the recipe, and repeat. It is like a flipbook: each page is slightly different, and together they create animation.

function startRenderLoop(device, context, pipeline, bindGroup, timeBuffer, resolutionBuffer, canvas) {
  // Send resolution to GPU (only needs to happen once, unless resized)
  device.queue.writeBuffer(
    resolutionBuffer, 0,
    new Float32Array([canvas.width, canvas.height])
  );

  function frame(timestamp) {
    // Update time (convert ms to seconds)
    device.queue.writeBuffer(
      timeBuffer, 0,
      new Float32Array([timestamp / 1000])
    );

    // Create the render command
    const encoder = device.createCommandEncoder();
    const pass = encoder.beginRenderPass({
      colorAttachments: [{
        view: context.getCurrentTexture().createView(),
        loadOp: "clear",
        storeOp: "store",
      }],
    });

    pass.setPipeline(pipeline);
    pass.setBindGroup(0, bindGroup);
    pass.draw(3); // 3 vertices = our full-screen triangle
    pass.end();

    // Submit to GPU
    device.queue.submit([encoder.finish()]);

    requestAnimationFrame(frame);
  }

  requestAnimationFrame(frame);
}

If you have used requestAnimationFrame before for Canvas 2D animations, this is the same idea. The only difference: instead of drawing with ctx.fillRect(), you write a command list and send it to the GPU. Think of commandEncoder as writing a to-do list, and device.queue.submit() as handing that list to the painters.

Step 6: Wire it all together

async function main() {
  const { device, context, format, canvas } = await init();
  const { pipeline, bindGroup, timeBuffer, resolutionBuffer } =
    createPipeline(device, format, shaderCode);

  startRenderLoop(device, context, pipeline, bindGroup, timeBuffer, resolutionBuffer, canvas);
}

main();

Open index.html in your browser. You should see a smooth, colorful gradient filling your screen — every single pixel computed by the GPU in real time. All 5,000 painters working together.

Make it your own

The shader is your playground. You can change the recipe and the painters will follow. Try replacing the color math inside fragmentMain:

Circular waves:

let dist = distance(uv, vec2f(0.5, 0.5));
let wave = sin(dist * 20.0 - time * 3.0) * 0.5 + 0.5;
return vec4f(wave, wave * 0.5, 1.0 - wave, 1.0);

Checkerboard morph:

let scale = 10.0;
let checker = step(0.5, fract(uv.x * scale + sin(time))) *
              step(0.5, fract(uv.y * scale + cos(time)));
return vec4f(checker, 1.0 - checker, 0.5, 1.0);

Noise-like pattern:

let n = fract(sin(dot(uv + time * 0.1, vec2f(12.9898, 78.233))) * 43758.5453);
return vec4f(n * 0.8, n * 0.4, n, 1.0);

Change one number, save, refresh. You will see the result immediately. This is the best way to learn — experiment and break things.

What you just learned

Here is a cheat sheet. Every WebGPU concept mapped to something you already know as a frontend developer:

WebGPU concept	Analogy
`adapter`	Finding which painting agency is available
`device`	Signing a contract with them
`shaderModule`	The recipe card you give to every painter
`buffer`	An envelope with data (time, screen size) for the painters
`bindGroup`	Labels on the envelopes so painters know which is which — like props in a component
`pipeline`	The full work plan: recipe + materials + instructions
`commandEncoder`	A to-do list you write before handing it to the painters
`device.queue.submit()`	Handing the to-do list and saying "go"
`requestAnimationFrame`	Same as always — the flipbook loop

When should you use WebGPU?

After building this, you might want to use the GPU for everything. Do not do that.

The GPU is like a factory: amazing for mass production, terrible for custom one-off work. Use the right tool for the job.

Use WebGPU when:

Processing thousands of pixels, particles, or data points at once
Running ML models in the browser
Building visualizations with 100k+ data points
Real-time image or video filters

Stick with JavaScript when:

DOM manipulation
Business logic and API calls
Anything that is not the same operation repeated thousands of times

Where to go from here

You now have the foundation. The setup code stays the same — from here, the fun is changing the recipe (shader). Some ideas:

Add mouse interaction — send mouse coordinates as another uniform, so the gradient reacts to your cursor
Compute shaders — use the GPU to process data, not just pixels (great for simulations)
Particle systems — combine vertex and fragment shaders to move thousands of objects
WebGPU Samples — official examples with more advanced patterns

Questions? Leave a comment — I will answer every one. If you built something cool by changing the shader, I would love to see it.

AI Writes the Code. AI Reviews the Code. So Why Do They Still Need You?

Andrés Clúa — Tue, 10 Mar 2026 23:56:53 +0000

An AI writes your code. A different AI reviews it, flags the bugs, suggests the fix, and posts a clean summary to your PR. Cost: about $25. Time: minutes.

So what exactly are you doing here?

That's not a rhetorical question. It's the question every engineering team is quietly asking right now. And the companies that get it wrong are already paying for it.

The Wall and the Tap

Amazon recently held a mandatory meeting to address a wave of production incidents tied to AI-assisted code. Their internal briefing described outages with "high blast radius" caused by generative AI changes, and admitted that best practices for this workflow simply don't exist yet.

One incident stands out: an AI coding tool was asked to make a routine change to an AWS environment. Instead, it decided to delete and recreate the entire thing. Thirteen hours of recovery. Amazon called it an "extremely limited event." The affected tool served customers in mainland China.

They asked the AI to fix a leaky tap, and it knocked down the wall.

Amazon's fix wasn't more automation. It was more human oversight. Junior and mid-level engineers can no longer ship AI-assisted code without a senior signing off. One of the most technically advanced companies in the world looked at the problem and concluded: we need more experienced humans in the loop, not fewer.

The Numbers Agree

A CodeRabbit analysis of over 470 pull requests found that AI-generated code produces roughly 1.7x more issues per PR than human-written code. The biggest gaps weren't cosmetic. Logic errors, missing null checks, broken control flow, security misconfigurations. The kind of things that pass CI but blow up in production at 3 AM.

AI-generated code tends to look clean. It follows conventions, names things reasonably, formats well. But underneath that surface, it skips the guardrails that experienced engineers build instinctively. The code looks right. That's what makes it dangerous.

We Didn't Ship Garbage Before AI Either

Before AI we had code reviews. QA cycles. Staging environments. Integration tests. Senior engineers who would block your PR because they'd seen that exact failure before in production. We built entire cultures around shipping reliable software because humans were in the loop.

AI doesn't eliminate that need. It amplifies it. When you produce code 10x faster, you produce bugs 10x faster too. The volume goes up. The surface area for failure goes up. Remove the human filter to "move fast" and you get what Amazon got: a trend of high-impact outages with no safeguards.

The smart move was never to take humans out of the loop. It's to take the tedious work out of their day so they can focus on what prevents disasters: judgment, context, and ownership.

Great Demo. Terrible Production App.

Tools like Lovable, Bolt, and others let you go from idea to working app in minutes. The UIs look polished, the features work, the demo is convincing. As a proof of concept, they're unbeatable.

But if you're reading this, there's a decent chance you've already hit the wall. The wall where the app works beautifully in a demo but falls apart the moment real users touch it. No rate limiting. No input validation. No security headers. Endpoints wide open. The kind of stuff that doesn't show up in a screenshot but absolutely shows up in a penetration test.

I wrote about this after stress-testing an AI-built app. XSS payloads accepted with a smile. SQL injection that went through without a flinch. An SSRF vulnerability where the server tried to fetch internal cloud metadata from a URL someone typed into a text field. The app worked. It just wasn't safe.

I want people who use these tools on my team. Someone who spins up a working prototype in an afternoon to validate an idea before we spend two sprints building it? That person is incredibly valuable.

But here's the thing. Designers, marketers, and even developers who have never dealt with infrastructure, security, or scale should not look at these tools and think "I can ship this in production by tomorrow." Not because they're not smart. Because they haven't lived through the failures that teach you what production actually demands. Experience isn't gatekeeping. It's knowing what breaks when 10,000 real users hit your app at once instead of just you clicking around in a browser.

The AI builds the proof of concept. The engineer turns it into a product.

Your Value Was Never the Syntax

AI doesn't know your system. It doesn't know that your team decided last sprint to deprecate that service. It doesn't know the CTO's opinion on over-abstraction. It doesn't understand that the "elegant" solution will break the deploy pipeline because of a legacy dependency nobody wants to touch.

Code is decisions. Every function, every architectural choice, every trade-off reflects something the model doesn't have access to: the context of your team, your users, your business. The model gives you signal. You give it meaning.

The Responsibility Didn't Change

AI writing code doesn't eliminate engineers. It eliminates the mechanical fraction of the job. What remains is judgment, context, ownership, and taste. The things no model update will automate away because they require understanding why you're building something, not just how.

We're still human. The tools changed. The responsibility didn't.

The question isn't whether AI can write and review your code. It can. The question is whether you can do everything around the code that the AI can't.

If the answer is yes, you've never been more valuable.

Superpowers With No Aim: What I Found After Stress-Testing an AI-Built App

Andrés Clúa — Wed, 18 Feb 2026 14:28:24 +0000

Look, I love AI. I use it every day. It makes me faster, it helps me think, it writes boilerplate so I don't have to. But we need to have a serious conversation about what happens when you let AI build your app without knowing what you're actually asking for.

A friend of mine shipped a side project recently. Nice UI, clean design, worked well. He built most of it with AI assistance — prompting his way through features, shipping fast, iterating quick. The vibe coding dream, right?

I decided to throw some load at it. Just to see. Artillery, some custom scripts, a couple hundred random payloads. Nothing crazy, nothing illegal — just the kind of stuff any curious person with a terminal could do on a Tuesday afternoon.

What I found was genuinely scary.

The numbers

First test: 690 requests at 2 requests per second. Every single one went through. Zero rate limiting. The server didn't even flinch, but not in a good way — it just accepted everything blindly.

Second test: 3,050 requests with spikes up to 30 per second. Out of those, only 33 got a 429 (rate limited). That's 1%. The other 99% went through like butter.

Then I ran the fuzzer. 780 payloads — XSS, SQL injection, command injection, SSRF, path traversal, oversized strings, weird edge cases. The results:

614 malicious payloads accepted with a happy 202 status
86 payloads crashed the backend with 500 errors
20 requests timed out because the server stopped responding

Let that sink in. I sent <script>alert(1)</script> as an input value and the server said "yeah cool, let me process that for you."

The really bad stuff

The scariest finding was SSRF. I put a cloud metadata URL as a user input — the kind of internal endpoint where AWS and GCP store instance credentials. The server actually tried to fetch it. If that request resolves, someone can pull service account keys, environment variables, the whole thing. No exploit kit needed. Just a URL in a text field.

There were also API parameters sent directly from the client with zero server-side validation. Path traversal payloads went through without any checks. That means potentially reading or writing data you were never supposed to access.

No authentication on any endpoint. No input sanitization. No content security policy. The server was even broadcasting what framework it was running through response headers.

This is not a skill issue, it's a prompting issue

Here's the thing — I'm not writing this to roast anyone. The app works. The UI is clean. The features do what they're supposed to do. The problem isn't the developer. The problem is how we're using AI to build stuff.

When you tell an AI "build me an app that does X", you get exactly that. A thing that does X. It works. It demos well. It looks great in a tweet.

But the AI didn't add rate limiting because you didn't ask for it. It didn't validate inputs because your prompt was about features, not security. It didn't think about SSRF because that wasn't in the conversation. It gave you exactly what you asked for — nothing more, nothing less.

We've become monkeys with shotguns. We have this incredibly powerful tool that can generate entire applications in minutes, and we're pointing it at production without understanding what it built or what it missed. We're not thinking. We're just firing.

"Make it work" vs "Make it right"

There's a massive difference between these two prompts:

Prompt A: "Build me an API that receives user input, processes it, and returns results"

Prompt B: "Build me an API that receives user input. Validate the input format using a strict whitelist. Add rate limiting at 10 requests per minute per IP. Add security headers. Sanitize all user input before storing. Block private IP ranges and internal hostnames to prevent SSRF. Use parameterized queries. Add proper error handling that doesn't leak stack traces or internal details. Return 405 for unsupported HTTP methods."

Prompt A gives you a working app. Prompt B gives you a safe working app. The AI is perfectly capable of doing both — but it only does what you tell it.

And that's the core problem. AI doesn't have opinions about your architecture. It doesn't push back and say "hey, are you sure you want to accept arbitrary input from anonymous users and process it server-side without any checks?" It just does it. It's the most agreeable coworker you've ever had, and that's exactly what makes it dangerous.

The debugging trap

Here's something that doesn't get talked about enough: AI debugging without context is often worse than the original bug.

You hit an error, you paste it into the chat, the AI fixes the symptom. The 500 goes away. But it didn't fix the root cause — it just wrapped it in a try-catch that silently swallows the error, or it loosened a validation that was actually protecting you, or it added a workaround that introduces a new vulnerability.

I've seen this pattern over and over:

Dev builds feature with AI
Something breaks
Dev pastes error into AI
AI patches the symptom
Underlying issue is now hidden AND the patch introduced something new
Repeat until the codebase is a house of cards

When the AI doesn't have the full picture — your architecture, your security requirements, your threat model — its fixes are just educated guesses. Sometimes they're great. Sometimes they remove the one validation that was actually keeping your database safe.

What I actually think we should do

I'm not saying stop using AI. That would be stupid. AI is genuinely incredible and I'd be a hypocrite — I used AI tools to run this entire security assessment.

What I'm saying is:

1. Know what you're building before you prompt. Have an architecture in your head. Know what patterns you want. Know what your security boundaries are. Then tell the AI to build within those constraints.

2. Iterate with intention, not with vibes. "Make it work" is step one, not the finish line. After the feature works, go back and ask specifically about security, validation, error handling, edge cases.

3. Treat AI output like a junior dev's PR. You wouldn't merge a junior's code without reviewing it. Don't deploy AI-generated code without understanding what it does and what it doesn't do.

4. Security is not a feature, it's a requirement. Bake it into your prompts from the start. "Add rate limiting" should be as natural as "add a button."

5. When debugging, give context. Don't just paste the error. Explain what the code is supposed to do, what your constraints are, what you've already tried. The better the context, the better the fix.

The bottom line

The app I tested took probably a few hours to build with AI. It would take maybe 30 minutes more to make it secure — if security was part of the conversation from the beginning.

That's the gap. Not days. Not weeks. 30 minutes of intentional prompting. The difference between "build me this feature" and "build me this feature, and here's how I want it protected."

AI gave us superpowers. But superpowers without direction are just destruction with extra steps.

Build with intention. Prompt with context. Review what you ship.

Or keep being monkeys with shotguns. Your call.

If you want to run similar tests on your own projects (with permission, obviously), the tooling is straightforward: Artillery for load testing, custom JS payloads for fuzzing, and curl for manual recon. Took about 20 minutes to set up and the findings speak for themselves.

Full transparency: This article was written with AI. I don't usually write like this — English isn't even my first language and my usual tone is way more chaotic. But that's kind of the whole point. I ran the security assessment step by step using AI tools, organized my findings as I went, and at the end I asked for a clean markdown copy for dev.to. The irony isn't lost on me — an article about being intentional with AI, made with AI. But that's exactly the difference I'm talking about. I didn't say "write me a blog post about security." I guided every section, every point, every finding, based on real tests I actually ran. The AI shaped the words. The thinking was mine.

Speculation Rules API: Make Your Pages Load Before the User Clicks

Andrés Clúa — Tue, 10 Feb 2026 12:31:04 +0000

Imagine your website could predict where the user is going and have that page ready before they click. That's exactly what the Speculation Rules API does.

It's not magic. It's not a framework. It's a native browser API. And it's stupidly easy to implement.

The Problem

When a user clicks a link, the browser has to:

Request the HTML from the server
Download CSS, JS, images
Parse everything
Render the page

That takes time. Sometimes a little, sometimes a lot. But it always feels slower than it should.

The Solution: Cheat (the good kind)

The Speculation Rules API tells the browser: "Hey, the user will probably go to this page. Get it ready now."

And the browser does it. In the background. Without the user knowing.

When they finally click, the page shows up instantly. Literally. 0ms of perceived wait time.

Prefetch vs Prerender

There are two levels:

Prefetch: Downloads only the HTML of the page. Like downloading the blueprints of a house but not building it.

Prerender: Downloads EVERYTHING and renders the full page in the background. Like building the entire house and having it ready when you arrive.

Prerender is more aggressive and uses more resources, but the experience is instant.

How to Use It

It's a <script> tag with type="speculationrules" and JSON inside. No NPM, no imports, no config files.

Option 1: Specific URLs

If you know exactly which pages you want to pre-load:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/about", "/work", "/contact"]
    }
  ]
}
</script>

This tells the browser: "Prerender /about, /work and /contact immediately."

Option 2: Automatic Rules (document rules)

This is where it gets interesting. Instead of listing URLs by hand, you tell the browser to decide based on the links it finds on the page:

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "*.pdf" } },
          { "not": { "selector_matches": ".no-prefetch" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

Translation: "Prefetch all internal links on the page, except PDFs and links with the .no-prefetch class, but only when the user starts clicking."

Eagerness: How Anxious Do You Want It to Be

Controls when the browser starts pre-loading:

Level	What it does
`immediate`	Does it now. Doesn't ask.
`eager`	Same as immediate (for now)
`moderate`	Waits for 200ms of hover
`conservative`	Waits for the click to start (mousedown/touchstart)

conservative is the safest to start with. Only pre-loads when the user is already clicking, so you don't waste resources. My recommendation if you're unsure.

moderate is the sweet spot. 200ms of hover is enough to have the page ready by the time the click lands.

immediate is for when you're certain the user will go there. Use it with specific URLs, not document rules (or you'll prerender everything).

Useful Filters

By URL pattern

{ "href_matches": "/work/*" }

Only links starting with /work/.

By CSS selector

{ "selector_matches": ".prerender-this" }

Only links with that class.

Exclude pages

{ "not": { "href_matches": "/logout" } }

Important: Always exclude routes with side effects. If you prerender /logout, the user gets logged out without clicking. Not kidding.

Combine conditions

{
  "and": [
    { "href_matches": "/*" },
    { "not": { "href_matches": "/api/*" } },
    { "not": { "selector_matches": "a[rel~='nofollow']" } }
  ]
}

Add It Dynamically with JS

If you need to add rules after the page loads:

const rules = {
  prerender: [
    {
      urls: ["/next-page"]
    }
  ]
};

const script = document.createElement("script");
script.type = "speculationrules";
script.textContent = JSON.stringify(rules);
document.body.append(script);

Useful if you want to prerender the "next page" based on some user data.

Check Browser Support

if (
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports("speculationrules")
) {
  console.log("Speculation Rules supported");
}

Detect If a Page Was Prerendered

if (document.prerendering) {
  console.log("This page is being prerendered");
}

document.addEventListener("prerenderingchange", () => {
  console.log("User just navigated to this prerendered page");
});

Useful if you want to defer analytics or other actions until the user actually sees the page.

Things to Keep in Mind

Browser Limits

Chrome caps how many pages you can pre-load at once:

immediate/eager: up to 50 prefetches, 10 prerenders
moderate/conservative: up to 2 of each

Don't go crazy prerendering 100 pages. The browser will just ignore them.

Resource Consumption

Prerender uses bandwidth, CPU and battery. Chrome automatically disables it if:

The device is in power saver mode
Battery is low

Content Can Go Stale

If you prerender a page and the user takes 5 minutes to click, the content might have changed. For pages with real-time data, use prefetch instead of prerender.

Extensions

uBlock Origin disables preloading by default. Keep that in mind when measuring impact.

Deferred APIs

Some APIs (Geolocation, Notifications, Storage) are delayed until the page is actually activated. They won't fire during prerender.

Debug in DevTools

Open Chrome DevTools
Go to Application > Background Services > Speculative Loads
Reload the page
You'll see which pages are being prerendered/prefetched and any errors

Browser Support

Chrome: Yes (since 2024)
Edge: Yes
Firefox: No
Safari: No

For Firefox and Safari, the <script type="speculationrules"> tag is simply ignored. It doesn't break anything. Pure progressive enhancement.

Now Here's the Plot Twist

Everything above is cool. But if you hardcode your speculation rules and forget about them, you're leaving performance on the table.

The real power of this API is that it's just JSON. And JSON can be generated. Dynamically. From data.

What data? Your analytics.

Think about it. Your analytics already know:

Which pages users visit most
What the most common navigation paths are
Which links get the most clicks on each page
How those patterns change over time

So instead of guessing which pages to prerender, you can know.

The Loop

Here's the workflow:

Week 1: You deploy speculation rules based on gut feeling. Prerender /about and /work because they seem important.

Week 2: You check analytics. Turns out 73% of homepage visitors go to /work first, then /work/project-x. Nobody clicks /about from the homepage. Now you know what to actually prerender.

Week 3: Traffic patterns shifted. A blog post went viral and now /play is getting 5x the traffic. Your speculation rules should reflect that.

This isn't a "set it and forget it" feature. It's a feedback loop.

How to Build It

The simplest version: a script that runs weekly (cron job, CI pipeline, whatever) that:

Pulls your top navigation paths from Google Analytics, Plausible, or whatever you use
Generates a JSON with the speculation rules
Deploys it as a static file or injects it at build time

// build-speculation-rules.js
// Run this weekly via CI/cron

async function generateRules() {
  // 1. Fetch top navigation paths from your analytics
  const topPaths = await getTopPathsFromAnalytics();
  // e.g., [{ from: "/", to: "/work", percentage: 73 }, ...]

  // 2. Build rules per page
  const rulesPerPage = {};

  for (const path of topPaths) {
    if (!rulesPerPage[path.from]) {
      rulesPerPage[path.from] = [];
    }

    rulesPerPage[path.from].push({
      url: path.to,
      eagerness: path.percentage > 60 ? "moderate" : "conservative"
    });
  }

  // 3. Write the output
  return rulesPerPage;
}

Then in your template/layout:

// Get the precomputed rules for the current page
const currentPageRules = speculationData[currentPath] || [];

const rules = {
  prerender: currentPageRules
    .filter(r => r.eagerness === "moderate")
    .map(r => ({ urls: [r.url], eagerness: "moderate" })),
  prefetch: currentPageRules
    .filter(r => r.eagerness === "conservative")
    .map(r => ({ urls: [r.url], eagerness: "conservative" }))
};

The Eagerness Trick

Here's where it gets smart. Use analytics to decide eagerness too:

More than 60% of users navigate there? Use moderate (prerender on hover)
Between 20-60%? Use conservative (prerender on mousedown)
Less than 20%? Don't bother

You're not wasting resources prerendering pages nobody visits. And you're aggressively prerendering the ones everybody does.

Measure the Impact

Once you have this loop running, track:

LCP (Largest Contentful Paint) for pages that were prerendered vs not
Navigation timing using the Performance API
Hit rate: how often a prerendered page was actually visited

const navEntry = performance.getEntriesByType("navigation")[0];

if (navEntry.activationStart > 0) {
  // This page was prerendered!
  console.log("Prerender saved:", navEntry.activationStart, "ms");
}

Feed that data back into the loop. Drop pages with low hit rates. Promote pages with high navigation probability. Every week your speculation rules get smarter.

Summary

Add a <script type="speculationrules"> to your HTML
Define which pages to pre-load and with what eagerness
Your pages load instantly
No libraries, no frameworks, no weird stuff
Browsers that don't support it just ignore it
Connect it to your analytics and update weekly -- that's where the real value is

Static speculation rules are a quick win. Analytics-driven speculation rules are a compounding advantage. Every week your site gets faster because it gets smarter about what to pre-load.

It's free, it's easy, and it makes a real difference. There's no reason not to use it.

If this helped, drop a like and follow for more web performance content.

That Side Project You Abandoned? I Finally Finished Mine.

Andrés Clúa — Mon, 26 Jan 2026 15:05:21 +0000

We all have one. That side project you started super excited, thinking it would be the one. You set up the repo, picked the stack, maybe even bought a domain. And then... life happened. Work got crazy. A new idea came up. The project just sat there for months.

This is the story of how I finally finished mine.

Last year, I stopped by Hotel Domine in Bilbao to grab a bite. The lobby has this crazy clock on the wall. I stood there like an idiot for five minutes, watching the hands move together to form numbers. I later found out it was inspired by "A Million Times" by Humans Since 1982 — an art piece where hundreds of analog clocks work together to display time. Each small clock does its own thing, but together they show something bigger.

I was hooked. I had to build a web version.

I started the project that same week. I went with React and Vite — not my usual stack at all. I started with Angular 1.6 **(yes, I'm that old), quickly moved to **Vue and never left that ecosystem. These days I mostly work with Astro. Playing with time and dates is one of the first things you learn as a developer, right? So building a clock in React felt like a good way to get familiar with it without getting too deep. I had a basic grid of clocks working in a few hours. This was going to be easy!

Then I didn't touch it for almost two years. Sound familiar?

The problem wasn't motivation. It was that weird gap between "it works" and "I'm actually proud of this." That phase where you're moving pixels around, questioning every decision, and wondering if anyone will even care.

What Finally Got Me to Finish

I'm not going to lie, there was no magic moment. What worked for me was simple: I made it smaller.

Instead of building the ultimate clock with every feature I could think of, I focused on:

The main thing — Mini clocks with two hands that rotate to form digits
One animation — A nice entrance when the page loads
One extra detail — A WebGL background that reacts to mouse movement

That's it. No settings. No themes. No "export as GIF." Just a clock that looks cool.

The Technical Stuff

For those who want to know how it works:

The Clock Grid:
Each digit is a 3×6 grid of mini analog clocks. Every mini clock has two hands that can point anywhere. By setting the right angles, you can "draw" numbers:

// Each position is [hourHand, minuteHand] angles
const digitPatterns = {
  0: [
    [TL, H, TR],  // Top: corners + horizontal line
    [V, D, V],    // Vertical lines with fill
    [V, D, V],
    [V, D, V],
    [V, U, V],
    [BL, H, BR],  // Bottom row
  ],
  // ... more digits
};

The Entrance Animation:
GSAP handles the staggered reveal. Each mini clock scales and rotates in from a random position:

gsap.fromTo(miniClocks,
  { opacity: 0, scale: 0, rotation: -180 },
  {
    opacity: 1,
    scale: 1,
    rotation: 0,
    stagger: { each: 0.03, from: 'random' },
    ease: 'back.out(1.7)'
  }
);

The Background:
Three.js with particles. They float slowly, but when you move your mouse (or tilt your phone), they react. It adds some depth without distracting from the clock.

What I Learned

1. Done is better than perfect

I could have spent another month adding features. Instead, I shipped something that works and looks good. The "just one more thing" mindset kills projects.

2. Limits make things easier

Having only three things to build made every decision simpler. Should I add dark mode? No, it's not on the list. Should I add 12-hour format? No. Move on.

3. Side projects don't need to be useful

This clock has no practical purpose. Your phone already tells time. But building something just because it's cool is a good enough reason. Not everything needs to be a startup idea.

Try It

The clock is live at clock.andresclua.com

Move your mouse around (or tilt your phone) to see the background react. Watch the seconds go by. Maybe stand there like an idiot for five minutes, like I did in that hotel lobby.

And if you have your own abandoned project sitting in a repo somewhere — maybe it's time to make it smaller and ship it.

What's your abandoned side project? Drop it in the comments — maybe we can push each other to finally finish them.

The AI Coding Shortcut: Balance Speed with Learning

Andrés Clúa — Mon, 14 Jul 2025 12:59:31 +0000

Introduction

AI code assistants can write functions, fix simple bugs, and save us time. But there’s a habit—sometimes called “instinct coding”—where you ask AI for all the code and then ship it without proper checks. That shortcut feels good, but it has real costs for both your project and your growth as a developer.

Why AI Helps Us Code

Fast setup: In seconds, AI creates project templates or folder structures.
Instant examples: You get code samples for new libraries without searching online.
Consistent style: AI follows naming and formatting rules so your code stays tidy.

These perks make AI a popular helper, especially under tight deadlines.

What Is “Instinct Coding”?

For me “Instinct coding” means:
You give a brief prompt to AI.
It generates code.
You paste that code directly into your project.

Skipping careful review leads to unpredictable results and hidden problems.

Learning by Doing vs. Copy-Paste Speed

Writing code yourself, debugging, and understanding each error teach you to:

Improve performance by spotting slow parts.
Handle unusual edge cases before real users see them.
Debug complex issues with confidence.

Copying AI output feels fast but cuts short the trial-and-error that builds true skill.

Impact on Juniors and Seniors

Juniors: Beginners may lean too heavily on AI, missing out on core learning. They risk never understanding basic concepts like data structures or algorithms, because they copy code without exploring why it works. Over time, this creates gaps that make it hard to solve novel problems alone.

Seniors: Experienced developers might use AI to speed up routine tasks, but overuse can dull their edge. Seniors need deep system knowledge to design architecture, review pull requests, and mentor others. If they rely solely on AI, they may lose familiarity with new frameworks, struggle to catch subtle bugs, and find it harder to guide junior teammates.

Balancing AI help with hands-on work ensures both groups keep growing.

Security Holes and Hidden Bugs

Credentials exposure: AI can insert real or dummy API keys and passwords by mistake.
Vulnerable dependencies: It may include outdated libraries or unsafe code patterns.
Technical debt: Generated code often lacks tests, comments, and clear structure, making future maintenance harder and riskier.

Without a careful review, these issues can lead to serious production failures.

Smart Ways to Use AI Coding

Use AI where it shines, but always review its work:

Boilerplate tasks: Generate basic file structures, config settings, or helper functions.
Prototyping: Quickly spin up demos to share ideas with clients or teammates.
Requirement clarification: Let product managers draft rough versions that engineers can refine.

After generation, take time to read, test, and clean up the code before deploying.

Final Thoughts

AI is a powerful ally—but not a replacement for hands-on coding and critical thinking. Relying on it without understanding your code can lead to hidden bugs, security holes, and technical debt. The best approach is to balance: use AI to speed up routine work, but keep your hands on the wheel. Write, test, and learn from your own code.

That way, you build solid software and strengthen your skills—whether you’re just starting out or guiding a team.

Probably most people don’t care, but every AI request runs on powerful servers and uses a lot of electricity. If every developer leans on AI for every line of code, the total energy use—and carbon footprint—of software development will go up a lot. This tech is super helpful, but let’s use it carefully in our daily work and when consuming AI-generated content—whether that’s code, images, videos, or anything else.

Let It Flow – Effortless Noise Animation for the DOM

Andrés Clúa — Tue, 24 Jun 2025 20:15:47 +0000

Why I Love Noise (and You Probably Do Too)

As someone who works across creative code, product design, and interface motion, I often find myself looking for ways to make digital experiences feel less rigid. Whether it's subtle breathing in a background or a micro-interaction that wobbles just right, nothing beats the magic of Perlin noise or its more modern sibling, Simplex noise, for bringing that organic, almost-natural motion to life.

But here’s the thing—most of the tools we use to create that kind of movement aren’t really made for the web. Especially when working on B2B client projects, where simplicity and performance are everything, pulling in a full noise generator or a 3D engine just to move a few elements feels… excessive.

So I built something to bridge that gap.

Meet PerlinDOM

PerlinDOM is a super lightweight (less than 1 kB gzipped), zero-dependency JavaScript library that gives any HTML element natural, Perlin-style motion — no canvas, no WebGL, no dependencies, no drama.

It’s perfect when you want to make a boring interface feel a little more alive without writing boilerplate or compromising performance.

I’ve been a long-time fan of noise-driven animation in Three.js, but when you just want to animate a DOM element, spinning up a 3D renderer is like bringing a rocket launcher to a pillow fight.

The Problem: Animating the DOM with Noise Gets Messy

Normally, if you want to apply noise motion to DOM elements, you end up doing something like this:

Load a noise-generation library (often quite large).
Manually set up a requestAnimationFrame loop.
Map the noise values to CSS transforms.
Handle play/pause logic, cleanups, and performance tweaks…

What should be a creative experiment becomes a maintenance headache.

What PerlinDOM Does Instead

PerlinDOM wraps all of that into a single, clean, flexible API. Here’s what it gives you out of the box:

✨ Features

Organic motion — never robotic, always smooth.
Zero dependencies — literally just plug and play.
Tiny footprint — less than 1kB gzipped.
Clean API — with play(), pause(), destroy(), and optional seed support.
Customizable — control the motion range, speed, and lerping with config options.
Efficient — runs on requestAnimationFrame for buttery-smooth animation.

✅ Use it when you want:

Great for	Not ideal for
Subtle hover effects	Complex, timeline-driven scenes
Floating UI blobs or "breathing"	Real-world physics or collisions
Backgrounds with organic motion	3D environments with heavy rendering
Light dashboards & playful UIs	Frame-perfect synchronization needs

Example

Need motion without a full motion engine?

Try PerlinDOM.

It’s designed for when your site needs to feel more alive — without overthinking it.

Navigating Asynchronous JavaScript: From Promises to Async/Await and Beyond

Andrés Clúa — Fri, 15 Mar 2024 09:25:12 +0000

In the dynamic world of JavaScript development, understanding asynchronous operations is essential. This blog post delves into the core concepts that make managing asynchronous code not just manageable, but elegant and effective.

From the foundational promises, through the evolution of promise chaining with .then(), to the streamlined async/await syntax, and the careful navigation around callback hell, we’ll cover the tools and techniques to elevate your JavaScript code.

My objective is to offer you a comprehensive understanding that balances fun and functionality, ensuring you can tackle asynchronous challenges with confidence.

Overview

Promises: The bedrock of asynchronous JavaScript, encapsulating potential future values.
.then() Chaining: An evolution in handling sequential async operations elegantly.
Avoiding Callback Hell: Strategies to evade the notorious complexity of nested callbacks.
Async/Await: A syntactical sugar that simplifies writing async code akin to synchronous patterns.
Error Handling: The art of using try...catch...finally to manage exceptions in async flows.

By the end of this post, you'll have a solid grasp of these concepts, ready to apply them to enhance your JavaScript projects.

Understanding Promises: The Foundation

At the heart of asynchronous JavaScript lie Promises, objects that represent values which may be available now, in the future, or never. These values mirror real-world operations—such as fetching data from an API—encapsulating their eventual success or failure. Promises exist in one of three states:

Pending: The initial state, where the outcome is still unknown.
Fulfilled: Indicates successful operation completion.
Rejected: Signifies a failure in the operation.

Example

let learningOutcome = new Promise((resolve, reject) => {
  let isSuccessful = true;
  if(isSuccessful) {
    resolve('Successfully learned JavaScript!');
  } else {
    reject('Learning journey continues...');
  }
});

Streamlining with .then() Chaining

The .then() method provides a structured way to specify actions following a Promise's resolution or rejection, thus avoiding the pitfalls of nested callbacks and improving code readability.

Example

learnJavaScript.then((result) => {
  console.log(result); // 'Learned JavaScript!'
  // Perform a simple follow-up action
  console.log('Preparing to apply knowledge...');
}).catch((error) => {
  console.error('Failed to learn JavaScript:', error);
});

This pattern improves upon nested callbacks, offering a more manageable approach to handling multiple asynchronous tasks.

Callback Hell: A Tangled Web

Callback Hell, sometimes known as "The Pyramid of Doom," refers to the difficulty in managing and maintaining code that relies heavily on nested callbacks for asynchronous operations.

Example

getData().then(a => {
    return getMoreData(a).then(b => {
        return getEvenMoreData(b).then(c => {
            console.log('Finally got all data:', c);
        });
    });
});

The Evolution: Async/Await

This nesting leads to code that is hard to read, understand, and debug, motivating the search for cleaner solutions.

Example

async function masterJavaScript() {
    let result = await learnJavaScript;
    console.log(result); // 'Learned JavaScript!'
    let nextResult = await performAnotherAsyncOperation();
    console.log(nextResult);
}

This approach streamlines asynchronous code, making it easier to read and maintain.

Mastering Error Handling with try...catch...finally

Effective error handling in asynchronous code is crucial. The try...catch...finally syntax in async/await operations ensures that errors are caught and handled gracefully, maintaining the robustness of applications.

Example

async function fetchDataSafely() {
  try {
    const data = await fetch('https://api.example.com');
    console.log('Data fetched successfully:', data);
  } catch (error) {
    console.error('Failed to fetch data:', error);
  } finally {
    console.log('Attempt to fetch data completed.');
  }
}

Async/await syntax, introduced to simplify working with promises, makes asynchronous code look and behave more like synchronous code. It's the equivalent of telling JavaScript, "Wait here until this task finishes, then move on."

Example

async function codeExecution() {
  try {
    let result = await codingPromise;
    console.log(result);
  } catch (error) {
    console.error('Error:', error);
  }
}

By embracing these techniques, you’re not just writing code; you’re crafting an efficient, maintainable, and elegant codebase.

Asynchronous JavaScript no longer needs to be daunting. With promises, .then() chaining, and the async/await syntax, you have the tools at your disposal to handle any asynchronous operation gracefully.

Remember, the key to mastering JavaScript's asynchronous nature lies in understanding and effectively applying these concepts.

Crafting My NPM Package: Beyond jQuery

Andrés Clúa — Mon, 11 Mar 2024 21:07:53 +0000

The Problem

A few years ago, when I began to lead development teams, I often faced a problem. I would say, "use the function we used in another project," and we would always end up copying and pasting code from one project to another.

Yes, we were using npm and similar tools, but sometimes the tasks we needed were very specific, like checking the browser, adding or removing styles, and many developers still preferred using jQuery for those tasks.

Draft

So I thought, "Why not create my own package?" I can address these small items, all in one library. My team will have a single source of truth, and together, we can solve our problems.

You might think vanilla JS makes jQuery unnecessary, and you're right. However, I chose to start with something easier to manage, aiming to use it for our internal projects. This also helps old developers move to the vanilla ecosystem more smoothly.

Objectives

1 - Develop an NPM Module
2 - Avoid Repetitive Work
3 - Connect with other devs
4 - Make the library Grow in terms of functionalities.

Library Features

The library offers functionalities for manipulating HTML elements and attributes with ease. Features include hiding, showing, styling elements, adding or removing classes, toggling classes, and checking element matches.

It also enables attribute manipulation, converts strings to boolean or number, identifies browser types and systems, and introduces delays in code execution. These tools streamline web development tasks, enhancing efficiency and code readability.

Some Examples

Hide Elements

import { u_addClass } from '@andresclua/jsutil';
u_addClass('selector', 'add-new-class');
// examples
u_addClass('.add-class'), 'add-new-class');
u_addClass(document.querySelectorAll('.add-class'), 'add-new-class');
u_addClass(document.querySelector('.add-class'), 'add-new-class');
u_addClass(document.getElementById('my-element-class'), 'add-new-class');

Add style to elements

import { u_style } from '@andresclua/jsutil';
// Apply multiple styles to elements with class 'styled-elements'
u_style('.styled-elements', [{ color: 'red' }, { fontSize: 16 }]); // if no unit is define will use pixels
u_style('.styled-elements', [{ background: 'red' }, { display: 'block' }]);

Add Single class or multiple Classes to element

import { u_addClass } from '@andresclua/jsutil';
// Add 'class1' and 'class2' to elements with class 'add-classes-to-me'
u_addClass('.add-classes-to-me', 'class1 class2');

Check if element has matches certain criteria

import { u_matches } from '@andresclua/jsutil';
// Check if there's an element with the class 'active'
const hasActive = u_matches('.menu-item', 'active');

import { u_matches } from '@andresclua/jsutil';
// Check if there's an element containing both 'active' and 'highlighted' classes
const hasActiveAndHighlighted = u_matches('.menu-item', 'active highlighted');

import { u_matches } from '@andresclua/jsutil';
// Check if there's an element with a data-attribute 'data-role' equal to 'admin'
const hasAdminRole = u_matches('div', 'admin', 'data-role');

Browser Type

import { u_browser } from '@andresclua/jsutil';
const isChrome = u_browser('chrome');

You can find more documentation on how to use it

Conclusion

Creating my npm package was very rewarding. I started with webpack but switched to Vite recently, to use its library mode. This change made my package work better for UMD and ES modules, improving how developers can use it.

For the latest version, I've improved the documentation using Astro, which I like for its ease of use in web projects.

Using these tools made development smoother and helped me make a useful and easy-to-understand package. Making my npm package taught me about being adaptable, the importance of good documentation, and keeping up with new technology to help developers.

I enjoyed sharing about making my npm package. It's been a great journey, and I'm excited to share more. Thanks for reading my first post. I'd love to hear your thoughts or feedback!