Autonomous Websites: The Case for Never-Finished Code

Your website peaked on launch day. That’s not cynicism — it’s physics. The moment a site goes live, the world starts moving away from it: browser engines update, user expectations shift, competitor benchmarks rise, and content quietly goes stale. Most teams know this and do nothing about it, because “keeping the site current” competes with every other priority in the backlog and loses every time.

Pierre Burgy at Smashing Magazine puts the problem plainly: websites don’t decay because they break, they decay because nobody has time. That framing reframes the entire maintenance question — this isn’t a resourcing problem, it’s an architectural one. And the architectural answer emerging right now is the autonomous website: a site designed from the ground up to be continuously optimised by agents after launch, not just maintained by humans between sprints.

For performance engineers, this is the most interesting infrastructure problem of 2026.

The Launch-Day Ceiling Is a Performance Problem

Here’s what actually happens to Core Web Vitals over time. A site launches with a respectable LCP of 1.8s. Six months later, marketing has added three new tag manager triggers, two A/B testing scripts, and a chatbot widget. Nobody ran a Lighthouse audit. LCP is now 3.4s, and conversion rate has quietly dropped — but no one’s connected the dots because the site “works.”

This is the performance debt cycle, and it’s endemic across Southeast Asian e-commerce — particularly on Shopee and Lazada storefronts where brands control a webview layer but can’t always audit the platform overhead beneath it. The autonomous website model Burgy describes tackles this by treating optimisation as a continuous process rather than a launch deliverable. Agents monitor, test, and implement changes — adjusting image compression ratios, pruning unused CSS, reordering critical rendering paths — without waiting for a human sprint cycle to catch up.

The business case is straightforward: Google’s own data consistently shows that a 100ms improvement in page load time correlates with measurable conversion lifts. For a mid-market SEA retailer doing USD 2M/month in online revenue, that’s not a UX nicety — it’s P&L.

Lightweight Code as a First Principle, Not an Afterthought

One signal that sits quietly alongside the autonomous website conversation is the renewed appetite for minimal, dependency-light tooling. CSS-Tricks recently featured MicroLighter, a syntax highlighter built by Dave Rupert that delivers code block highlighting without the bloated JavaScript, complex markup, or cascade of spans and classes that tools like Prism.js or Highlight.js require.

On its own, a syntax highlighter is a niche concern. But the philosophy behind it is directly relevant to autonomous optimisation: if your baseline codebase is leaner, agents have less noise to work around and fewer performance regressions to detect and fix. Every third-party dependency you add is technical surface area that autonomous systems have to monitor, test against, and potentially roll back.

This is a useful design constraint to apply broadly. Before reaching for a full library, ask whether a 2KB custom implementation serves the use case. In mobile-first markets like the Philippines and Vietnam — where median connection speeds still make JavaScript payload size a real friction point — this discipline pays compounding dividends.

---

When Visual Ambition Collides with Performance Budgets

Not every web trend is pointing toward minimalism. The same week that MicroLighter dropped, Codrops published a detailed tutorial on building a mouse-following square lens effect using Three.js and GLSL — real-time image distortion with RGB shifting and animated shaders. It’s technically beautiful work by Tomoyuki Nakata, and it represents a category of interactive experience that brands increasingly want on hero sections and product pages.

Here’s the performance tension: WebGL-based effects like this, when implemented naively, can tank your INP (Interaction to Next Paint) score and wreck CLS on lower-end Android devices — which remain the dominant hardware class across most of Southeast Asia. A Three.js scene loading synchronously in the critical path will delay your LCP regardless of how elegant the shader code is.

The mitigation strategy isn’t “don’t build this” — it’s “build this with a performance budget from day one.” Specifically: lazy-initialise the WebGL context after the critical content paints, use IntersectionObserver to defer canvas rendering until the element is in viewport, and always provide a static image fallback for devices that fail a WebGL capability check. In an autonomous website architecture, these conditions become monitored thresholds — if the effect starts degrading real-user metrics, the agent can serve the fallback to affected device segments automatically.

Designing for Agents, Not Just Users

The deeper design problem Burgy surfaces is that most websites aren’t built to be changed — they’re built to be launched. Templates are rigid, content is hardcoded into layouts, and component architecture makes surgical updates difficult without breaking adjacent elements. Autonomous optimisation agents hit this ceiling fast.

For teams in Southeast Asia building or rebuilding sites now, this is the moment to make different architectural decisions. Adopt headless CMS architectures where content and presentation are genuinely decoupled. Build with design tokens so that visual adjustments don’t require code deployments. Instrument your site with real-user monitoring from day one — not just synthetic Lighthouse scores — so that any agent (or human) has actual signal to optimise against. Tools like Vercel’s Speed Insights, Cloudflare’s observatory tooling, or open-source RUM setups piped into a Grafana dashboard all give you the observability layer that autonomous systems require to function.

The websites that will compound in performance and relevance over the next three years aren’t the ones with the most impressive launch. They’re the ones built to keep learning.

---

Key Takeaways

• Build sites with autonomous optimisation in mind from day one: decouple content from presentation, instrument real-user monitoring, and keep dependency footprints lean so agents have clean signal to work with.
• Apply a strict performance budget to any interactive or WebGL-heavy feature — lazy initialisation and capability-based fallbacks are non-negotiable on Southeast Asia’s device distribution.
• Treat post-launch optimisation as an architectural layer, not a backlog item; the teams that close this loop fastest will own the conversion rate gap.

The autonomous website isn’t science fiction — Burgy’s team is building it in production today. The open question for Southeast Asian brands is whether your current web architecture is even capable of being autonomously optimised, or whether it’s so tightly coupled and instrumentation-free that no agent — human or otherwise — could meaningfully improve it without starting over. That’s worth sitting with before your next redesign brief.

---

At grzzly, we spend a lot of time inside exactly this problem — helping brands across Southeast Asia build web infrastructure that performs on launch and keeps performing long after. Whether that’s Core Web Vitals remediation, headless architecture scoping, or real-user monitoring setup, we work at the intersection of engineering rigour and business outcome. If your site is drifting from where it should be — or you’re about to build and want to do it right — Let’s talk.