Nick Sherman gave a fascinating talk at Ampersand earlier this month which was based on an article he wrote called Variable Fonts for Responsive Design. In both the talk and the essay he suggests that we need a new font format to solve complex responsive design problems:
…the glyph shapes in modern fonts are restricted to a single, static configuration. Any variation in weight, width, stroke contrast, etc.—no matter how subtle—requires separate font files. This concept may not seem so bad in the realm of print design, where layouts are also static. On the web, though, this limitation is what I refer to as the “glass floor” of responsive typography: while higher-level typographic variables like margins, line spacing, and font size can adjust dynamically to each reader’s viewing environment, that flexibility disappears for lower-level variables that are defined within the font. Each glyph is like an ice cube floating in a sea of otherwise fluid design.
The web is a fluid place. Different sized screens, yadda yadda yadda. Fortunately for us, the web is ready for it. Text wraps. CSS gives us control over how to size things. What we don't get (easily, anyway) is a way to scale whole element (and it's children) proportionally—retaining its exact layout as it changes size.
We can do it though.
WPO, as in, "Web Performance Optimizations", I believe.
Case studies and experiments demonstrating the impact of performance optimization on user experience and business metrics.
Real companies, real performance changes, real impact. Ya know, Little things like:
Staples reduced median homepage load time by 1 second and reduced load time for the 98th percentile by 6 seconds. As a result, they saw a 10% increase in their conversion rate.
Neat trick by Tobias Ahlin:
How do you animate the
box-shadowproperty in CSS without causing re-paints on every frame, and heavily impacting the performance of your page? Short answer: you don’t. Animating a change of
box-shadowwill hurt performance.
There’s an easy way of mimicking the same effect, however, with minimal re-paints, that should let your animations run at a solid 60 FPS: animate the opacity of a pseudo element.
Pretty bold step for WordPress. Totally new UI. Totally new technologies. No more PHP and MySQL, it's Node.js, React, Flux, Babel, Webpack... the fanciest of fancy modern tooling. Still completely open source.
On one hand it seems risky. How much of WordPress' success is based on the epic backwards compatibility and ability to run on nearly any server? Will this ever become the self-hosted WordPress.org variant? At the moment, they are saying "Install JetPack and you can manage your self-install from WordPress.com" - but that doesn't feel like an answer. If we can never self-install, maybe the backwards compatibility doesn't matter? Can you keep developers interested in working on "the old thing" when the new shiny open source thing that powers the core business is right there?
On the other hand it seems to stifle risk. If you stay stuck in old tech, how long can you retain talent? How long until using it feels awkwardly antiquated?
This chart really drives home the before/after benefits.
The following is a guest post by Eduardo Bouças. Eduardo is back to follow up on his journey of approaching media queries programatically. He'll catch you up on how this started, where it's went, and how that's going.
A classic blog-and-forth, my favorite form of internet discussion.
Most critics miss the key [value to using a framework]: frameworks let you manage the complexity of your application as it and the team building it grows over time. All of the other stuff is just gravy.
... my hypothesis is that, for apps of any complexity, the ones that start off “vanilla” will accrete their own Frankenframework that performs similarly to, if not worse than, an off-the-shelf framework
... the interesting discussion to be had from Tom’s post is: Are we trying to make lightweight sites that WORK FAST or maintainable sites WORK FOR YEARS?
My take: yes, maximum performance and maximum developer comfort are a bit at odds. It's a dance as old as time. The river runs slower when you dam it, but hey you get some electricity. OK enough metaphors.
More baby bear porridge from Zach Leatherman, and a hopefull call for benchmark-pushing competeition:
If you decide to spend valuable kilobytes on a framework, fortunately there are plenty of frameworks to choose from. Just like DOM libraries used to compete on selector engine performance, the onus is on framework authors to compete against each other on initial render performance.
Another thing I'd add: this uncached time-to-glass stuff is a good metric; perhaps the most important metric. But measuring performance after that is pretty important too. Who is winning the "clickin' around and doing stuff" performance race?
On the design of CSS-Tricks as I record this, one of the things I wanted to add was a "Front End Design & Development Jobs" widget, powered by the CodePen Job Board. Those jobs are available as JSON data.