> When I keep them in their native P3 color space, each image is between 50kb and 150kb. With 22 individual images, I’d be sending almost two megabytes of assets, which feels like way too much for decorative images like this!
Love to hear the consideration for folks. I feel like I download twice that in javascript blobs from like 12 analytics companies and ad videos every time I visit e.g. CNN or TechCrunch
If only more people were considerate about the amount of bandwidth their websites serve. I just had a conversation where our system generates a CSV and I feel that we should be zipping the file, but I was overridden with a "people today can download large files easily today" and the "not having to unzip is worth it" reasons.
I think a lot of web servers will automatically gzip data if the client accepts it.
You might not even have to do anything config wise if this is for a website and normal web browsers.
If it’s for an app, it might depend on what client library you use but even then I guess a lot of them will automatically support that for you without any special configuration required.
I just took a look at my httpd.conf, and the deflate module is being loaded, but there was no directive on what file types to apply it to that I could find. I'll have to set up a couple of tests to see the before/after of enabling it for a specific file type
I'll have to leave myself a comment in the conf file to remind me that I got a little tech support on a divergent bit of comments on a post about interesting CSS anims =)
Also, instead of compressing files live on every request, you can pre-compress them, put them next to the uncompressed files with the same name but .gz extension, and tell your server to serve those if the client support it [0].
Useful in case of bigger files (so you don't have to compress them on request), and also if you want to use a higher compression level: you're only going to compress them once, not on every request, so you can use a bit more CPU on making them a bit smaller.
Unfortunately, the specific thing I was looking to compress are reports generated live, and are then removed with a TTL type policy.
I would however definitely be interested in having the site's .js files delivered as .gz files. This has been something I have always been curious about and had as a TODO item, but I think this discussion will move it up on my priority list. Luckily, we are a very small site with a laughably small set of users. But nothing wrong with using best practices even so
Working on mobile it gets even crazier because everything* is shipped to everyone.
"Oh we just need to include this lib for that one tiny thing, who cares."
Turns into
"we're using 7TB of mobile storage around the world for this one tiny feature"
or
"Our app is responsible for ~472TB of mobile storage being used."
(actual numbers I just calculated btw)
*: Some stuff is optimized out, not everything but essentially anything needed to run any part of the app on a users device is included, even if they just need to do one specific thing and nothing else.
By on mobile do you mean working as a native app bloating the app size?
The "just for one thing" also seems to be a common complaint about NPM as well. I'm sure any package/library managed ecosystem suffers this problem, but it really seems the Node gets tagged with it much more frequently.
> It appears that you’ve ticked the “Reduce motion” option in your system settings. As a result, certain whimsical features on this page have been disabled.
I think this is a Windows setting I enabled to get rid of annoying window animations, didn't know it could affect web pages, and I'm not sure I want it to :D
Well it's nice actually, but in this specific case I think I'd like to override it.
Josh’s first course, CSS for JS Devs was how I finally “learned” CSS after 15 years of working with it.
It’s not just for JS devs of course, I started with C and PHP nearly 20 years ago now, and I highly recommend it to anyone looking to understand things like “why isn’t the z-index doing anything?!?!” and the like.
Idk if there's just something wrong with me, but I feel like every time someone says "look how much better P3 looks" I just think it looks over-saturated and the more muted look of the srgb just looks so much better to me.
It appears that you’ve ticked the “Reduce motion” option in your system settings. As a result, certain whimsical features on this page have been disabled.”
Each time something from Josh gets posted here, I find my self realizing how little I know about CSS yet feel like I have a much firmer grasp than most. This individual's dedication to continue pushing things within CSS is something that I am in awe of and much appreciation. I just wish I had such a site where some of his more interesting ideas would be a fit.
He strikes me as someone with a creative tech nerd version of "hold my beer" mentality with much less dire consequences
What stands out the most to me on that landing page is that scrolling craters the framerate on my high end phone even though there doesn't seem to be any animations tied to scrolling. Maybe a Chromium browser would handle it better than Firefox, but ugh.
In my OneOplus Nord 2 5G, that's a kinda mid range of that same era, works fine. Firefox 135, Android 13 (with all the stuff that OnePlus puts over it)
> When I keep them in their native P3 color space, each image is between 50kb and 150kb. With 22 individual images, I’d be sending almost two megabytes of assets, which feels like way too much for decorative images like this!
Love to hear the consideration for folks. I feel like I download twice that in javascript blobs from like 12 analytics companies and ad videos every time I visit e.g. CNN or TechCrunch
If only more people were considerate about the amount of bandwidth their websites serve. I just had a conversation where our system generates a CSV and I feel that we should be zipping the file, but I was overridden with a "people today can download large files easily today" and the "not having to unzip is worth it" reasons.
What about zipping only on the transport? Http supports compression. You save on bandwidth and users don't have to manually unzip it.
This is why I don't call myself full stack even if tasked with those.
Thank you. I will look into this
I think a lot of web servers will automatically gzip data if the client accepts it.
You might not even have to do anything config wise if this is for a website and normal web browsers.
If it’s for an app, it might depend on what client library you use but even then I guess a lot of them will automatically support that for you without any special configuration required.
I just took a look at my httpd.conf, and the deflate module is being loaded, but there was no directive on what file types to apply it to that I could find. I'll have to set up a couple of tests to see the before/after of enabling it for a specific file type
I'll have to leave myself a comment in the conf file to remind me that I got a little tech support on a divergent bit of comments on a post about interesting CSS anims =)
Also, instead of compressing files live on every request, you can pre-compress them, put them next to the uncompressed files with the same name but .gz extension, and tell your server to serve those if the client support it [0].
Useful in case of bigger files (so you don't have to compress them on request), and also if you want to use a higher compression level: you're only going to compress them once, not on every request, so you can use a bit more CPU on making them a bit smaller.
--
(I guess you're using Apache, but other servers can do it too)Unfortunately, the specific thing I was looking to compress are reports generated live, and are then removed with a TTL type policy.
I would however definitely be interested in having the site's .js files delivered as .gz files. This has been something I have always been curious about and had as a TODO item, but I think this discussion will move it up on my priority list. Luckily, we are a very small site with a laughably small set of users. But nothing wrong with using best practices even so
I appreciate everyone's suggestions
Working on mobile it gets even crazier because everything* is shipped to everyone.
"Oh we just need to include this lib for that one tiny thing, who cares."
Turns into
"we're using 7TB of mobile storage around the world for this one tiny feature"
or
"Our app is responsible for ~472TB of mobile storage being used."
(actual numbers I just calculated btw)
*: Some stuff is optimized out, not everything but essentially anything needed to run any part of the app on a users device is included, even if they just need to do one specific thing and nothing else.
By on mobile do you mean working as a native app bloating the app size?
The "just for one thing" also seems to be a common complaint about NPM as well. I'm sure any package/library managed ecosystem suffers this problem, but it really seems the Node gets tagged with it much more frequently.
> It appears that you’ve ticked the “Reduce motion” option in your system settings. As a result, certain whimsical features on this page have been disabled.
I think this is a Windows setting I enabled to get rid of annoying window animations, didn't know it could affect web pages, and I'm not sure I want it to :D
Well it's nice actually, but in this specific case I think I'd like to override it.
Josh’s first course, CSS for JS Devs was how I finally “learned” CSS after 15 years of working with it.
It’s not just for JS devs of course, I started with C and PHP nearly 20 years ago now, and I highly recommend it to anyone looking to understand things like “why isn’t the z-index doing anything?!?!” and the like.
Idk if there's just something wrong with me, but I feel like every time someone says "look how much better P3 looks" I just think it looks over-saturated and the more muted look of the srgb just looks so much better to me.
“ Reduced motion detected
It appears that you’ve ticked the “Reduce motion” option in your system settings. As a result, certain whimsical features on this page have been disabled.”
Thank you.
Wasn't expecting to see Irish there, thank you! Beautiful page also!
Each time something from Josh gets posted here, I find my self realizing how little I know about CSS yet feel like I have a much firmer grasp than most. This individual's dedication to continue pushing things within CSS is something that I am in awe of and much appreciation. I just wish I had such a site where some of his more interesting ideas would be a fit.
He strikes me as someone with a creative tech nerd version of "hold my beer" mentality with much less dire consequences
What stands out the most to me on that landing page is that scrolling craters the framerate on my high end phone even though there doesn't seem to be any animations tied to scrolling. Maybe a Chromium browser would handle it better than Firefox, but ugh.
Works fine on iPhone 13 mini with iOS Safari. It's your browser.
Safari on an iPhone 13 Pro handles this page without issue. That’s a three generation old high end phone.
In my OneOplus Nord 2 5G, that's a kinda mid range of that same era, works fine. Firefox 135, Android 13 (with all the stuff that OnePlus puts over it)
> The experience is very limited on mobile. If at all possible, I’d strongly encourage you to visit on desktop.
I took that to mean "the interactivity is more geared towards mouse input than touch", not "scrolling the page demands a desktop GPU for some reason".
[dead]