The Death of a Website  ## Metadata - Author: [[Jono Alderson]] - Full Title: The Death of a Website - Category: #articles - Document Note: --- tags: [web-performance, JavaScript, web-architecture] author: Jono Alderson source: jonoalderson.com reference: [https://www.jonoalderson.com/misc/the-death-of-a-website/] date created: 2025-10-09 12:00 --- # 🏷️ Title: The death of a website ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened. - A noir-style investigation recounts “another site down” where “a website that used to be fast, lean, full of life” is now dead. - Why it matters. - “Cause of death? Same as always. Blunt-force abstraction.” Systemic complexity, JS overuse, and managerial pressure rot the web. - Key stakeholders. - Engineers, designers, PMs, execs/investors, users, and the broader web ecosystem. - Risks and tradeoffs. - Optimizing metrics over experience; speed vs. features; iteration vs. maintainability; abstraction vs. clarity. - Bottom line. - “The crime isn’t that the web is dying. It’s that we’ve stopped treating it like something alive.” ## 📖 Main Content - Core arguments: - Modern sites die from “systemic neglect” and “chronic misuse of JavaScript,” not malice. - Framework-heavy stacks (“Weapon of choice: framework, heavy calibre. Probably React, maybe Vue.”) create fragile, bloated experiences. - Teams “optimise for the wrong things” (e.g., green charts for Core Web Vitals) while real usability decays. - Continuous patches mask deeper architectural debt: “the corpse will twitch again.” - Context and terms: - Core Web Vitals and LCP matter, but proxy metrics can be gamed and miss holistic UX. - Headless CMS, microservices, and hydration scripts add indirection and failure modes if unmanaged. - Uncertainties: - Not all frameworks cause bloat; discipline and constraints can yield excellent outcomes. - Organizational incentives vary; some teams ship performant, resilient stacks. ### 🗒️ Notes - “No pulse, no structure, no soul. Just a tangle of wrappers, scripts, and styles…” - “Cause of death? Same as always. Blunt-force abstraction.” - “Weapon of choice: framework, heavy calibre. Probably React, maybe Vue.” - “Clean charts, broken sites. Numbers that make investors smile while users drown in latency.” - “You can fake a pulse for a while. You can’t fake a heartbeat.” - “Corporate homepages bloated on tracking scripts… storefronts drowning in dependencies… portfolios buckling under their own JavaScript.” - “Nobody writes websites anymore. They assemble them… to deliver experiences nobody asked for.” - “Contributing factors: build complexity, managerial optimism, chronic misuse of JavaScript.” - “We’ve normalised it… background noise in a city that forgot what silence sounds like.” - “The crime isn’t that the web is dying. It’s that we’ve stopped treating it like something alive.” ## 📚 References - Core Web Vitals overview (https://web.dev/vitals/) - Largest Contentful Paint (LCP) (https://web.dev/lcp/) - React official docs (https://react.dev/) - Vue official docs (https://vuejs.org/) - Hydration explained (https://www.patterns.dev/posts/hydration/) - Headless CMS concept (https://www.contentful.com/r/headless-cms/) - Microservices overview (https://martinfowler.com/articles/microservices.html) - Chrome DevTools (https://developer.chrome.com/docs/devtools/) ## 🗣️ Paraphrase - Paragraph A: - A detective-like expert examines a once-healthy website now crippled by excessive layers of code and tools, signaling systemic failure. - Paragraph B: - Despite good intentions and “best practices,” over-optimization and abstraction bury content and user needs under complexity. ## 📰 Newsletter - This week’s read: a gripping lament for sites that “used to be fast, lean, full of life” but now twitch under patches. Takeaway for WordPress pros: measure what matters beyond green Vitals. Audit third-party tags, cut JS, and prefer server-rendered, semantic HTML. Try Performance Lab, Query Monitor, and Lighthouse CI. Community picks: Core performance chats, theme.json tips, block patterns that don’t bloat, and hosting configs that hit TTFB budgets. Build less; ship clearer. ## ✅ Action Items #### DevRel - Talks: “Blunt-force abstraction: diagnosing web rot” with live audits. - Demos: JS-free patterns, server-rendered templates, progressive enhancement. - Docs: perf budgets, examples-first patterns, CI checks. - Campaign: “Fix before you add” content series; attribution via UTMs. - Community: office hours for perf triage; incident review templates. #### OSPO - Governance: mandate perf budgets and decision records for new deps. - Compliance: license/dep scans; quarterly audits. - Security: third-party tag intake, embargo policy, signing. - SBOM: own components; freshness SLOs and deprecation paths. - Developer support: training on hydration costs; review hours. - Upstream: fund critical perf tooling; MoUs with key projects. - Strategy: OKRs tying UX metrics to revenue and retention. #### Community - Maintainers: roadmap clinics; release hygiene and rollback drills. - Contributors: first-issue perf bounties; pairing sessions. - Sponsors: milestone-linked budgets; transparent impact reports. - Ecosystem: cross-project outage drills; disclosure playbooks. #### WordPress - Core: triage slow paths; enforce performance budgets. - Core Performance: profiling plan; dashboards; perf bounties. - Core AI: guardrails; eval sets; no regressions to UX. - Core Program Team: rituals; cross-team dependencies; retros. - Mobile: telemetry review; offline UX priorities. - Playground: repro labs; education modules on perf smells. - Community: meetup kits on “less JS, more HTML.” - Training: lesson plans on CWV, server rendering, PEF. - Marketing: narrative—value of boring tech; case studies. - Support: KB gaps on third-party tags; escalation paths. - Design: UX audits; reduce motion; design tokens. - Documentation: examples-first patterns; style guide. - Photos/TV: submission and caption standards. - Polyglots: locale perf checks; glossary alignment. - Accessibility: WCAG reviews; heatmap of issues. - Meta: API reliability; contributor tools perf. - CLI: plugin scaffolds with perf defaults. - Hosting: cross-host perf checklists and telemetry. - Tide: scoring transparency; false-positive loops. - Openverse: ingestion performance; moderation policy. - Themes: linting; mentoring; test matrices. - Plugins: security liaisons; provenance checks. #### The WPCC - Programs: fellowships and maintainer stipends for perf initiatives. - Projects: governance clinics; documentation sprints. - Funding: matched grants; milestone payouts; open ledgers. ### FAIR - Independence: local metadata, provenance, signature checks. - Policies: funding transparency; sunset clauses; anti-capture. - Governance artifacts: reusable charters and scorecards. ## 🧪 Hypotheses - Teams optimizing solely for CWV risk worse real-user satisfaction and retention. - Reducing client-side JS by 30–50% improves task success and conversion. - Strict third-party tag governance lowers failure rates and improves TTI. - Server-rendered, semantic-first architectures outperform SPA baselines on resilience. ## 📊 Methodology - A/B test JS reduction and measure RUM (LCP, INP, CLS) plus task success. - Observational study correlating tag counts to error rates and bounce. - Case-control of SSR vs. SPA builds on identical content; measure uptime, UX, and SEO. ### ❓ Questions - Which incentives cause “clean charts, broken sites”? - What minimal abstraction yields maximal maintainability? - How to - Summary: The call came in after midnight. Another site down. Same pattern. Same rot. Somebody’s killing the web, and nobody’s talking. - URL: https://www.jonoalderson.com/misc/the-death-of-a-website/  They called me just after midnight. Said they’d found another one. A website that used to be fast, lean, full of life, now lying cold on the server room floor. I threw on my coat and grabbed my toolkit. Chrome DevTools. A strong coffee. A sense of déjà vu. When I arrived, the place was already crawling with engineers. The kind with ergonomic chairs and stress twitches. Nobody met my eye. They all knew how this story ended. The homepage was still up on a monitor, looping a loading animation like a bad joke. Looked fine from across the room – gradients, glassy buttons, a hero image big enough to land a plane on. But the moment I hit *View Source*, I knew I was staring at another corpse. Same story as the last dozen. No pulse, no structure, no soul. Just a tangle of wrappers, scripts, and styles, every line stepping on the toes of the one before it. A thousand dependencies all arguing about whose fault it was. I scrolled deeper. The markup was dense and panicked, trying to hold itself together. Once upon a time, you could tell what a site was for just by glancing at its code. Headlines, paragraphs, lists – neat little rows of intention. You could read it. Like a book. Now it’s all ceremony and scaffolding. Somewhere in the mess, I caught a glimpse of the old world – a clean `<h1>`, a fragment of actual content. The outline of meaning, trapped under layers of build artefacts. It was enough to remind me what this used to be. What it should be. Cause of death? Same as always. *Blunt-force abstraction*. Weapon of choice: *framework, heavy calibre*. Probably *React*, maybe *Vue*. You can tell by the wounds – duplicated imports, mismatched modules, hydration scripts still twitching long after the heartbeat’s gone. Nobody meant to kill it. They never do. They just wanted to make it better. Faster. Scalable. Every dev swears they’re saving time; none of them notice the cost. The logs told the rest of the story. Requests timing out. Scripts looping. Memory bleeding out by the kilobytes. Third-party tags nesting like rats in the foundation. The database crying for help in stack traces nobody reads. In the corner, a junior developer was pacing. Fresh out of bootcamp, eyes wide, wearing a hoodie that said *Move Fast, Fix Things*. He told me they’d followed all the best practices – modular architecture, headless CMS, microservices, graph queries, everything in the cloud. I nodded. That’s how they all start. Then they optimise for the wrong things until there’s nothing left to save. He said the Core Web Vitals were nearly in the green. That they’d made great progress on improving their LCP scores this quarter. I told him I’d seen those reports before — clean charts, broken sites. Numbers that make investors smile while users drown in latency. You can fake a pulse for a while. You can’t fake a heartbeat. There was a silence then, the kind that fills a room after truth walks in. I closed the laptop, took a sip of my coffee, and stared at the glow on the wall. It wasn’t the first site I’d seen go down this way. It wouldn’t be the last. They think it’s random, a one-off, a bad deploy. But I’ve been on this beat long enough to know a pattern when I see one. The whole city’s crawling with corpses – corporate homepages bloated on tracking scripts, e‑commerce storefronts drowning in dependencies, portfolios buckling under their own JavaScript. Every week there’s another obituary, another site that “*just stopped working*” after the last sprint – traffic and visibility flatlined. And still, they keep building. New tools, new frameworks, new ways to wrap the same mistakes in shinier wrappers. I see the same scene play out over and over. PMs asking for “more interactivity”. Designers chasing whatever Apple’s doing this week. Engineers stacking abstraction on abstraction, until the original content’s just a rumour. Nobody writes websites anymore. They assemble them; out of parts they don’t understand, shipped by systems they can’t see, to deliver experiences nobody asked for. By morning, they’ll push a patch. They’ll call it a fix. And the corpse will twitch again – enough to convince the client that it’s still alive. I pack up my gear. Another case closed. Another line in the report. “*Cause of death: systemic neglect. Contributing factors: build complexity, managerial optimism, chronic misuse of JavaScript.*” Outside, the rain’s coming down hard, pixelated by the streetlights. I watch the reflection of a thousand broken sites shimmer in the puddles. The web used to be a city that never slept. Now it’s a morgue with good Wi-Fi. If you want to see it for yourself, you don’t need me. Pick a site. Any site. Pop the hood. Hit *View Source*. And tell me you don’t smell the crime. I used to think these were murders. Something deliberate. A hand on the keyboard, a choice that killed a page. But after a while, you see the pattern. It isn’t malice – it’s neglect. A slow rot that seeps in through every sprint, every deadline, every “*good enough for now*.” Nobody’s swinging a hammer. They’re just walking away from the cracks. Whole neighbourhoods of the web are crumbling like that – bright from a distance, hollow underneath. Teams push updates, patch bugs, add new dependencies, all to keep the lights on a little longer. Then they move on, leave the old code flickering in the dark. We’ve normalised it. The sluggish loads, the broken forms, the half-working interactions – background noise in a city that forgot what silence sounds like. Ask around and nobody even calls it decay anymore. They call it iteration. That’s the trick of it. The crime isn’t that the web is dying. It’s that we’ve stopped treating it like something alive. So when the next call comes in – another homepage gone cold, another app bleeding users – I’ll pour another coffee and head back out. Because that’s what you do in this line of work. You don’t solve the case. You just keep showing up to document the decline., The Death of a Website, Jono Alderson, 01k74srmfexqwcpmj2dnegcjbg.