Indonesia Singapore ไทย Pilipinas Việt Nam Malaysia မြန်မာ ລາວ
← Back to Blog

CSS border-shape, Infinite Canvas, and the Performance Tax

Every new design capability has a render cost — audit before you ship, not after your LCP collapses.

Editorial illustration of a developer weighing a ornate CSS shape against a stopwatch on a giant balance scale
Illustrated by Mikael Venne

New CSS properties and WordPress visual builders promise design freedom — but every feature has a performance cost. Here's how to ship without sacrificing speed.

The frontend world has had a quietly productive few weeks. A new CSS property is landing that will reshape (literally) how we handle decorative borders. A WordPress builder has launched with an infinite canvas and a bold claim about performance parity. And a studio built a scroll-driven WebGL comic to celebrate its tenth anniversary — which is either an inspiration or a cautionary tale depending on how your LCP scores look right now.

Three different stories. One thread connecting them all: every new capability has a render cost, and in Southeast Asia’s mobile-first, bandwidth-variable environments, that cost lands directly on your conversion rate.

CSS border-shape Is Coming — And It’s More Powerful Than It Looks

CSS-Tricks’ Temani Afif has a detailed breakdown of the incoming border-shape property, which builds on the recently introduced shape() function and corner-shape to give developers native, GPU-composited control over border geometry. We’re talking arbitrary curves, chamfered corners, and complex outlines — without a single SVG clip-path or pseudo-element hack in sight.

The performance angle here is real. Legacy approaches to shaped borders — SVG masks, clip-path, stacked pseudo-elements — are notoriously paint-heavy. They force the browser to recalculate layer compositing on scroll and animation, which tanks your Interaction to Next Paint (INP) scores on mid-range Android devices, the dominant handset category across the Philippines, Vietnam, and Indonesia.

Native border-shape rendering is handled at the compositor layer, which means it sidesteps the main thread entirely during animation. For brands doing heavy scroll-triggered UI work — think Shopee-style product carousels or Grab’s contextual card layouts — this is a meaningful shift. The catch: browser support is still catching up, so progressive enhancement via @supports is non-negotiable before you ship anything customer-facing.

Kirki’s Infinite Canvas: The Performance Claim Deserves Scrutiny

Smashing Magazine’s Zareen Tasnim profiles Kirki, a new WordPress visual builder positioning itself as the first freeform infinite-canvas tool for WordPress — no plugin dependencies, cleaner output, and a drag-anywhere design surface reminiscent of Figma.

The zero-plugin-dependency claim is the one worth pulling apart. Traditional WordPress page builders (Elementor, Divi, WPBakery) are notorious for injecting bloated CSS and JS bundles regardless of whether you’re using the features on a given page. Kirki’s architecture reportedly avoids this by compiling only the styles and scripts actually used — a build-time approach closer to how modern static site generators work.

If that holds up in production, the Largest Contentful Paint implications are significant. A typical Elementor-built WooCommerce page in Southeast Asia routinely loads 400–600KB of unused CSS. Eliminating that alone can move LCP by 800ms to 1.2 seconds on 4G connections — which, per Google’s own threshold data, is the difference between a “good” and “needs improvement” score.

The infinite canvas itself is a UX bet on whether marketing teams can self-serve without producing layout chaos. That’s a stakeholder conversation worth having before rollout: governance rules and component libraries need to exist before you hand a freeform canvas to a team of ten.


What a WebGL Comic Teaches Us About Experiential Performance Budgets

Codrops published the making-of for Studio375’s “Ten Years Away” — a scroll-driven interactive comic built in WebGL to mark the studio’s anniversary. It’s genuinely impressive work: hand-drawn panels, parallax depth, frame-by-frame scroll control, the lot.

From a performance engineering standpoint, it’s also a useful case study in intentional trade-offs. WebGL experiences of this complexity will not pass Core Web Vitals thresholds on a standard audit. The initial bundle weight, the GPU memory allocation, the deferred rendering pipeline — none of it looks good in Lighthouse. And that’s fine, because this wasn’t a lead-generation landing page.

The lesson isn’t “don’t build ambitious things.” It’s that performance budgets are contextual. A brand anniversary microsite and a product detail page have fundamentally different success metrics. The error most teams make is applying one standard across both. Define your performance contract by page type: conversion pages (LCP under 2.5s, INP under 200ms, no exceptions), brand experience pages (progressive loading, skeleton states, fallback for low-end devices), editorial and campaign pages (assessed case-by-case against engagement goals).

For Southeast Asian audiences specifically, always test WebGL and heavy animation experiences on a Redmi or Samsung A-series device on a throttled connection before sign-off. What renders beautifully on a MacBook Pro becomes a stuttering slideshow on the handset your actual customer is holding.

The Common Thread: Render Cost Is a Business Decision

What connects border-shape, Kirki, and a WebGL comic is that all three represent the same expanding frontier — more design capability, more visual expressiveness, more ways to differentiate a brand experience. That’s genuinely good news.

But in markets where 60–70% of sessions come from mobile devices on variable network conditions, design decisions are always simultaneously performance decisions. A shaped card border that forces a repaint on scroll. A visual builder that ships 200KB of unused JavaScript. An immersive experience with no low-bandwidth fallback. Each one is a quiet tax on your conversion rate, paid by users you never see in your analytics because they bounced before the page finished loading.

The teams winning on performance right now aren’t the ones restricting their design vocabulary — they’re the ones who’ve built the measurement infrastructure to know exactly what each creative choice costs before it goes live.

Key Takeaways

  • Native CSS border-shape renders at the compositor layer, making it significantly lighter than SVG or clip-path alternatives for animated UI elements — worth prioritising once browser support stabilises.
  • Kirki’s zero-plugin-dependency architecture addresses a genuine WordPress performance problem, but infinite canvas tools require content governance frameworks before team-wide rollout.
  • Define performance budgets by page type, not site-wide — WebGL experiential pages and conversion pages are not the same product and shouldn’t share the same Lighthouse pass/fail threshold.

The broader question worth sitting with: as CSS becomes expressive enough to handle what we used to solve with JavaScript or SVG, and as builders abstract away enough complexity that non-engineers can ship production code, where does performance ownership actually live in your organisation? If the answer is “with the developer, at the end of the process,” you already have a problem.


At grzzly, we work with marketing and product teams across Southeast Asia to build performance into the brief — not bolt it on after the fact. Whether that’s auditing your WordPress stack, setting page-type performance contracts, or helping your team understand what new CSS capabilities actually cost at runtime, we’re the kind of partners who care about your LCP as much as your look. Let’s talk

Diesel Grizzly

Written by

Diesel Grizzly

Core Web Vitals, rendering strategies, PWAs, and the relentless pursuit of sub-second load times. Believes that performance is the most underrated conversion optimisation lever in existence.

Enjoyed this?
Let's talk.

Start a conversation