Integrations, languages and performance

Integrations

The external systems the Euro League site connects to. Contentful is always on. Most of the rest are switched on by environment: the code ships in this repository, and an integration comes on in an environment (local, develop, staging, production) when that environment sets its key or address. With nothing set, the integration is simply absent — no script loads and nothing is drawn — so a developer's machine and CI run without any of them. The variables are listed in Environment variables.

Content, data & media

Fans, measurement & consent

Hosting & caching

Configuration slots with nothing behind them

The configuration schema (packages/template-config/src/schema.ts) has slots for these, but nothing in this site reads them: setting one switches nothing on. Each would be a build, not a configuration change.

How a feature is declared, and how an environment variable switches it on, is governed by the typed configuration file apps/web/club.config.ts. See Template config and Features & domains.

Design & tokens

Figma and Token Studio are build-time integrations, not runtime ones — designers work in Figma, and the design tokens flow into the codebase through the token pipeline. They underpin theming and the whole component library, but the live site never calls Figma.

Internationalisation

The site is multi-locale from the ground up. It currently uses one locale, but locale-prefixed addresses, translatable interface copy and the process for adding a language are all Available; full right-to-left (RTL) language support has its foundations in place but is Planned.

Locales

The site can serve content and interface copy in several languages. Euro League runs one locale, en-US — the default and the only one (apps/web/club.config.ts → locales) — and new locales are added through a defined process, not a code rewrite.

Every address carries its locale first: en-US is served under /en, so the home page is /en, an article /en/news/{article} and a team /en/teams/{team}. An address without the locale (/news) redirects to the one with it. This is the segment routing mode in the configuration (the other mode, with no locale in the address, is for a single-locale site that does not want one).

The dictionary still carries label sets for en-GB, fr-FR and it-IT inherited from the template, with translation passes outstanding. They are not served by this site; confirm their state before promising a translated Euro League site in another language.

UI copy: the dictionary

Interface labels — button text, section titles, standard phrases — are managed through a dictionary. The code owns the vocabulary (the set of keys and their default English copy) in code; editors maintain the labels in Contentful, and a label they publish reaches the site without a deploy. A label is looked for in the requested locale, then in en-US, then in the default copy in code. This means the interface is fully localisable without a developer, while the set of things that can be localised stays typed and reviewed.

Right-to-left (RTL)

The design and code layers anticipate RTL: the layout uses direction-aware CSS throughout, and the token layer ships a complete RTL typography set. But the design system's components were authored left-to-right only, so RTL is an engineering effort still to be completed rather than a finished capability.

In short: if ELB asks for an RTL language (Arabic, Hebrew), the honest answer is that the site is built to support it and the groundwork is done, but shipping an RTL locale is a project, not a switch.

Performance & scale

The site is built to serve high traffic cheaply and fast. Everything here is Available today.

Static-first rendering

Every page is served as a pre-rendered shell with cached data: the parts of a page that do not change per visitor are built ahead, and the content inside them is read through the app's cache rather than from Contentful on every request. Listings are path-based — /en/news/page/2 and every filtered view are pages of their own — so they stay cacheable under filtering. Listings and home pages are also cached at the Cloudflare edge, in front of the app; article and content detail pages are served by the app itself, from its cache.

Basketball data is cached by how fast it changes: team lists, profiles, standings and statistics for five minutes, the schedule and an unplayed game for one minute, a finished game for five. Live answers are never cached — while a game can be live, the browser asks the site for it directly (see Sport).

Targeted cache invalidation

Rather than rebuilding the site on every edit, the site refreshes exactly the pages a change affects. When an editor publishes, a webhook expires only the relevant cached content, and purges the same pages from the Cloudflare edge by tag; time-based limits act as a self-healing floor if a webhook is ever missed. The result is near-instant freshness with minimal recompute.

Multi-instance caching

Each deployed environment runs the app across several server instances, so it uses a shared Redis cache that lets one editorial change reach every replica. It is config-gated (on where CACHE_REDIS_URL is set) and isolated per environment — each environment has its own Redis, never shared — and off where it is unset (a single local instance needs nothing extra).

Lean pages

A Lighthouse campaign in October 2026 cut what each page has to download and lay out. The site's styles are split by section: every page loads a shared stylesheet of about 140 KB compressed (it was one 3 MB file), and the video and basketball pages each add their own smaller part only where they are used. The brand's design values are declared once for the whole page rather than on every component, which cut style and layout work on the home page by roughly two-thirds.

A load-test script (scripts/loadtest/eviction-storm.mjs) checks that a mass cache refresh under heavy traffic is absorbed by serving slightly stale pages while fresh ones are built, rather than flooding Contentful. It is run against a real deployment with Redis, not in CI.

SEO & discoverability

The scale story in one line

Pre-rendered pages with cached data, refreshed precisely when content changes, cached at the edge and shared across instances — so traffic spikes hit the cache, not the CMS or the Competition Engine. For the full picture see Scale & performance.