Award Site Teardowns
Awwwards SOTD / The FWA中文
2026.09.09InstrumentRealtimeThe FWA FOTD

Awards Racing

Awards Racing is a drift racer that runs in a browser, and the company that made it sells waste-management software out of Dubai. You play a junior designer, driving into design-app icons and dodging irritated jurors. Four gauges down the right of the screen read DESIGN, USABILITY, CREATIVITY and CONTENT, and every like you collect pushes one of them up. The Awwwards categories serve as the health bar, which is why the game never has to write a line of tutorial.

Visit site
Awards Racing first screen

Concept

The hard part of shipping a game as a website is not the play, it is getting anyone to start. This one solves it by dropping the player into a situation they already know.

Before the race there is a garage. The left side reads VISITOR-152, JUNIOR DESIGNER · LVL 1, a small purple monster in a party hat sits on the roof, and the car is covered in stickers, one of which reads ALIGNMENT? MORE LIKE ALIGN-MAYBE. On the right is the day's leaderboard, with drivers called NEWCOMER-9, CURATOR-777, THINKER-576, AUTEUR-22 and RUNNER-341 racing for TEAM BÉZIER, TEAM 4O4, TEAM NAN, TEAM OFF-BY-ONE and TEAM SEGFAULT.

The garage: character, car, daily leaderboard, controls along the bottom

None of those names are arbitrary. Every one comes out of what designers and front-end developers deal with daily, so getting one makes you want the next, and getting them is itself the thing that pulls you in.

Enter starts the race. The ground is ultramarine, divided into irregular polygons by white lines like a zoomed-in territory map. The camera looks down at the car, four gauges sit down the right edge for DESIGN, USABILITY, CREATIVITY and CONTENT, and a multiplier with a distance counter sits at the top beside a tally of likes.

The track: white lines on ultramarine, with the four Awwwards categories as gauges down the right

Turning the award categories into gauges is the smartest move in the project. Anyone who has spent time in this field recognises those four words without being told what they mean, so the game borrows an existing understanding and skips an entire tutorial.

The obstacles scattered across the track are design-software app icons, built as slowly rotating cubes. What you collect is a blue like and a cup of coffee.

Obstacles: app-icon cubes floating over the track, with chromatic fringing at the edges

The whole world repaints when a stage advances. Measured further in, that ultramarine has become magenta, the icon cubes have shifted to match, and they are considerably denser than in the first stage.

Scoring is distance plus likes. After collecting likes, CREATIVITY in that right-hand column had risen from 50 to 52. In this world likes genuinely convert into scores, which is both the mechanic and the joke the project is making.

Design

The interface is almost entirely one HUD layer over the scene, and it is organised by function rather than by looks.

The mark sits top left, a row of key prompts sits bottom left with arrows for DRIVE, Q for FIRE, E for BOOM, Shift for NITRO, space for JUMP and R for RESTART, each drawn as an actual keycap. Three item counters sit midway down the left, the four score gauges down the right, multiplier and distance at top centre, pause and share at top right.

Each corner handles one thing and the middle is left entirely to the track. That division is ordinary in games but worth recording on the web. The tighter a HUD hugs the edges, the more playable area survives, and most web overlays do the opposite and reach for the middle.

Bottom left also carries a live frame-rate readout showing 60 FPS. Printing frame rate on screen in a consumer game is talking to people who know what it means, and the audience for this project is the trade.

The settings panel: mood, camera, quality, frame cap, and the renderer backend at the bottom

The gear beside that readout opens a white panel holding four groups. MOOD offers Auto, Day and Night. CAMERA offers Auto, Side and Follow. ECO QUALITY carries a slider, described as standard shadows with simplified glow and stable performance. Limit FPS offers 60, 30 and MAX.

The last group is the interesting one. Two radio buttons for WebGL2 and WebGPU, with WebGPU greyed out on the test machine. Making the renderer backend a user choice rather than an automatic decision in code is rare on the web, and it means this renderer was written twice.

There is no fixed brand colour, since each stage brings its own. The interface layer stays white outline over a semi-transparent ground, which reads over any of them.

Motion

Beat synchronisation is the craft to take away here, and the method is startlingly cheap.

The page loads six music tracks named chrome-vortex, out-of-office, rocket-burst, emerald-mechanism, hot-and-nebula-papapa and evil-genius-ks-remont-u-sani, each 1 to 1.5 MB. Alongside them sit six more files with the same names and a .beats extension, each only 1 to 3 KB.

Every track's beat grid has been computed offline and ships as a table of a couple of kilobytes. The runtime needs no spectrum analysis, no AnalyserNode and no energy peaks computed on the audio thread, only a table and a clock. The team says its characters skip traditional skeletons and are built from springy point masses that bob with the music, and the two halves together make the whole method. The beat table supplies the timing, the point masses supply the movement.

The idea transfers directly. Whenever the programme material is fixed before launch, which covers background music, cutscenes and title sequences, precomputing the analysis into a data file always beats analysing at runtime, moving the cost from a few milliseconds every frame to a few milliseconds once. Only material the user uploads themselves genuinely requires live analysis.

Physics is a 233 KB wasm file literally named physics.wasm, 529 KB decoded. The team credits Bullet, and the bundle contains the word bullet exactly once, with every other physics symbol living inside the wasm and invisible from the JavaScript side.

The 3D assets are organised just as plainly. The main file is everything5.glb at 1.53 MB, 3.32 MB decoded, and the name says what it is. The whole world in one file. The other three are env.glb at 271 KB, collectables.glb at 93 KB and collectable-2.glb at 60 KB. Under 2 MB of geometry holds up the entire track.

Lighting is image-based. The page pulls two sets of EXR cube maps, named m2_px through m2_nz and m3_px through m3_nz, six faces each, plus a 342 KB brdf_LUT_512.exr. That lookup table is standard equipment for computing specular reflection in physically based rendering, and its presence says the materials are PBR rather than painted into the textures.

The canvas is 1920 by 945, matching display size with no supersampling, but with 4× multisampling on. Red and cyan fringing along the edges of those icon cubes says a chromatic aberration pass runs after.

Measured on the track across 240 frames: 60 fps average, p95 frame cost 17ms, worst frame also 17ms, 0% janky frames.

Nothing accommodates a reduced-motion preference. There is no prefers-reduced-motion rule anywhere in the stylesheet. That is harder to solve in a game than on an ordinary site, since the animation is the content, but the 30 option under Limit FPS and the ECO QUALITY slider at least give anyone who goes looking a way to turn things down.

Nothing plays until a visitor asks for it. There is not one audio element on the page, everything goes through Howler, and Howler's measured volume is 0 until a visitor turns it up.

Engineering

Loading it cold comes to 24.9 MB across 378 files, which is not much for a game.

Broken down, music is the largest single block at 8.09 MB, followed by images: 4.26 MB of avif, 3.22 MB of jpg, 1.82 MB of png, 1.64 MB of webp and 417 KB of svg, 11.3 MB together. Then 3D models at 1.95 MB, script at 1.07 MB, wav effects at 1.02 MB, EXR environment maps at 847 KB and wasm at 234 KB.

There is a telling gap in that list. KTX2 appears 10 times in the bundle and not one .ktx2 file is ever requested, so the code supports compressed textures and this build does not use them. Moving part of that 11.3 MB of imagery to KTX2 would cut both video memory and load time again.

Start-up measures well: 209ms to first byte, 1,192ms to first contentful paint, 538ms to DOM content loaded, 761ms to load. What stands out most is that there are no long tasks at all. A project that has to decode wasm, decode four glTF files and build a physics world, with nothing on the main thread running past 50ms, is real engineering.

Third-party content is essentially nil. Of the 24.9 MB, 24.85 MB comes from awards.racing itself, with 75 KB from images.awards.racing and 5 KB from api.awards.racing. That api subdomain backs the leaderboard and the player count, which read 19 online and 4,692 racers in total. No analytics script, no pixel, no session recorder.

Now the claim that does not hold.

The team's FWA write-up says everything is built for speed. Objects pooled rather than allocated mid-run, the world streaming in and out around the car, and the whole scene rendering in a single draw call. The first two are plausible from the design. The last one does not survive measurement.

Hooking a counter onto every draw entry point on the WebGL context and sampling 900 consecutive frames on the track gives a minimum of 80 draw calls per frame, a first quartile of 88, a median of 90, a p95 of 150 and a maximum of 152.

The reasonable reading is that the sentence means the world itself. This machine supports the WEBGL_multi_draw extension, and the bundle contains BatchedMesh twice and InstancedMesh seven times. three.js's BatchedMesh uses exactly that extension to collapse hundreds of objects into one call, so the track geometry very likely is drawn once, with the remaining eighty-odd calls covering HUD, characters, effects, shadows and post. One draw call holds for the world geometry and does not hold for the scene.

There is something to take from this too. Draw calls per frame need only a few lines of hooking to measure, so any project claiming extreme batching is worth counting before believing.

Accessibility has real problems. Of 76 interactive controls on the page, 37 carry neither text nor an aria-label, exactly half. The only landmarks are header and footer, with no main and no nav. All 23 headings in the document come from the legal text and help copy in the footer, and the game itself has none.

Input support is better than accessibility. The Gamepad API is in use, eight touch-only controls sit on the page, the key prompts are drawn as real keycaps, and there are options to cap frame rate and lower quality. A game that could have been mouse and keyboard only actually supports two further routes in.

Scores and Team

Award Source Date Score
FWA of the Day The FWA 2026-09-09 84 POINTS, DAYS 2

Eighty-four is the highest FWA score in this library, and it took only 2 days. The FWA publishes no category breakdown, and the team's own statement puts everything on engineering: pooling, streaming, batched rendering, physics-driven effects, characters without skeletons. A winning write-up that talks implementation throughout and never mentions the idea says plainly where the team thinks it won.

Credit Who FWA wins
Ecofuture Dubai, United Arab Emirates 2

One credit, and its origin is genuinely unexpected. Ecofuture's FWA profile describes it as a waste-management software company registered in Dubai. It holds two FWAs, with a timeline showing 2023 and 2026.

A company selling waste-management software producing an 84-point browser racer is worth recording above any technical detail here.

Awwwards has no entry for this site.

Archive

Award date
2026-09-09
Awards
The FWA FOTD 2026-09-09
Site
https://awards.racing
Credits
Ecofuture
Design
interface
Build
realtime
The FWA
84 POINTS, DAYS 2. https://thefwa.com/cases/awards-racing
Stack
three.js, WebGL2 (WebGPU selectable), BatchedMesh with WEBGL_multi_draw, custom physics.wasm, Draco, EXR cube maps with a BRDF lookup table, Howler, Gamepad API
Total assets
24.9 MB cold across 378 files, of which music 8.09 MB, images 11.3 MB, 3D 1.95 MB, script 1.07 MB, wasm 234 KB, beat tables 13 KB
Speed
209ms to first byte, 1,192ms first paint, 761ms to load, zero long tasks. 60 fps on track, p95 17ms, 0% janky frames
Test conditions
1920×945, dpr 1, zoom 100%, cold profile. Canvas 1920×945 with 4× multisampling. Median 90 draw calls per frame while racing