What's changed and where's it going

A Talk By Dave Rupert @davatron5000

Responsive Web Design 102: A refresher course

This talk is a refresher course on Responsive Design. I feel like we’re at a point where RWD is nearly 10 years into Responsive Design and it’s a good time to reflect on all we’ve learned and also evaluate how it’s all going. A lot of my work in the last year or so has been rehabbing existing sites and I’ve learned a few things I’d like to share here today.

2010

Let’s start by teleporting back to 2010… where it all started.

Responsive Web Design

In 2010 Ethan Marcotte wrote a blog post that became a book called Responsive Web Design. During this time a lot of us were duplicating our effort by creating both a desktop site and an m-dot site that worked on these new-fangled iPhones.

In his blog post Ethan propsoed a new technique where you can use a combination of three things to create a site that works on both desktops and phones:

  1. Flexible Grid
  2. Fluid Media
  3. Media Queries

I was mad at Ethan for this. It was pretty disruptive to our pixel perfect workflows that we had essentially mastered. But the more we played with it, the more we realized the potential.

RWD is a Technique

But in 2010/2011, RWD is still very much a web design technique.

But it didn't stop there...

Slowly but surely, more and more concerns were piled on and the breadth of things you needed to understand to make a Responsive Website grew and grew.

  • Mobile First
  • Sass
  • Web Typography
  • Responsible Responsive Design
  • Touch
  • Patterns & Principles
  • Making Money with RWD
  • And going responsive at an organization level…

Karen rightly pointed out that RWD is starting to impact our businesses. Through her and Ethan’s

RWD is a Philosophy

It’s at this point, RWD pivots from a technique, to a philosophy.

But it didn't stop there...

In order to make a website, we now have to have some proficiency in…

  • Git
  • SVG, a new image format based on Math
  • JavaScript, o lord, JavaScript
  • The Command Line
  • Animation
  • How to put a webfont on the webpage
  • We need to be reminded about Accessibility
  • CSS Grid, the most important advancement in CSS since CSS itself!
  • Websites can work offline now
  • We can use webfonts, but we need to understand how to set type
  • Image performance, a whole book on how to put an image on a webpage
  • Progressive Web Apps, websites now interact with the operating system
  • And of course the “non-canon” books about Design Systems… who knows if these will take off.

Looking at the Data

If we look at some data we can see this explosion of concerns…

2014

Let’s go back to 2014 and I picked 2014 for two reasons…

  1. It’s 5 years ago, a mid-point in the last decade of responsive design
  2. I feel like this is 2012-2014 era is when a lot of sites started adopting Responsive Design and we were building momentum towards Google Search’s 2016 recommendation for RWD.

A lot of the website I’m being called in to help on are from this era and perhaps you have one too.

Total Kilobytes

According to HTTP Archive, the average Mobile site has more than tripled in size since in the last 5 years from ~560kb to ~1.7MB. Don’t look at the Desktop stats, we’re only looking at mobile because that’s the only thing that matters.

JavaScript! JavaScript! The problem is JavaScript… well…

JavaScript Bytes

Not necessarily… but it’s still quite a lot.

JavaScript we’re sending to Mobile has more than doubled over the last 5 years. We’re now sending ~360kb of JS. And it’s important to note, this is just the transfer size, the actual JavaScript size is considerably more than this.

What about CSS?

CSS Bytes

CSS has actually tripled in size over the last 3 years from 18kb to 56kb.

This is really curious to me because I don’t exactly think we have 3x the style problems compared to 5 years ago. If anything, with browser standardization we’ve removed the need for *most CSS prefixes.

I’d love to dig into this more. I wonder if CSS frameworks play into this or if we’ve all just got lazy.

Image Bytes

Now images make up the brunt of the website bloat. I have mixed feelings about this…

On one hand, we most certainly are sending down bloated images to the client. I’d bet you $100 I can unoptimized image on your homepage.

On the other hand, the Mobile landscape has changed. With 2x and 3x phones we have to send down larger imagery. And in the era of Instagram and Snapchat it’s really important that your brand maintains a level of visual fidelity.

So in someways, I want to externalize this blame say “not my fault” but also acknowledging there’s things I can control.

Quick Note on Kilobytes

  • Gzipped vs Unzipped
    • Gzipped: Reflects the speed at which resources will arrive
    • Unzipped: Reflects the amount of work on the CPU and maintenance costs
  • All bytes are not equal
    • JS bytes that must be downloaded, parsed, and executed and cause a style recalculation on the client are more expensive than CSS bytes
    • Image bytes are memory intensive and more expensive to resize on device.

But...

But Aren’t mobile Phones and mobile connection speeds getting faster? Won’t this problem go away?

Yes but No, Actually.

DOMContentLoaded

This chart is great because the dataset for DOMContentLoaded for Mobile and Desktop was actually joined together, but in ~2016 they started collecting different metrics for mobile and desktop. And you can see how mobile, even though devices and connection speeds are getting faster, this even where HTML says it’s ready has slowly creeped upwards.

onLoad

The chart of onLoad, the point where the browser has everything it thinks it needs for the page, fills in some of the details. We see the average mobile site has gotten ~6s slower, while the average desktop site has gotten ~1.5s faster.

Despite advancements in technology, mobile sites are getting slower. And this is due to all the HTML/CSS/JS/Fonts/etc that we’re sending to the device.

The DoubleClick Study

Why does this matter?

Accordion to DoubleClick’s study on the impact of mobile latency we know that 53% of users abandon a site if it takes more than 3s to load. 50% of people expect a page to load in 2s…

Charting that out

The average site takes 18.4s to load…

But the money zone is at 3s…

This is an incredible gap to close.

Looking at some Examples

I thought it’d be good to look at some examples. These are all sites I’ve worked on in the last year or and while I’ll talk mainly about one site in particular, the stories here are mostly the same and

Khoros

Khoros was a 6 month project, but 3 weeks into the project our client (spredfast.com at the time) announced a merger with (lithium.com). A couple weeks later we got a new creative director. A couple weeks later after the dust from the merger had settled we had a different CMO than the one that hired us. And a month after that it was decided there would be a NEW comapny established. But we still had an early March deadline. And the big catch was the branding (fonts, colors, logo, etc) for this new company wouldn’t be ready until early February. We had one month to build out and deliver a website coordinating with their in-house designers and content people. We all got a few grey hairs in the process, but using the power of a design system, we were able to meet the deadline.

Austin Chamber

We recently launched the Austin Chamber of Commerce’s new website. We worked with them on establishing a new look and feel for this organization that plays a big role in attracting business to Austin. In about 3 months we handed off a design system to a development team who integrated that in nearly 3 months and we had a website. They even started building pages using the components without even asking us, which honestly was the entire goal of delivering a design system.

PapaJohns

We helped a small pizza company from Kentucky update a few areas of their site. Addressing the elephant in the room, Papa Johns is a company that has undergone quite a few changes in the last couple years. Apparently Shaq is on the board now and visits the office!? One thing I’ve learned over the last couple years is that a lot of times the headlines in the news are very different than your experience and the diverse team of people you work with.

Papa Johns makes an interesting case study because this is a site that was handed off by Happy Cog (a talented agency and friends of my shop Paravel), but over the years the site - just like many sites I see - just grew and grew and grew.

How big you ask? Well…

1 MB 1 MB + CSS JS

They were sending down 1MB of CSS and 1MB of JS. Now this gzips down to around 256kb and 300kb. But. This is a lot of code.

How much code?

37,000+ Lines of CSS

Approximately 37,000 lines of CSS. This is a maintenance burden. Every time you write a line of CSS, you have 37,000 potential collisions. This is a lot and makes it difficult to work in and it appears that most people would just copy and paste whole sections and give it more specificity to work around this issue.

Managing CSS

So… let’s talk about managing CSS.

Step 1: Interface Inventory

This section of my talk is going to sound really familiar, it’s a classic design system story.

Buttons

We found ~32 different buttons on the site. The bulk of that was ~20 different green buttons with slightly different spacing, border-radii, sizes, and icons.

Product Cards

Digging in we found ~14 different product cards on the site which is somewhat unexpected for a company that more or less sells one product.

There’s more examples here of course, but hopefully we’re getting a sense of the explosion of variants that happened one small decision at a time over the life of the product.

Step 2: Measure

I find it really helpful at the start of a project to measure what you’re up against.

CSS Stats

CSS Stats is a great tool that can help give you a 10,000ft view of your CSS file. You can see the 1,012kb (I wasn’t lying 😉). 10k selectors, 16k declarations, 711 font sizes, 75 background colors, and 41 unique colors for a site that really only has 3 colors red, white, and green. And black for text.

Lighthouse

Lighthouse is built into Chrome/Edge/Opera/Brave so you have no excuse not to use it and run it on your site right now.

It gives you a rating on your Performance, your Accessibility, UX Best Practices, and SEO.

But I have some rules about how to use this tool. When you start it up you get asked to choose your Speed and we -in this room- choose Mobile with Applied 4G with 4X Slowdown. In this house we’re mobile first and don’t trust in vanity metrics.

These measurements are from a remote pre-production environment and won’t really reflect all the third-party scripts and CDN etc that might impact the site. Always know the limitations of your data.

Step 3: Patternize

The next step is doing the work.

Color

We reduced and improved the contrast of the colors to meet WCAG 2 AA recommendations and got the number down to ~16 colors and maybe 8 of those are greytones.

Buttons

32 buttons became about 12. The majority is this matrix of 9 colors: 3 colors × 3 sizes. Using color and size we can prescribe consistent meaning though the site.

Product Cards

We ended up with ~5 different product cards each with similar, cohesive style but different define usecases.

  • Product Card
  • Banner Card
  • Feature
  • Special Offer Card
  • Hero Offer Card

Step 4: Measure Change

Now that we’re finished, let’s measure the site and see how we’ve done…

28 Major Components 67 Total Variants 105 Pages Covered

Pages play a crucial role in how we build design systems. Pages

source-map-explorer

One other tool I use is source-map-explorer which takes your Sass and JavaScript sourcemaps and breaks them out into a treemap. This a good way to see files grouped together. On our “AFTER” side, the top half is our components and the bottom half are our utilities…

(Disclaimer: Animations is coming in verrrry large. There’s no way we have 28kb of animations. I think this is a problem with third party CSS getting lumped in)

I have some interesting data from this. Looking at my components, knowing I have 28 major components and 56kb of component CSS, I know that components average about 2kb of CSS. So if someone wants a new component, that’s going to add ~2kb of CSS to the total unzipped size. Variants? About 800 bytes each.

This is cool data to have and this visualization allows you to audit your CSS, combat the bloat, and you can identify large bits of CSS that you can potentially whittle down.

CSS Stats: Before and After

Let’s check CSS Stats for the before and after…

We reduced our CSS 91% to 100kb. This gzips down to ~14kb and we know it can build ~105 pages on the website.

  • 91% less selectors.
  • 83% less font-size declarations
  • 63% less background-colors (this still seems high)
  • 69% less colors.. and truth be told, while preparing this talk, I saw 3 or 4 repeated colors here and got this down to 10 unique colors.

Lighthouse: Before and After

Let’s check Lighthouse…

Not green across the board, but getting closer. You’ll see the number of green checkmarks goes up to up to 3 and we lost 2 red checkmarks.

Back to the Money Zone

Looking back at the money zone, our CPU Idle time, that’s more or less the onLoad meaning the CPU has a chance to take a breath…

Moved up to 6s. We’re getting closer.

Opportunities

What’s nice about Lighthouse it gives you recommendations for how you can improve your site and shows the estimated impact it might have on your site…

Doing those tasks has the potential to move us into that money zone.

Managing JS

npm

Over the last 5 years the JavaScript community has (more or less) settled on using npm to install dependencies, called “packages”, from the Internet.

This replaces manually going to a website, downloading a zip file, and then extracting that to your project inside a poorly organized directory structure.

package.json

Using npm to install these packages gives us a package.json which is a file that lists our dependencies. This is what we want. If you hop into a project, you can look at this file and get an idea of what technologies this site relies on. And if npm disappears tomorrow and is replaced by something else, we’ll have this list of packages that our needs to function.

And if these dependencies have dependencies, npm will fetch those files too. Very often, this can get out of control end up with thousands of dependencies… but hey.. at least it’s all organized.

ES Modules

JavaScript has also gained a native module importing syntax which improves the authoring experience of JavaScript.

You can import packages as objects and then write your JavaScript and then export pieces of your JavaScript that other files can import and use.

Imports and Exports. It makes decent sense.

But we didn’t have that…

We had a 1MB jQuery “App”

Auditing in Notion

I took a couple days to manually audit all the JavaScript in an app called Notion. I have all 67 files in here, found a little snippet as an identifier I could search the code base with, I found the number of occurrences of each, documented their dependencies and page weight. It was quite illuminating.

You might not need...

Looking at the codebase I found a few Responsive Design Solutions™ that you might not need anymore…

matchMedia polyfill - All browsers have this, even IE respond.js - A media query polyfill for IE6-8 Picturefill - Technically you need this for IE11.. but, there are workarounds HTML5shiv - Came with the famous HTML5 Boilerplate FastClick - Removed the 300ms tap delay in Webkit.. but this has been fixed LoadCSS - A script to compliment Critical CSS techniques, found out last week you don’t need it Modernizr - More or less replaced by @supports Webfontloader.js - Replaced by font-display: swap Require.js - A script to require scripts, don’t need it jQuery?!?? - Lots of jQuery’s good parts have been replaced by native browser tech and CSS animations.

TOTAL: 133.59 kb unzipped 49.25 kb gzipped

But looking at our site… removing jQuery is maybe a little more difficult. Take this freight.js tool, a way to declare button behavior in HTML that’s more or less a wrapper around $.ajax()…

391 Occurences

391 occurrences 
@ 1hr per fix 
@ 1hr per QA
---------------------------
19.55 Weeks of Human Effort

And we still end up with a difficult to maintain jQuery app.

Auditing our JavaScript now gives us the ability to have a more informed discussion about what to do next.

Perhaps a framework makes more sense?

JavaScript Frameworks were built to solve these kinds of problems with a lot more structure. So we’ve started on a path that leverages Angular to add more structure to our JavaScript system.

That which is not managed, grows

Alls this to say, CSS gets a bad wrap for being “append only”, but as you can clearly see JS can grow and grow and grow. The

Rolling Out A Design System

I want to talk about rolling out a Design System real quick…

A Design System is a group of people with different abilities coming together to stitch together some patterns.

I’ve seen this process go many ways.

I’ve seen a group of people come together…

Upload some patterns to the cloud…

And rejoice.

I’ve also seen a team of people get ready to ship a Design System…

And get pulled over to fight some fire…

And when they’re about to get back to shipping the Design System…

They get pulled over to someone’s big idea.

And after they’ve lost a few people on the way and are about to push that Design System out…

New people show up and ask “Why not use Bootstrap?”

And then you’re back to the beginning, having the same conversations.

And what I have to say about this is the Patterns, the assembling the puzzle pieces of a Design System, that’s not the difficult part. It’s the people part.

Conway's Law

Computer Scientist Melvin COnway once said in the 60s

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. – Melvin Conway

Or as I like to put it…

Rupert's Law

Your website is a manifestation of your organization’s problems. – Dave Rupert

Why are two pages on the website different? That’s because of 2 different departments. Why does one page look good and one look weird? One team values design, the other doesn’t. Why does one page have too much animation? Design has too much unchecked power. Why is the site inaccessible? The org doesn’t care.

In fact, I’d go so far to the success of a Design System hinges on a person who is over Product, Engineering, and Design being bought in on the benefits of a design system.

2019

Let’s fast-forward to this year.

Frameworks

JavaScript frameworks have exploded and are impossible to ignore in 2019.

  • Angular, from Google
  • React, from Facebook
  • Vue, the indie choice

HTML5 Components

Let’s look at the structure of a traditional HTML5 app…

This is the classic separation of concerns.

Angular Components

Angular has made the decision through their tooling to enforce a pattern called “co-location”. You HTML/CSS/JavaScript and Tests are split up at the Component level.

React Components

React components actually prescribes very little, but one thing React components do is render out HTML using a slightly modified syntax called JSX.

In general, the community at large has settled on a similar structure where everything about your component is managed (or pulled into) a single JS file. From this you get patterns like CSS-in-JS. Technically, this is demoing CSS Modules, but there are a lot of options here. And then relies on Webpack or whatever tool to split up and dissect this code.

Vue Components

Vue Components are awesome. The sort of take things a step further and say “We’ll do HTML, CSS, and JavaScript in one file, but we’re going to add some structure.

I like this separation of concerns quite a bit. It’s still all handed off, sliced and diced by Webpack but it’s a pretty great authoring experience.

Regardless of your preference, I think it’s interesting to see this iteration on the “Separation of Concerns” and how different frameworks approach the “componentization” trend.

Buzzwords...

  • JAM Stack is Javascript, APIs, Markup. You make a static site of some kind and use JavaScript to connect to APIs. Most of the application power is on the front-end but can still be static pages powered by jQuery. Could be a JS Framework. Very broad term.
  • GraphQL is the ability to build your own database queries from the front-end. It’s a bit hard to wrap your head around but gives developers power to create data queries on their own without having to bother a backend developer every time.

The Power of Serverless

Once templating and data querying move to the client, well now we have to re-evaluate our relationship with the server. A “Serverless” server is a server that spins up on demand. It doesn’t run endlessly and fall over every two days. You hit the serverless API, the server starts up, and then shuts down when it’s all over.

Mobile has hit the tipping point

One thing in 2019 we can’t ignore is that mobile has hit the tipping point.

Mobile use still increasing

According to Mary Meeker’s Internet Trends report we can see that mobile use is continuing to increase and laptop/desktop use is starting to taper off.

And interestingly mobile device time has overtaken TV. This is a big moment.

The traffic I’m seeing on client sites is overwhelmingly mobile right now. And if I truly start thinking Mobile First, it changes a lot of my perspectives. Even weird things like font-size should never go over 20px. Not really. But in a mobile world, larger type sizes become less useful.

The Expectation Gap

The expectation gap is large. So there’s a lot of work to do.

And worth mentioning, all those JS Frameworks I talked about… they’re not mobile first. They were designed and shipped in the desktop era. We have a long way to go.

2024

Let’s look into our potential future a bit…

Web Components

Web Components have a sordid past, but it’s worth talking about because Web Components are also trying to solve the same problem as JS Frameworks: the story of JavaScript Components.

The potential here is that Web Components would be able to be a native solution, requiring less JS to performantly construct mobile-first component-based front-end experiences.

Create and HTML Import

The original version of Web Components had a feature called “HTML Imports”. You author components in an HTML <template> element then use a <script> tag to define a Custom Element.

Import that HTML Import into HTML

And then you use HTML <link rel="import"> to import that HTML file so you can use that custom HTML element. It’s HTML all the way down.

It worked pretty well. Polymer and AMP were built on this.

Firefox kills HTML Imports

But Firefox draws a line in the sand and says they have no interest in implementing HTML Imports.

Their argument in 2014 was that they wanted to see how ES Modules would shake out and that might inform our decisions here.

Web Components: Part II

ES Modules has now landed in most modern browsers so the most common way to author Web Components now is using JS.

All-in-JS Web Components

This is using LitElement, a small wrapper around native Web Components to make them a bit more easier to author.

You can see this style of component now looks a lot similar to a React Component.

Import Module Script in HTML

Then in your HTML, you import a JS module file to use your new custom HTML element.

Web Components are kinda “meh” right now, but…

Rich Harris recently wrote about why he doesn’t use Web Components and it highlights a lot of the nuanced problems in building component systems and frameworks with them.

In a lot of ways, Web Components were designed at a low-level for framework authors to build frameworks on… but framework authors aren’t building on it. Seems like Web Components has failed it’s core mission.

Systems Using Web Components

That’s not to say you can’t use Web Components right now. Lightning Web Components from Salesforce uses them. And projects like A-Frame, Ionic,

HTML Template Instantiation Spec

http://w3c.github.io/webcomponents/proposals/Template-Instantiation.html

Unity Component Spec

https://github.com/TheLarkInn/unity-component-specification

Web Components have the potential to be great.

Web Assembly

Squoosh

Squoosh is an image compression app from a few Google Dev Rels.

LiquidFun

LiquidFun by Lorenzo Cadamuro is amazing. This would be nearly impossible with JavaScript. One thing that JavaScript is bad at is math. And liquid physics uses a lot of math. That’s being handled by the Web Assembly component handing the rending off to WebGL. This is very cool and very fast.

https://perceptiontoolkit.dev/

Web Assembly will make websites more powerful.

CSS Houdini

https://css-houdini.rocks/rough-boxes

https://css-houdini.rocks/irregular-grid

https://css-houdini.rocks/masonry

Houdini will make websites unique again.

So before I go…

Mobile First: Once More with Feeling

Thank you very much

Dave Rupert @davatron5000