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.
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.
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.
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.
> 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.
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.
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…
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
>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.
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.
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.
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.
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
They said halftone, so I imagine every pixel became a circle.
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.
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.
> 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.
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.
I wonder how much you could have compressed that SVG if you stored the broad strokes and added the perturbations with javascript, after loading.
Client side JS will always be slower than letting the browser render the PNG.
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…
Unless Figma is embedding a raster image of the text in the SVG, how is that possible?
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.
> 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
> 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.)
> Bootcamps tend to not focus on image formats
Can you tell me which university class you took that did?
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.
I did a course on them at university. I can't remember what it was called.
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.
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.
> Devs often argue that the format is "sharper".
You can also use lossless WebP in place of PNG these days.
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.
And what were the results?
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.
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.
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.
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.
Same here. It's not so hard, if your image isn't flat colours and has any "noise" use jpg.
I learned.. how to type.
Oh, this is a great idea. I love it.
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.
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.
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
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.
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.
> 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.
> 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
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.
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.
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.
The website does not fall under the budget cap, there is plenty of money to go around which cannot be used for racing anyway.
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.
Didn't know about this, what a totally cool result of a normally mundane action (re-allocation of business resources)
>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.
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.
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.
The newer cars are definitely bigger and less nimble. 2026 regs help a little bit with that but not quite enough.
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.
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.
There should be a DRS button on the website too!
Sure, but you can only use it if you arrive at the website within a second from the visitor before you.
Visualization of current state: https://lightest.app/c/Rm995qYNIL
P.S. hope not messed up with links
Missing Mercedes and Alpine, odd that the original post didnt have it either
https://www.mercedesamgf1.com/
https://www.alpinef1.com/
https://lightest.app/c/SM4HFPEXpx
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
>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.
Watching the Belgium Sprint Qualifying right now and found this post here.
Now I need to see the 2025 version!
Given this is 4 years old; did any sites take on the feedback?
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.
We really didnt care at all about the load-time for this marketing gimmick made by some one-time contractor. We built fast cars instead.
I was bored so I created a quick site for the current F1 teams
https://ericlugo.com/f1-2025/
Very cool but is it possible that there are not links to the actual websites?
If you expand the teams at the bottom, there is a link to each page