BT / EE UK E-commerce Platform
High-traffic telecom storefront where Core Web Vitals and WCAG are release criteria.
Role
Senior Frontend Engineer — performance, accessibility & GraphQL integration
Engagement
Full-time at Segwitz
Client
BT / EE (UK telecom)
Period
2023 — 2024
The problem
A national telecom storefront serves enormous organic and paid traffic, ranks in a brutally competitive SERP, and converts on a multi-step journey. Every hundred milliseconds of LCP is measurable revenue, accessibility is a legal and brand requirement, and the frontend consumes a large GraphQL catalogue API owned by another team. Slow pages, janky journeys and inaccessible components were direct commercial problems.
My responsibility
Senior frontend engineer on the storefront: rendering strategy per route, GraphQL integration, Core Web Vitals remediation, WCAG conformance work, and contract testing against the backend catalogue API. I also owned the frontend performance reporting that went to stakeholders.
Surfaces shipped
Storefront
Public catalogue and offer pages: mobile plans, handsets, broadband and TV, with comparison, eligibility and pricing logic.
Checkout journeys
Multi-step acquisition flows with address, credit and tariff selection — conversion-critical and heavily instrumented.
Content & campaign surfaces
Marketing-led landing pages and campaign templates rendered from a CMS with strict performance budgets.
Architecture
How it was structured, and the reasoning behind each boundary.
- 01
Deliberate rendering strategy per route
Catalogue and offer pages are SSG/ISR with targeted revalidation so marketing changes go live without a deploy. Eligibility, pricing and checkout are dynamic and streamed. Nothing is server-rendered by default just because it can be.
- 02
GraphQL with a typed client layer
Operations colocated with the components that use them, generated types, and a normalised cache layer. Field-level selection kept payloads small — the catalogue API can return far more than a page needs.
- 03
Component-driven UI with accessible primitives
Storybook-backed components with keyboard and screen-reader behaviour specified in the component contract, so accessibility is a property of the primitive rather than something each page re-implements.
- 04
Contract testing at the API boundary
Consumer-driven contract tests verify the frontend's assumptions about the GraphQL schema. Breaking changes fail in CI, which matters when the API is owned by a different team on a different release train.
- 05
Performance instrumentation
Lab (Lighthouse CI) plus field (RUM) measurement, with budgets per route. Improvements were only claimed when the field data agreed with the lab.
Key challenges
- 01
LCP on image-heavy offer pages
Handset imagery dominates the viewport. Fixing it meant responsive srcsets at real device sizes, modern formats, correct priority hints on the single above-the-fold image, CDN cache configuration, and removing the layouts that caused images to be discovered late.
- 02
Third-party script weight
Analytics, tagging, chat and payment SDKs competed with the page. Scripts were audited, deferred or moved off the critical path, and their cost reported per tag rather than accepted as unavoidable.
- 03
WCAG conformance at catalogue scale
Thousands of templated pages inherit whatever the components do. Fixes had to land in the primitives: focus management in modals and mega-menus, honest labelling on price and tariff tables, contrast on promotional styling, and a keyboard path through every journey.
- 04
Layout shift from dynamic pricing and promos
Eligibility-dependent content arriving after render caused CLS. Reserved space, skeleton sizing matched to real dimensions and streamed placeholders removed the shift without delaying the content.
- 05
Another team's API, another team's release
Contract tests plus a defensive rendering layer meant schema drift degraded a component gracefully instead of blanking a revenue page.
Implementation
- 01
Measured before touching anything
A baseline across the highest-traffic routes — lab traces, field percentiles, bundle analysis, script waterfall. The remediation list was ranked by measured impact, not intuition.
- 02
Attacked the critical rendering path
Route-level code splitting, removal of barrel imports that pulled entire libraries, inlining of critical CSS, self-hosted fonts with font-display control and preconnects to the origins that actually mattered.
- 03
Made accessibility a component contract
Each shared component documents its keyboard behaviour, ARIA surface and contrast requirement; stories include the failing states. Accessibility review became part of PR review.
- 04
Guarded the gains
Performance budgets in CI with a hard failure on regression, so an improvement survived the next six feature releases.
Results
40%
LCP improvement
35%
FCP improvement
95+
Lighthouse score
- 0140% improvement in Largest Contentful Paint on the targeted storefront routes.
- 0235% improvement in First Contentful Paint over the same baseline.
- 03Lighthouse scores above 95 across performance, accessibility, best practices and SEO on audited routes.
- 04WCAG conformance issues fixed in shared primitives, propagating to every templated page rather than per-page patches.
- 05Breaking GraphQL schema changes caught in CI by contract tests instead of surfacing in production.
Technologies
- Next.js
- React
- TypeScript
- GraphQL
- Tailwind CSS
- Storybook
- Cypress
- Jest
- AWS
- Docker
- Lighthouse CI
Technical highlights
- Per-route rendering strategy: SSG/ISR for catalogue, streamed dynamic for eligibility
- Image pipeline rebuilt around real device sizes and discovery order
- Third-party script audit with per-tag cost reporting
- Consumer-driven contract tests against an external GraphQL API
Building something similar? I’d like to hear about it.
Start a conversation