Tags: web-dev analytics landscape
2026-08-16 - Landscape - Industry
Captured: 2026-08-16
Re-check by: 2027-02-16
Confidence: mixed — stated per section. Verified against sources on the day; several areas rest on secondary commentary rather than primary documentation.
Where the field stands in August 2026. The value of this note is the diff against the next one, not the content — so it is not to be corrected later.
Privacy and measurement
Confidence: high. Verified against Google’s own announcements and ICO commentary.
The five-year expectation that third-party cookies would disappear from Chrome did not happen, and the replacement programme has been wound down.
- Google abandoned third-party cookie deprecation in July 2024, with no replacement date. In 2026 Chrome presents a privacy choice, making them opt-in rather than removed
- Privacy Sandbox is being retired. Announced October 2025; deprecation began Chrome 144 (January 2026), removal targeted for Chrome 150 (July 2026). Topics, Protected Audience and Attribution Reporting are going. CHIPS, FedCM and Private State Tokens survive
- Safari and Firefox have blocked third-party cookies by default for years, independently of any of this
The quieter change matters more. First-party identifiers got much shorter-lived. Safari caps cookies written by document.cookie at 7 days, and 24 hours when arriving with tracking parameters. Server-set cookies via Set-Cookie aren’t capped the same way — which is why server-side collection moved from optimisation to necessity.
UK regulation moved in February 2026. PECR Schedule A1 now provides a narrow exception for first-party, statistics-only analytics: data stays with the operator, used solely for service improvement, clear information, free opt-out. The proposed legitimate interest route for analytics did not make it into the Data (Use and Access) Act. Commentary is consistent that GA4 falls outside the exception, because data goes to Google for Google’s purposes.
What I’d expect to have changed by February: whether the ICO enforces against sites relying on the new exception, and whether any self-hosted analytics tool positions itself explicitly around it.
Feeds: Browser Privacy Restrictions · UK GDPR and PECR for Analytics · Consent Management · Client-Side vs Server-Side Tracking
Measurement tooling
Confidence: high on the vendor fact, low on the direction.
Google announced on 20 May 2026 that Google tag and Google Tag Manager are merging — Google tags become fully capable GTM containers, able to send directly to Google destinations without loading gtag.js as a second layer. Opt-in; existing containers keep working. New snippets drop the gtag config command in favour of a GTM init trigger.
Genuinely open: whether the industry is consolidating into tag managers or moving away from them. Both currents are real — engineering-led teams increasingly instrument in code and push processing server-side, while marketing-led teams consolidate further into containers. I could not find good evidence either way, and the sources that address it are vendor content. Recorded as unresolved, which is what February will answer.
Feeds: Tag Managers · Server-Side Tag Management · Tag Manager Performance
Experimentation tooling
Confidence: high. Acquisitions verified against primary reporting.
The category consolidated hard in under two years.
| Statsig → OpenAI | September 2025, $1.1bn. Still operating independently |
| Eppo → Datadog | Folded into their product analytics |
| VWO + AB Tasty | Merging. ~$100M combined ARR |
| Optimizely, Adobe Target | Still the enterprise incumbents |
| GrowthBook | Open-source, warehouse-native, independent |
| Convert, Kameleoon | The remaining independent mid-market |
The structural split is now clear: visual-editor client-side tools for marketing teams, warehouse-native server-side tools for engineering-led ones. The middle is where the acquisitions happened.
Feeds: Client-Side vs Server-Side Testing · Assignment and Bucketing · Optimizely · GrowthBook
Data stack
Confidence: medium. Direction is well-attested; adoption figures aren’t.
The movement is away from “put everything in a warehouse and query it there”.
- DuckDB — in-process analytical database. Queries Parquet and Iceberg directly from a laptop or notebook. The interesting question it raises is whether a given workload needs dedicated server infrastructure at all, and for a growing number of teams the answer is no
- Apache Iceberg — the open table format converging as a standard. ACID transactions, time travel and schema evolution on plain object storage, with Spark, Flink, Trino, ClickHouse and DuckDB all reading the same tables
- ClickHouse — real-time columnar OLAP for high-concurrency analytical queries
- dbt — still effectively the default modelling layer wherever a warehouse exists
The emerging pattern is hot/cold: real-time engine for recent data, Iceberg on object storage for durable history.
Feeds: Warehouse-First Analytics · Event Streams vs Aggregates · BigQuery
Crawlers and discoverability
Confidence: medium-high. Mechanism well-attested; volume figures are not.
The materially new fact: AI crawlers do not render JavaScript. GPTBot, ClaudeBot, PerplexityBot, Bytespider and Meta-ExternalAgent read the HTML they’re served and stop.
That changes the client-side rendering argument in kind rather than degree. Googlebot’s two-wave indexing means JS-rendered content is indexed late; for AI crawlers it isn’t indexed at all. Server rendering moved from a performance preference to an indexability requirement.
Two operational details:
- Training and search crawlers are separate bots. GPTBot (training) versus OAI-SearchBot (search); ClaudeBot versus Claude-SearchBot. You can decline training while staying visible in AI search
llms.txtis not adopted. As of early 2026 no major vendor had committed to reading it and traffic to the file was negligible. It’s a proposal, not a standard — don’t spend time on it
Feeds: Rendering and SEO · Crawling and Indexing · Technical SEO
JavaScript runtimes
Confidence: medium. Sources were comparison blogs; treat characterisations as directional and ignore the adoption percentages they quote.
Three runtimes, and the contest is less dramatic than the discourse.
| Position | |
|---|---|
| Node | The default. Largest ecosystem, best production stability, full npm compatibility |
| Deno 2 | Pivoted to full Node/npm compatibility, abandoning the incompatibility that limited it. Security-first sandbox model, standards-based |
| Bun | Built on JavaScriptCore rather than V8. Substantially faster at install, I/O and HTTP throughput. Ongoing reports of instability in long-running processes |
The honest summary: Bun is compelling as a toolchain — install and test speed are not marginal — and less proven as a long-running production runtime. Deno 2 removed its own biggest adoption barrier. Node remains the safe answer and is not under threat.
What I’d expect by February: whether Bun’s long-running stability reports have resolved, since that’s the only thing standing between it and default-toolchain status.
Feeds: Build Tools · Package Managers
Frontend frameworks
Confidence: medium. Version facts consistent across sources; “which is best” commentary discarded.
The ecosystem settled into two architectures answering the same question differently:
SERVER COMPONENTS ISLANDS
React 19, Next.js 16 Astro 5
components render on page ships as static HTML,
the server, stream HTML, only marked islands hydrate
bundle small by default framework-agnostic per island
Current state: React 19 stable across the ecosystem. Next.js 16 shipping production Turbopack builds. Astro 5 added a Content Layer API and build performance work. Svelte 5 compiler-based reactivity, with SvelteKit alongside.
The relevant read for retail: islands suit commerce front ends better than the discourse suggests, because most of a product or category page is content rather than application — see Islands Architecture. Server components attack the same problem from the other side.
Feeds: Rendering Strategies · Hydration · Islands Architecture
CSS
Confidence: high. Baseline status is objectively checkable.
The largest expansion of the language in a decade has landed and is now safe to use. Baseline across all engines: container queries, :has(), subgrid, cascade layers, native nesting, @scope, OKLCH, color-mix(), logical properties, and the View Transitions API (single-page and cross-document).
Also stable in current Chrome, Safari and Firefox: Popover API, anchor positioning, scroll-driven animations.
The consequence worth acting on: a meaningful amount of JavaScript written in the last five years is now replaceable with CSS. Tooltips and dropdowns via popover and anchor positioning; page transitions via View Transitions; component-scoped responsiveness via container queries rather than breakpoints.
Feeds: Container Queries · Cascade Layers · View Transitions · Responsive Design
AI in the development workflow
Confidence: low-medium. Directionally consistent, but the specific figures come from vendor and aggregator blogs and should not be quoted.
The shift is from autocomplete to agents that take a task and return a change.
- Stack Overflow’s 2025 survey put developers using or planning to use AI tools at 84%, up from 76% — the one figure here with a named source
- Adoption of agentic tools is far lower than adoption of assistants. Roughly half of developers reported still using autocomplete only
- Review has overtaken writing as the larger time cost. Multiple sources report more hours per week reviewing AI-generated code than writing new code [CHECK: the specific hours figures are from a single aggregator and I’d not repeat them]
Two emerging problems worth watching, both structural rather than teething:
- Cost volatility. Per-request pricing producing monthly bills that swing several-fold
- Prompt injection as a real attack surface, larger than the IDE-completion model implied
What I’d expect by February: whether review burden is being addressed by tooling or is simply the new steady state, and whether any consensus emerges on reviewing generated code as a distinct skill.
Feeds: AI Coding Tools · Code Review · Supply Chain Security
Ecommerce platforms
Confidence: low. Not separately researched — included for completeness and to be filled properly next time.
Shopify remains the platform most of the mid-market runs on. Headless adoption continues without displacing the monolithic default, and the checkout constraint remains the binding limit on both measurement and customisation. See Headless Architecture and Checkout Instrumentation Constraints.
Flagged as the weakest section here. February’s snapshot should research it properly rather than inheriting this paragraph.
What I expect to be wrong
Recorded so the next snapshot can check:
- The Google tag / GTM direction. I’ve stated the vendor fact and declined to state the industry direction. February should be able to
- Bun’s production readiness. I’ve characterised it as unproven for long-running services on the basis of secondary reports
- The PECR exception’s practical reach. Whether anyone actually relies on it, and whether the ICO’s position is what commentary assumed
- AI agent adoption. The gap between assistant adoption and agent adoption is the number most likely to have moved