[HN Gopher] Who has the fastest F1 website (2021)
___________________________________________________________________
Who has the fastest F1 website (2021)
Author : tosh
Score : 172 points
Date : 2025-07-25 13:30 UTC (9 hours ago)
(HTM) web link (jakearchibald.com)
(TXT) w3m dump (jakearchibald.com)
| cjbarber wrote:
| This reminds me of a principle I like: Once you understand your
| key traits and the key things customers come to you for, it's
| good to embody them everywhere!
|
| F1 is largely about speed. (I fondly remember going to various
| races as a child with my grandparents, in Melbourne. Everyone
| seemed in awe of Schumacher). So of course your website should be
| about speed!
|
| This could then apply to everything: ticket turnstiles that
| measure themselves on time per guest scanned, food vendors that
| do the same thing, websites that measure and rank on speed.
| atonse wrote:
| I actually strongly agree with this philosophy because it's
| about fostering a certain culture.
|
| But as a counterpoint for the sake of argument, money and time
| spent on optimizing the website could be better spent on the
| actual race related stuff. So that might be where the
| optimization is happening.
|
| In reality, it's probably the simpler explanation, that they
| know how to hire mechanical engineering talent and just see IT
| as a cost center (and a nuisance) so probably are cheap in that
| department.
| consp wrote:
| The website does not fall under the budget cap, there is
| plenty of money to go around which cannot be used for racing
| anyway.
| gpderetta wrote:
| Indeed! Ferrari literally started racing again in Le Mans
| Series because they didn't want to have engineers sitting
| around or fire them due to the F1 budget cap. Instead they
| redirected (very successfully) their additional resources
| elsewhere.
| FirmwareBurner wrote:
| _> F1 is largely about speed._
|
| Not since a long time. It's about creating endless regulations
| to please big teams, sponsors and advertisers. 2026 cars will
| be even slower than before.
| dralley wrote:
| Faster doesn't necessarily mean better racing. And F1 has
| been heavily regulated forever.
|
| Turbos were banned in the 80s because they made the cars too
| powerful and difficult to handle. The reason F1 tires had big
| grooves cut into them for a long time was to reduce grip,
| also in an effort to tame the cars a bit and slow them down
| while cornering.
|
| The 2026 regulations are no different. Yes peak power is
| reduced but so is downforce / drag. Drivers will have to
| brake a bit more at the turns and accelerate out of them
| (which the extra electrical power will make easier). That
| means more overtaking possibilities, and the overtaking will
| likely be more based on driving skill than the current DRS
| push-to-pass. The current ground effect cars have so much
| downforce that they can go through corners flat out that no
| previous generation of cars would have been able to - and
| while that's cool to watch it's not that interesting from a
| racing perspective. You don't want to watch a high-speed
| parade.
|
| For years everyone was catastrophizing about how the 2026
| regs would make the cars 8 seconds slower, but the current
| consensus is around 1 second. That's not a big deal. And it
| only takes things back to say 2007 speeds, nobody ever
| accused 2007 of not being exciting.
| stockresearcher wrote:
| 6 or 7 years ago, F1 did a tour of large-ish cities around
| the world that did not have races nearby. They had booths
| set up where some teams showed off various technologies and
| materials and you could ask questions. They had some
| various cars on display. The highlight was a demo session
| where they had a collection of F1 cars of various vintages
| as well as some exotics driving around a makeshift circuit
| that had been setup on streets next to the venue. The one
| that I had taken my son to, the circuit included a 180
| degree turn. None of the most modern F1 cars could navigate
| it! (well actually, the drivers eventually learned that by
| doing donuts, they could in fact complete the turn).
|
| It was highly entertaining because it did not go well at
| all, and I'm pretty sure that F1 didn't actually finish the
| full scheduled tour. But it really showed a big difference
| between old cars and new.
| dralley wrote:
| The newer cars are definitely bigger and less nimble.
| 2026 regs help a little bit with that but not quite
| enough.
| nullify88 wrote:
| Or it maybe due to the cars and their designs being
| throughly tuned for the tracks they are racing on. More
| so when compared to previous generations of F1 cars.
| dralley wrote:
| I mean the cars are literally bigger and heavier. Even
| compared to 2014 / 2017. They're incredibly fast but
| can't be thrown around like the smaller and lighter cars
| from previous eras.
| cybrjoe wrote:
| This seems reductionist. There's plenty of other reasons people
| are F1 fans: the spectacle, the wealth, the prestige. While
| speed is certainly a draw for a lot of fans, speed can be at
| odds with the some of these other traits. For instance I took
| my son to qualifying in Miami, and while we both thoroughly
| enjoyed it, qualifying is quite short, and not nearly as
| exciting as watching it on TV. My son's first comment was: they
| don't seem as fast in person.
|
| We ended up kicking around the track for a few hours taking in
| all the sights and experiences and he enjoyed that a lot more.
|
| I guess my comment is, speed is important, sure, but don't give
| me a plaintext website either. There's a balance between speed
| and entertainment value.
| epolanski wrote:
| > My son's first comment was: they don't seem as fast in
| person.
|
| Depends when you're sitting, but you mostly appreciate it at
| good corners.
|
| There, you can really feel why F1 is fast.
|
| https://www.youtube.com/watch?v=I1ckq7T1Tlg
| cjbarber wrote:
| Yes! There'll be different key traits for different
| customers. Like you say for F1, might be speed for some,
| prestige for others. So perhaps you might need to focus most
| of your things on both, or some things on prestige and some
| on speed. Generally there'll be a relatively small set of
| truly key traits.
| _thisdot wrote:
| I thought F1 was supposed to look a lot faster in person. The
| cars going at 300kmph don't look so fast on a screen because
| the camera stabilisation. Someone who makes drones on YouTube
| collaborated with RedBull to shoot Max Verstappen with a
| drone at those speeds. And Max was impressed by the
| perception of speed from the drone footage compared to
| regular TV broadcast
|
| Link to YouTube video:
| https://www.youtube.com/watch?v=9pEqyr_uT-k
| dylan604 wrote:
| Okay, that was a cool video. It's always cool to see how
| things go wrong and how the challenge was overcome. That
| has to be a really cool and fun job.
| prmoustache wrote:
| your eyes/brain stabilize better than any camera/software.
|
| Having attended f1, rally and euro hillclimb races in
| person, I also thought the F1 in the v8/v10/v12 era indeed
| looked slower than on TV. I think the reason is they were
| so scandalously loud that you would expect something
| visually faster from something that is ripping your ears
| off even with plugs.
| dylan604 wrote:
| > My son's first comment was: they don't seem as fast in
| person.
|
| That was the exact opposite of my experience with autoracing.
| Watching on TV with the long tracking/panning shots seem to
| reduce the effectiveness of the speed. Standing at the track
| watching the cars fly by and are only there for a split
| second really brings home how fast they are. "zoom zoom" is
| about as close as one can get to describing it. There's also
| just no way to replicate how loud the cars are either. I've
| seen Fox try where they have moments where the commentators
| shut the hell up for a minute, they push the mix from the
| mics around the track, display Vu like meters on screen with
| some sort of Dolby/surround type of something suggesting it
| sounds great in that mode. Don't care. Nothing like being
| there.
| rconti wrote:
| I'd expect a long lens shooting down a series of S-curves
| (think: Austin) would exaggerate how fast the cars look, but
| everything else would seem faster in person. My first F1 race
| was, indeed, in Austin, and the cars seemed mind-bendingly
| fast. Even just the sound sent a shiver up my spine as I
| walked up to the track from a half mile away. But that was in
| the V10 era; now they're very quiet.
|
| On the other hand, my last F1 race was at Silverstone, and we
| were at Vale grandstand which is right at pit entry and the
| final chicane before the front straight. Sitting in a braking
| zone definitely makes the cars look slow.
| poemxo wrote:
| There should be a DRS button on the website too!
| GaggiX wrote:
| >Squoosh lets you disable subsampling for JPEG and AVIF, but it
| can't be disabled for WebP, as the format doesn't support it. To
| work around this, the WebP encoder has a "sharp RGB to YUV"
| option which tries to limit the impact of subsampling at the cost
| of some colour bleeding. I used that option above.
|
| This is something that I truly hate about WebP, thankfully AVIF
| exists and it's supported by all major browsers.
| hhmc wrote:
| Given this is 4 years old; did any sites take on the feedback?
| ethan_smith wrote:
| F1's official site has improved significantly since 2021, now
| scoring 75+ on mobile PageSpeed Insights vs ~45 back then.
| They've reduced initial payload by ~40% and implemented better
| image optimization techniques, though they still lag behind
| some team sites like McLaren's.
| defly wrote:
| Visualization of current state: https://lightest.app/c/Rm995qYNIL
|
| P.S. hope not messed up with links
| snug wrote:
| Missing Mercedes and Alpine, odd that the original post didnt
| have it either
|
| https://www.mercedesamgf1.com/
|
| https://www.alpinef1.com/
| defly wrote:
| https://lightest.app/c/SM4HFPEXpx
| firefoxd wrote:
| Recently I made a small game at work called JPEG or PNG, for the
| front end team. Bootcamps tend to not focus on image formats at
| all, the results is all Figma images gets exported as PNGs and
| bloat the website. Devs often argue that the format is "sharper".
|
| Anyway, my game consisted of a slide of images and we vote what's
| the most appropriate format. When when people got a hang of it, I
| threw in WebP and SVG. I talk about those last, because they can
| easily abused: i.e an SVG with an embedded png.
| import_gravity wrote:
| Oh, this is a great idea. I love it.
| perching_aix wrote:
| And what were the results?
| firefoxd wrote:
| Bad at first until the pattern emerged. Solid colors, sharp
| lines, is PNG. Photo, 3d, landscape, is JPEG. I'm still
| trying to hammer it down for juniors who default to JPEG now.
| sunaookami wrote:
| Huh, don't you learn these at school? I learned this in
| 5-6th grade in my country. Even learned basic HTML and how
| to create websites with tables... which was when floats
| were all the rage.
| bardak wrote:
| Same here. It's not so hard, if your image isn't flat
| colours and has any "noise" use jpg.
| the_plus_one wrote:
| As an American that grew up in a rural area, this
| definitely isn't something that would've been taught in a
| public school here. At best, we had typing classes in
| middle school, and the (quite old) teacher insisted on
| two spaces after the end of a sentence, something that
| disappeared after we stopped using typewriters.
| dhosek wrote:
| More to the point, the two spaces after the end of a
| sentence is a consequence of the typographic style at the
| time that the typewriter was introduced where additional
| space at the end of a sentence was employed (this is most
| common in books typeset in the 18th and 19th centuries,
| although earlier and later examples exist). Despite what
| people will tell you, it has _nothing_ to do with
| legibility for monospace printing, and an awful lot with
| 19th century compositors getting paid by the line and
| padding their paychecks by increasing spacing wherever
| possible. William Morris and his followers, direct and
| indirect, led to a contraction of word spacing and the
| elimination of the additional space at the end of
| sentences in emulation of the best printing examples of
| the 15th and 16th centuries.
| rconti wrote:
| I learned.. how to type.
| Swizec wrote:
| My favorite real world example of this was adding a bunch of
| 2-tone graphics to a website that looked like hand-drawn
| sketches. The designer insisted they have to be SVG because
| vector graphics scale better.
|
| The SVG was 20MB. The PNG version at huge resolution was 20kB.
|
| PNG is _really_ good when you have a few flat colors. SVG is
| _really bad_ when you have lots of fine detail.
| kevindamm wrote:
| I wonder how much you could have compressed that SVG if you
| stored the broad strokes and added the perturbations with
| javascript, after loading.
| afavour wrote:
| Client side JS will always be slower than letting the
| browser render the PNG.
| pxoe wrote:
| Have to wonder what those 20 MB SVGs were like and whether
| they could've been optimized as SVG still. Doesn't seem to
| add up that at "huge" resolution that PNG would be that small
| either.
| Swizec wrote:
| > Doesn't seem to add up that at "huge" resolution that PNG
| would be that small either.
|
| Well maybe not huge huge. Like 1000px wide so they look
| nice on retina screens.
|
| The key is that these images were just 2 contiguous color
| areas. Black and transparent. PNG is really good for that
| because the compression algorithm works on the basis of
| contiguous color areas.
| pxoe wrote:
| Was there any attempt to optimize SVG? If it was just a
| single object/path, it'd be pretty small (if it was
| optimized/simplified for curves/node count, it could be
| even smaller), and then it could be harder matching that
| size with PNG or it wouldn't be that much of a
| difference.
| jvanderbot wrote:
| PNG keeps a count of sequentially-same color pixels (not
| really but roughly speaking) instead of keeping pixels
| themselves. So scaling a monocrome png image means just
| changing the count entry (very roughly speaking), so it'll
| be nearly zero cost.
|
| What I mean is, if you have a million pixels of the same
| color (0xDEADBEEF maybe), then PNG will call that 1,000,000
| x OxDEADBEEF. So, it scales very nicely for few-color,
| sparse or "blocky" images.
| klysm wrote:
| Fine detail isn't really the metric to use when thinking of
| SVG size. 20MB just sounds like a catastrophic degenerate
| export from shitty software
| illwrks wrote:
| I've worked with various graphic formats for web... for over
| 20 years at this stage.
|
| It's incompetence to blame rather than file-size, maybe
| designers or someone in the briefing process that is
| uninformed that confuses the requirements for everyone else.
|
| Also... I don't trust Figmas quality with exported SVG. Just
| type some text, export it and see how it degrades...
| RandallBrown wrote:
| Unless Figma is embedding a raster image of the text in the
| SVG, how is that possible?
| illwrks wrote:
| When I was looking at it a few months ago, vector
| lettering (an outlined name in a logo) when exported the
| curves were goofy. I brought them into Illustrator and
| overlaid it on the actual logo and there was a clear
| difference.
|
| Couldn't find the source of the issue so could only
| assume the SVG data was being compressed on export.
|
| We decided to only use it to share graphic across the
| team, in any instance we were working with type we used
| illustrator.
| breve wrote:
| > _Devs often argue that the format is "sharper"._
|
| You can also use lossless WebP in place of PNG these days.
| Theodores wrote:
| You can get your code to list PNG or JPG and then get your
| server to serve webp. Browsers don't care about file
| extensions, they read the image headers.
|
| To implement this you can get nginx to generate the webp from
| the JPG or PNG. Then you get that cached by your CDN.
|
| If you need to change your compression levels then you can
| delete the cache on the CDN.
|
| You can use the varies header to see if webp is accepted. If
| not, serve the original. In this way people can save the
| hires JPG with a right click.
|
| You can also amp up the compression just for when the data
| saving flag is set.
|
| The best thing is that you can do all this with hardly any
| lines of code and the VIPS library to optimise it.
| paulddraper wrote:
| > Devs often argue that the format is "sharper".
|
| And they're correct.
|
| PNGs use lossless compression.
|
| JPEGs use lossy compression. (JPEG XL allows for lossless.)
| kllrnohj wrote:
| > results is all Figma images gets exported as PNGs and bloat
| the website
|
| It's not just size but also decompression time. JPEG is _way_
| faster to decode which is also on the critical path towards
| time-to-display
| the_sleaze_ wrote:
| > Bootcamps tend to not focus on image formats
|
| Can you tell me which university class you took that did?
| robertlagrant wrote:
| I did a course on them at university. I can't remember what
| it was called.
| fragmede wrote:
| https://web.stanford.edu/class/cs148/ would be a class that
| covers raster vs vector graphics, which should be covered in
| every computer science degree.
| ksec wrote:
| Which got me thinking, may be there should be a tool that shows
| results of compression and allow devs to choose which one to
| use?
|
| JPEG, PNG, WebP, JPEG XL and SVG. Even though I am pretty sure
| JPEG XL will win 95% of times.
| ericmcer wrote:
| The huge SVGs are probably a side effect of Figmas export to
| svg and people not knowing what to look for. I have seen some
| crazy inefficient exports from that.
| goshx wrote:
| Watching the Belgium Sprint Qualifying right now and found this
| post here.
|
| Now I need to see the 2025 version!
| zaking17 wrote:
| This reminds me of one of my favorite books from a few decades
| ago: Websites that Suck http://www.webpagesthatsuck.com/ That
| might have been what turned me on to web design, and I'm still
| trying to make things that don't suck
| snug wrote:
| I was bored so I created a quick site for the current F1 teams
|
| https://ericlugo.com/f1-2025/
___________________________________________________________________
(page generated 2025-07-25 23:01 UTC)