PFO Proxies — Proxy Network Marketing Site · beiryu
PFO Proxies — Proxy Network Marketing Site
Live
A Next.js 16 marketing site for a six-line proxy provider, built around an interactive canvas world-map of 1,033 mapped network nodes, a three-layer motion system that degrades safely to no-script and reduced-motion, and a synthesised audio layer that leaves every page server-rendered.
PFO Proxies sells the six product lines this category runs on — ISP, datacenter, IPv6, residential, unlimited residential, and mobile — to buyers scraping, verifying ads, tracking fares, and operating accounts at scale. The site covers products, pricing, use cases, locations, partners, a reseller programme, a blog, and the full company and legal surface.
In a category where every competitor's site looks broadly identical, the differentiation had to come from the experience rather than the copy. This build spends its complexity budget on three things a visitor actually feels: an interactive network map that responds to the cursor, motion that is choreographed rather than sprayed, and an optional audio layer — all delivered without giving up server rendering or accessibility.
The signature background is a canvas field of dots in the shape of a world map, and it is the largest single component in the codebase.
The geometry is not procedurally generated. It is stored as structured text — one row per line in the design's own coordinate space — so all 1,033 node positions stay readable and reviewable in a diff rather than hiding inside a binary or a generator seed. It is parsed once at import into a flat coordinate array.
The behaviour layered on top:
A small percentage of nodes pulse on their own clock, each with an independent period, so the field never flashes in unison
The cursor lights the nearest cluster through a lagging follower, capped per sample and fading out — a trail rather than a spotlight
A click sends a lit band outward across the field toward the far corner
Every node holds one of exactly two brand colours, switched instantly and never blended, both read from design tokens so the field follows the theme and re-reads on a change
The backing store is capped with density giving way first, so the canvas can never exceed a browser's bitmap limit and blank itself
Rendering halts off screen, and reduced-motion visitors get a single static frame
A short grace window treats a pointer-leave that is immediately reversed as a focus blip rather than a real exit — the kind of detail that only surfaces from watching someone actually use it.
Reveal animation is split across two mechanisms on purpose, and the reasoning is documented in the codebase.
Above the fold, blocks fade in through CSS at first paint — content already on screen must not wait for hydration, and some of it cannot accept a wrapper at all: a sticky element would hand its layout placement to the wrapper, and a list that re-mounts on input would replay its animation on every keystroke. Below the fold, a JS-driven reveal component takes over. The shared rise distance, duration, stagger, and easing curve live in one module so the two paths move identically — including the easing curve written out by hand, because the library's named default is a different curve and would visibly decelerate on a later beat than the CSS path.
Those constants sit in their own module for a concrete architectural reason: the reveal component is a client module, and a value exported from a client module and imported by a server component arrives as a reference, not as the value.
Reduced motion is then handled at three levels rather than one — on the CSS path, on the JS path, and as pinned resting states in the stylesheet — with a no-script fallback as the final net, so a page whose JavaScript never runs does not render as a screen of blank blocks.
The numeric ticker is the same care at small scale. Each decimal place derives its offset from one shared spring rather than its own, because an independently animated digit column rolls backwards on the nine-to-zero step; deriving from the whole number produces real carry, and repeating the first cell makes the wrap invisible.
The site carries a synthesised audio layer — seventeen semantic sound roles across five categories, generated from an instrument system rather than shipped as sample files, so it costs no network weight at all. Volume is tuned per category to intent: hover sounds sit low because they fire constantly, and celebratory cues stay off entirely on pages that have nothing to celebrate.
The integration is the interesting problem. Most of the site is server-rendered, and reaching a sound hook conventionally would mean converting every card, sidebar, and banner into a client component purely to make a noise. Instead, a zone component wraps a region and listens by event delegation, so its children stay exactly what they were — server-rendered elements passed straight through. It listens on the event that actually bubbles to the zone, and tracks the last-hovered element so moving across a card's own children does not retrigger the sound. The provider renders no DOM of its own, keeping the tree server-rendered from the root layout down.
Every page's content is a typed module checked against shared interfaces — six products with per-card tone and feature list, nine use cases, twelve locations, a full FAQ set, partners, testimonials, and posts. The five dynamic sections each resolve a slug against a record and enumerate it for static generation, so adding a page is adding a key.
The data layer also carries the reconciliation work. Where source content arrived inconsistent — the same IP-count pool paired with different countries across two exports, product descriptions encoded two opposite ways across six cards — it is normalised once at the source, with the decision recorded, rather than being patched per component downstream.
This codebase is unusually well documented, and not in the way that means every function has a comment restating its name. The comments explain roads not taken: why a sticky element gets the fade but not the rise, why configuration lives in a typed module rather than where the library's documentation suggests, why a particular animation fill mode is load-bearing rather than decorative, why a fallback selector must avoid certain characters that would be silently escaped and corrupted.
That is what makes a site like this maintainable six months later — the reasoning lives in the repository, so the next engineer to open the file knows why it is the way it is.