Author: teserakt_admin

  • Practical Guide to Web Performance Budgets on Client Projects

    Most web agencies know they should have performance budgets. Few actually enforce them. After a project where a last-minute carousel widget pushed a client’s LCP past 4 seconds on launch day, we made budgets a contractual deliverable — not a nice-to-have.

    What goes into a budget

    We set three numbers per project:

    • LCP ≤ 2.5 s on a simulated mid-tier Android device over 4G (Lighthouse mobile preset)
    • Total JS ≤ 200 KB (compressed) for the initial route
    • CLS < 0.1 — no layout shift after fonts load

    These map directly to Core Web Vitals thresholds, which keeps the conversation simple with clients who care about SEO.

    Enforcement in CI

    We use bundlesize for the JS limit and a Lighthouse CI step for LCP and CLS. Both run on every pull request. A failed check blocks the merge — no exceptions, no “we’ll fix it later.” The key is configuring the Lighthouse CI budget file at project kickoff, not after launch.

    {
      "budgets": [
        {
          "resourceSizes": [{ "resourceType": "script", "budget": 200 }]
        }
      ]
    }

    The client conversation

    When a feature request would break the budget — a full-page video background, a heavyweight slider library — we frame it as a trade-off, not a refusal. “We can ship this, but it will push LCP to ~3.8 s and likely drop your search ranking for these pages. Here’s a lighter alternative that achieves the same effect.” Clients almost always choose the lighter path when the cost is concrete.

    Performance budgets have saved us from scope creep disguised as features more than once. Build them in at the proposal stage and they become a shared language, not a developer complaint.

  • How to Run a Technology Strategy Engagement Without It Becoming Shelfware

    The graveyard of enterprise technology strategy is full of documents. Beautifully formatted, thoroughly researched, delivered with a presentation and a Q&A — and then never looked at again. The teams we work with are smart; the documents weren’t bad. The problem was structural.

    The problem with deliverable-centric engagements

    Most strategy engagements end with a deliverable: a report, a roadmap slide deck, a set of recommendations. The consulting team presents it, the client applauds, and then the client goes back to the day job. The document has no forcing function. It doesn’t connect to the next sprint, the next hire, or the next budget conversation.

    What we do instead

    We structure engagements around decisions, not documents. At kickoff, we ask: what are the three most important technology decisions you need to make in the next six months? Everything we do during the engagement is in service of those specific decisions. The output is a decision memo, not a strategy paper — shorter, more direct, with a clear recommendation and the evidence behind it.

    The 30-day follow-through

    We include a 30-day follow-through session in every engagement. Thirty days after delivery, we meet with the client to review which recommendations have been acted on, which have been deprioritised (and why), and what obstacles have appeared. This creates accountability and surfaces implementation problems early when they’re still cheap to address.

    The metric we use internally

    We track the “recommendation adoption rate” — the percentage of our recommendations acted on at the 90-day mark. A low adoption rate is a signal that the engagement was too abstract, too expensive to implement, or solving the wrong problems.