Ryan Albrecht digs into how efficient browser caching is on Facebook.com. They release code twice a day, breaking cache as they do, so they were curious if that was too often for browser cache to be efficient.
After collecting data, they are seeing 44.6% users getting an empty cache, which they determine effective:
The best practices tell us to use external styles and scripts, include Cache-Control and ETag headers, compress data on the wire, use URLs to expire cached resources, and separate frequently updated resources from long-lived ones. All of these techniques work together on any website, not just one at Facebook scale.
I'm not sure at what level they would be determined not useful though. Seems browser caching is an easy enough thing to implement that if 90% of users got an empty cache it would still be worth it, if just for the speed of that session alone.
Pinterest is kind of a big deal. In the blog and e-commerce world, it's threatening to edge out Google as the most important search engine. That's the world I come from, so I've had lots of opportunity to work with Pinterest's data attributes and meta tags. These bits of markup give site owners control over how their images and site are presented on Pinterest, and what can and can't be “pinned”.
Before we get into the tag and attribute details, …
This has become quite the hot topic lately. It's been talked about at a number of conferences and meetups I've been at personally lately. I've seen slide decks on it. I know people literally not shipping any CSS in production. Pretty wild, eh?
I thought we could have a little campfire here and talk about it as rationally as we can, covering all the relevant points. …
What should you do if you need a smaller button style whenever those buttons are placed in the header? Do you make a new class or a new custom button modifier? Harry Roberts tackles this problem in the following post on modifying components when they're inside another component:
If you need to change the cosmetics of a UI component based on where it is placed, your design system is failing. It’s as simple as that. Things should be designed to be ignorant; things should be designed so that we always just have ‘this component’ and not ‘this component when inside…’.
The problem here isn’t ‘How do we style this?’, it’s ‘Why has this been designed like this in the first place?’. Put another way, the problem here doesn’t exist in code, it exists in design.
The design issue here is solved by subtly inverting the problem: instead of saying "The buttons need to be smaller when they're in the header", we need to be saying "We have a smaller variant of our buttons, and it’s these that we use in the header."
In other words, a design system where the parts are purposefully ignorant of each other.
There is no min-font-size or max-font-size, so while setting font-size in viewport units is cool, there's a good chance your font-size might get too small on small screens or too big on large screens.
Eduardo Boucas has a clever workaround though. Use media queries to force the font-size back into a set pixel value when the viewport has gotten to the breakpoints at which those min/max values would be exceeded. He's got a Sass mixin to help with the math, but the compiled CSS is ultimately pretty simple.
I published a written post about this idea of the Server Side Mustard Cut. So if you're into reading and checking out code samples and stuff, that's the place for you. In this video I just walk through all that, explaining myself as we go.
I'll give the same caveat I have everywhere else I've introduced this: this may not be perfect for every site out there. In fact I think normal RWD stuff is generally better, up to …