Everyone wants sites that are responsive, beautiful, and fast. Do we need to make tradeoffs? And whose job is performance, anyway? In this event from February 26, 2015, we asked a panel of designers and developers from both in-house and agency teams to share their stories, strategies, and case studies. Watch the video or read the transcript here.
What we discussed
- Auditing an existing site’s performance
- Setting performance budgets
- Prioritizing and making design decisions
- Getting clients and colleagues on board
Featuring
Transcript
Mat Marquis: I want to welcome everyone to this, our first ever ALA: On Air event. With this event, we are opening up our lines of communication. Our goal is to bring the feel of a local web development meetup to the web, enabling a couple thousand of our closest friends to connect with our staff and our authors. We want you asking us the tough questions. We want you asking the stuff we don’t have answers for just yet, so we can figure it all out with you. I also wanted a radio host-style soundboard so I could make air horn noises and stuff but literally everyone said no… So, today we’re going to focus on the whole making websites thing.
We want to thank Pantheon for sponsoring us, which allows us to try out new things, like this very event. That’s Pantheon.io. They provide managed hosting for Drupal and Wordpress sites so you can focus on building cool stuff instead of fiddling around with servers and infrastructure and whatever the “cloud” is.
We are here today to talk about performance. I just got back from An Event Apart: Atlanta and the talks focusing on performance outnumbered the ones that didn’t by a huge margin. This stuff is clearly on everyone’s minds. Building a smaller, faster website is a huge technical challenge, but it’s more than that too. It means everything from changing minds within your organization to conscientious design decisions. How do we get our teams and the people that sign the paychecks as excited about building performant websites as we are? How do we keep performance in mind through every step of the design and development process? Once we’re all done talking, and thinking, and selling people on performance, where do we get started on actually building a faster website?
To answer all of these questions and then some, we have brought together some of the greatest minds in web performance today. We have Lara Hogan, author of the O’Reilly book Designing for Performance and a voluntary New Yorker, for reasons a Bostonian like myself can never understand. Lara runs an in-house team of performance-minded engineers at Etsy.
We have Scott Jehl, author of A Book Apart’s Responsible Responsive Design. He had the dubious honor of working with me back when I worked at Filament Group, which is a Boston agency known for developing accessible and highly performant websites for clients.
We have Yesenia Perez-Cruz, who is An Event Apart speaker and A List Apart employee of the month, which is a thing I made up just now. Yesenia is an in-house designer at Intuitive Company, focusing on designing for performance.
And there’s me. I am custodial engineer at A List Apart, and I will be your humble moderator for today’s event.
So, when we talk about performance, what precisely are we talking about? How do we define fast when it comes to web performance?
Lara Hogan: I’ll take it first. I think we used to always talk about performance in terms of how long a page takes to load in completion, but these days we’re talking a lot more about perceived performance, so how fast a site feels. I think that when we’re talking about performance in this panel, we’ll be talking not just about how the site loads overall but also how fast something feels.
Scott Jehl: I completely agree. I think perceived performance is the focus, and when we’re thinking about that we’re sort of aiming at what’s become sort of a de facto standard of maybe one second or so on a reasonably fast connection to get something usable to the person. On a slower connection, like 3G, something in the range of two seconds would be incredible. Those are the sort of goals we’re thinking about as far as what’s fast enough.
[05:00]
Yesenia Perez-Cruz: Yeah, and I think that the focus on perceived performance is really helpful because it really makes us focus on the people that are using the site and considering performance as part of the user experience just as anything else on the site. Just as we would consider a really usable navigation, we would consider performance something that we need to consider for people that are coming to our site and needing to access our content and our services.
Mat: So how do we measure that, then? If we’re looking at this strictly from the user’s perspective, what is the best way for us as developers, in a relatively privileged browsing context with new browsers and fast computers and bandwidth everywhere (but where I am right now), how could we look at that from the user’s perspective best?
Lara: I’ll kick it off by talking about a tool called WebPageTest, which is probably the easiest tool to use. You can type in the URL that you want to measure and choose a location from around the globe so you can get a sense of how your users globally are actually experiencing your site. It will also help you see how it loads over mobile, it’ll give you a shaped 3G connection if you want, and then it can give you a total waterfall, which is a way to see how your page is loading with number of requests and how big they are, etc. But it’ll also give you things like a filmstrip view and a video, so you can actually feel how that site is loading for those users.
Scott: Yeah, I can’t agree more. WebPageTest is so integral to our workflow now. Pretty much every time we make a major commit to a codebase, it’ll go up into a branch that has a preview URL and we’ll just funnel it right into WebPageTest and see how it impacted performance.
Lara mentioned the filmstrip view—I think that’s really become particularly handy for us because perceived performance is measurable but it can be a little subjective as well. Depending on the page, we find that certain types of pages have different content and we have to prioritize portions of the page that should be usable first and what deems a page usable kind of varies depending on the type of content on the page. So, that summary view that WebPageTest brings us is nice for quick numbers, like “Oh, it started rendering at 600 milliseconds,” or something like that. But looking at that timeline, you could say “Well, right around 900 milliseconds is where we’re actually rendering fonts and text and something is actually usable.”
Yesenia: I also think the timeline view is super helpful when it comes to comparing competitor sites, especially if I’m talking to a client and I can show them how long it took for the first byte to load on their site versus their competitors—that can be really compelling to show a client.
Scott: Absolutely.
Lara: We’re talking about stuff that’s live, stuff that you can actually point WebPageTest to, but with WebPageTest you can also run a local instance if you really want. Or, if you don’t need to get that fancy, while you’re developing something, Chrome DevTools has a ton of performance tooling. You can see, for instance, frames per second so that you can see if there’s a ton of scrolling jank and it’s really stuttering, and you can also see a waterfall and plenty of other things about performance.
Scott: I agree. Browser DevTools are kind of the immediate, easiest step while you’re actually hitting refresh and working with the code, and then once it’s up something like WebPageTest. Also PageSpeed Insights is nice, especially their documentation, and has really nice recommendations or tips about why your page might have certain bottlenecks that you can fix.
Mat: Do you guys use any of the bandwidth-throttling standalone OS X apps, or Windows apps, or any of that stuff, and if so, have you had a lot of success with those?
Scott: Yeah. There’s Network Link Conditioner; the new throttling that’s built into Chrome DevTools is pretty handy, I’ve found, especially just to throttle it way back and start looking at how assets layer in on an almost unrealistically slow connection just to see how priorities are organized.
Mat: I was going to ask if those were sufficiently terrible for real-world testing, like dropping packets, or is it like “the ideal, perfect-world 3G where no one else is using a phone anywhere.”
Scott: Yeah, I wish we had that 3G here, but we don’t. [Laughs]
[10:00]
Mat: Specifically you guys, while all focused on performance, you all come at it at sort of a different angle. Lara, you come at it from more of an organizational angle, Scott you’re a nerd and do a lot of stuff with semicolons I hear, JavaScript or whatever—I’m not really familiar with web development.
Lara: [Laughs]
Mat: And Yesenia, you’re a design-focused person. I’d kind of like you guys to sort of freely discuss among yourselves about what your differences in approach are. Speaking from a dev standpoint, you sit down and you make a website go quicker, but there’s way more to it than that final step in the baton handoff, where you have to sell clients on it, you have to sell supervisors on it, and you get your whole team on board, that sort of thing. It would be cool if you guys could talk about your roles in the process of building more performant websites.
Lara: Well, from my perspective, I work at Etsy and I’m the performance engineering manager here. So, I lead a team of developers whose job it is to help all the product teams start to make their stuff faster that they’re adding to the website. So, I have a couple of interesting pieces there—I have to convince these developers and designers to care about this stuff and I have to make sure the upper management is on board.
But I’m in a unique, very fortunate, and privileged position because all the people I need to convince are sitting around me, which is why I think it’s fascinating when I hear Scott and Yesenia talk about their work because it’s so much like convincing people who aren’t your co-workers all the time to get them to care about this stuff.
Mat: You can’t punch them in the shoulder, is what you’re saying.
Lara: Right. I couldn’t bribe them like I can with my coworkers. [Laughs]
Scott: I think a lot of the advice that Lara gives in her book about how you really have to bring the performance culture into your organization really translates to how we talk to our clients because from the first step, the first kickoff meeting, it has to be a priority and everyone has to care about it. I find it’s not that hard to get people to care about it because performance is really relatable to anyone who uses the web. It doesn’t have to be a technical discussion. It’s pretty simple. Typically we’ll have a lot of statistics to back up why other people care so much about how fast a particular site loads. But yeah, I think there’s a lot to that point that Lara talks about, trying to get everyone on board rather than just the development or just the design team.
Yesenia: I started caring about speaking about performance because I’d seen a lot of talks that focused primarily on implementation and how to optimize after something has gone through approvals and the design phase, and there’s really so many things that need to happen before you get to the implementation phase in terms of performance, because if something is signed off that contains huge images or a ton of fonts, it’s just going to be way more difficult to meet that end goal.
I think my challenge with this is that I typically work with clients that have maybe just undergone a big branding redesign that they love and they’re really into the idea of using a ton of typefaces or they’re really gung ho on this new technique, or they want to redesign so they can have a carousel. So, a lot of what I focus on is helping clients prioritize what elements of their brand will have the most brand impact, because we still want to create an experience that’s memorable and that’s going to make people come back, so we need some elements that still have brand impact but also—and I think Tim Kadlec has said this—has the most impact or the least amount of pain overall.
So, how can we still create a memorable experience that communicates the brand, that makes the marketing team happy and feels like it really reflects who they are, but also provides an overall really solid user experience? I primarily work in finding that middle ground and communicating the benefits of finding a middle ground there.
Mat: To that point, what is the best number of carousels to have for performance, would you say?
Lara: [Laughs]
Mat: Clearly we’ll need at least one.
Yesenia: Zero carousels. [Laughs]
Mat: I average around three per page…
[15:00]
Yesenia: Nested carousels.
Mat: Sure. Carousels within carousels. But more realistically to that point, does that make for a lot of strange looks around the desk when you kinda have to make those compromises? I mean I’m sure that’s a hard sell for a lot of people, when they say “We want 75 fonts” and you say “No, you may not.” That’s the start to a tough conversation sometimes.
Yesenia: To me, it comes down to, again, the conversation that all of this is part of the user experience and communicating how the business goals and the user needs that have already been defined at the beginning of the project—how performance is going to help you solve those things. I think it can be a little bit tricky if I’m saying “No, you can’t have this” if they really want it, but communicating how it’s going to impact the overall user experience and overall complete the goals of the project is how I approach that.
Mat: So, there’s also the client-facing side. Scott, how would you say that lines up with your experience in having those conversations? Because I’m sure there’s a lot of times, even if everything is designed with performance in mind, by the time it gets to the dev process it’s like “Maybe we can just sneak in one more italic.” How do you handle that same conversation?
Scott: I think it’s interesting… We talked about perceived performance—I think we’ve realized lately that a lot of the optimizations you make don’t have to necessarily cut into the weight but more so just prioritizing the way in which you’re loading your assets so that something usable is delivered a lot sooner and the nice-to-have elements can come in at their own convenience. So, perceived performance is nice in that way because you can satisfy all the business needs that are always there: deadlines, things like that.
But, you know, there are two sides to that coin. There’s the perceived performance angle, but there’s also overall page weight, which does still matter, because it actually costs people money. Right? If you’re paying for your data, which is something that most of the world does, every request takes money and time, so it is important. There’s kind of a balance; even though we can deliver a really large page relatively quickly, we still have to keep our eye on that.
Mat: Lara, how would you say that compares to… ? With your coworkers whom you have a rapport with, everybody knows each other, you can punch and bribe them— do you run into situations where they’re like: “Well, let’s just do this one extra font…” Do you kind of like have to rein that in ever?
Lara: Yeah. So, it happens two ways, generally. One is we’ll get a new hire, so somebody who just doesn’t know that this is part of the culture or doesn’t know how to measure as they’re building it. We’ve had stuff go out that’s like 10-12MB before we notice that it’s happened, and then we realize “Okay, this is someone new and they just need some training.”
But more often than not, performance is sneaky. Like, something will just slowly creep up over time because no one is watching it. So, more of our work has to do with alerting, making sure we’re measuring this stuff routinely and then we can easily go to the team later and say “Hey, we noticed that there’s a performance regression, here’s how you can fix it, or here’s what you can do about it.”
More often than not, too, is if somebody is building something out and they want to just sneak in an extra font, we’ll do what Yesenia recommended, is have a performance budget and then we can have a little cap-and-trade, like “Oh, you want to add an extra eight kilobytes of fonts? Go find that somewhere else, go save that somewhere else on the page.”
Yesenia: I’ve dealt with that because even if we agree, “Oh yeah, we want a fast site,” they’ll still try to sneak something in or say “But can we have this also?” So, finding a way to find a compromise is definitely helpful. Something that I’ve done with a performance budget in terms of picking a set of fonts to use, because fonts can have so many various weights and really become a large resource, is to figure out from my developers how much of a budget I can spend on fonts and then go back to the client with variations and options and have a conversation about which option is a better translation of your brand while still keeping within a budget. I’ve found that having conversations like that, where we’re evolving the brand experience together instead of me just saying “No” has been a lot more helpful.
[20:00]
Mat: So how does that work when… you’ve spoken to the client, you’ve spoken to the dev team, you’ve spoken to your own internal team, everybody’s sold, everybody is on board, everybody is being very careful about the 10MB pings that they’re putting wherever, avoiding regressions. What happens when that gets handed off?
Because at some step in the process, either the design goes to the dev team that may not be sold, or it goes to the client who has to maintain it long term, or it just goes to some other part of your organization—how do you, without threats of physical violence (which is my go-to), how do you maintain all the work that you’ve put in? How do you convey the importance of it to another team altogether who, for all intents and purposes, doesn’t really have to care?
Scott: I can take this. At Filament, we do a lot of the front-end and integration work, so we’ll hand off our somewhat static assets to their team and work with them to work it into the live codebase, and once it’s built, we usually set up some sort of monitor to leave them with after we’re done, such as tools found on WebPageTest.
Yesenia: I think something that’s important also, because a lot of sites that I design have a ton of image assets and images are a huge resource, is a lot of education and documentation about how to optimize the images. They tend to be the thing that gets forgotten in the implementation phase, where we can optimize the HTML and CSS as much as we want but then if they go in and upload giant uncompressed images it’s going to completely weigh the site down. So, that’s been a big thing.
Lara: Yeah, and I’d add that with any site, as it grows and evolves over time, things are going to shift a little bit and things are going to change, maybe new people get hired, maybe all of a sudden content editors can start adding stuff that they weren’t able to—things happen, things get bloated.
What I’ve found—automated testing is great, let’s get some alerting from third parties to help watch our stuff for us—but also what’s really good is I routinely give a presentation at Etsy about basics of design performance, basics of image optimization, and basics of how we do things here just to get everybody on the same page and remind them that this stuff is important, mostly because I don’t believe that there should be any performance “cops” or performance “janitors.” I don’t want my team to come through and have to clean up after somebody else’s mess or say “You guys messed this up.” I really want everybody to just get it and feel empowered that they can do this stuff too.
Yesenia: Lara, in your book you mentioned a lot about style guides and how important that is to maintain a fast site in the future, which I thought was really helpful information.
Lara: Thanks!
Mat: That kind of leads me to a question… Have you guys done much performance retrofitting? By which I mean there is a website, it could be faster and it falls to one of you to make it more fast? It’s clearly not ideal; it’s like saying “Let’s add accessibility” after the fact rather than building from the ground up that way, but these things do happen. When that falls to one or any of you, where do you start with that? Like: “I have a website, it’s too big, it’s too slow. What’s the first thing I should focus on if I want to make it fast?”
[25:00]
Lara: Scott and I were actually just talking about this on Twitter over the weekend, about some of the biggest ways we’ve found wins. The place I usually look first is images, just because they’re the thing that makes up the biggest page weight for us and often they’re the most easily overlooked. We can accidentally export an image that’s too big, we can accidentally forget to compress it or optimize it after, so that’s usually the first place I look when I’m seeing something for the first time.
Scott: I think one of the things that we prioritize most or tend to look at first is what’s sort of casually talked about as the “critical path”—so, everything that takes place in order of operation between when you first request that page and something shows up in your browser. A lot of those things are synchronous and need to happen in a certain order, but a lot of them can be deferred, and traditionally by default we haven’t tended to defer them as much as we should.
You mentioned retrofitting—we do a lot of performance audits at Filament, so a company with an existing site will come to us and say “Can you find any ways that you can make this load a lot faster, especially on mobile connections?” and that’s one of the first places we look. Whether or not they have JavaScript files and CSS files linked from the head that are blocking the page from rendering until they finish loading and parsing on the client side, that’s a big deal—it’s kind of like a potential single point of failure, any time we’re waiting for additional requests while the page is here but it won’t be shown until all those requests finish up. So, trying to defer as much as possible.
I think that probably the biggest tool and advantage that we’ve found lately in that regard is CSS inlining, because you really want a good portion of your CSS to be in the head of the page so you don’t get that flash of unstyled content before the page renders. But you generally don’t want all of your CSS there. So, what we do lately is use some tooling—sometimes Grunt tools, things like that—to figure out which portion of your stylesheet is actually critical to render the top portion of the page and we inline that portion and load the whole stylesheet in a way that doesn’t block rendering. I have to say, in the last two years that’s been the most significant impact to perceived performance, just that one approach. It’s just incredible that we’ve seen loading times cut in half just by implementing that. So that’s what I’d recommend.
Mat: We are running a little short on discussion time. So this is probably gonna be our last question before we get into the audience Q&A. What is coming up to facilitate making more performant sites? Like, are there any specs, tools, or browser features on the horizon that you guys are really excited about that will help us do our jobs better and make faster sites?
Lara: Yeah, I mean, I can kind of kick it off by saying HTTP2 is something that is basically here. It’s a little bit tough right now to figure out what you can and can’t implement for your users or what’s supported, but there’s plenty of new stuff that’s being developed online to help you start to think about how it impacts things like sprites and other things you’ve implemented as workarounds for performance that will be unnecessary with HTTP2.
Scott: Yeah. I totally agree. And one of the most exciting and interesting features in HTTP2 will be server push. Once that’s available to us, all of that inlining workflow that I just talked about sort of becomes irrelevant. We’ve sort of been faking as if we had HTTP2 before we really had it. So, it’s not necessarily, at least to my understanding, going to be detrimental that we’ve implemented these things for version 1 when we switch over to 2, but we won’t need to do them as much anymore as more and more browsers begin to support it. So that’ll be really nice.
On top of that, font loading events, just being able to show some text ahead of time and then let our custom fonts layer in at their own convenience—my biggest pet peeve as a user is knowing that the page is downloaded on my device and it just won’t show until the fonts show up.
[30:00]
Mat: From the design side of things, is there anything really exciting coming up, Yesenia, that lends itself towards faster websites down the line?
Yesenia: I don’t know if there are specifically any tools that I’ve seen from a design perspective. I just think that there’s been so much more awareness about performance. Like you were saying, it was such a big topic at An Event Apart Atlanta. I think it will be easier to convince people moving forward about the importance, so there will be a little less selling.
Mat: Cool. Okay. We are now going to switch gears a little bit and we’re going to answer some questions coming in from everybody watching right now, which is—no pressure—like a scant 1,500 people. So don’t panic; everyone’s hair looks great.
So I’m just gonna start at the top of the list. And this is actually something I have had asked of me, and I have considered, in the past. Scott, the inlining technique that you mentioned, the above-the-fold CSS, which is a huge performance enhancement and, like you said, can cut the perceived load time in half—it seems super gross to put CSS in the head of a document that way. Like, it feels really clunky and, like, sprite sheet-y, like a hack that has tremendous benefit, but seems really clunky. I know you’ve mentioned there are tasks to automate that some, but has it tripped you up at all or has that slotted into your workflow in a reasonable way without being gross?
Scott: That’s a good question. Like Lara mentioned, we have an evolving HTTP standard that will make these workarounds irrelevant and that’s great. But I think there’s a real measurable benefit to users today to implement this, at least for the next year or two. That standard is not going to be supported across all of the browsers that need the support for quite a while, so it’s going to be kind of a tricky period where we’re thinking about both environments for a little while.
But to your question: yeah, I think it is a little gross. Right now a lot of performance optimizations are that way, right? Spriting—you would never want to edit a source image as one portion of a giant sprite. But thankfully you don’t usually, we use tools to combine our source images into a sprite. I think of this inlining step in kind of the same way. When we’re working in our development environment, we are not working with inline CSS in the head of an HTML document. We’re working with CSS files or Sass files that get combined, just like we always would. To be honest, this stuff really just stays out of our way. It takes a little upfront configuration, but we hardly think about it after that.
Mat: All right. What do the non-Scotts think of this technique? Lara, you said you guys were discussing this on Twitter—”discussing” leads me to believe that you may not necessarily have been 100 percent on board.
Lara: What prompted me to ask Scott was it just seems, like you said, kind of gross. My biggest fear when I recommend things to people is “What is the operational overhead going to be for something?” In the performance world, there are so many micro-optimizations you can make that just sort of time-suck and maybe give you 10 milliseconds here or there. So, I was concerned at first—I mean, it’s something I recommend doing because there’s an obvious benefit here but I wasn’t sure how big the benefit was until I started talking to Scott over the weekend. I’m really impressed with all of the responses both from Scott but from plenty of other people out there about how much it saved them.
The tricky part—I was looking at this for Etsy and it has a lot of A/B tests that are constantly running, which change different pieces of the site, including things that are above the fold, constantly for our users. So for a site as large as us, it would probably take an unusual amount of operational overhead for us to implement inlining CSS. So right now, we’re focused on other kinds of optimizations. That’s not to say it’s not going to be a huge benefit for us, it just so happens that for a site as large as ours it takes a lot more to implement it.
[35:00]
Scott: Yeah. It affects every template on the site, so it’s definitely something you have to look at holistically. But just the idea that without that technique in place and on HTTP1, you’re going to request an HTML document and then the best case scenario is that if you’re referencing CSS in a traditional way, you’ll download that document and then the browser will start parsing it and see “Oh, there’s a reference to a link, to a CSS file. I’m going to go get that and just stop everything I’m doing, and not show the user those feeds that I already have right here.”
The idea is just to avoid that second delay because latency is a big problem, all that time spent traveling on the network really adds up, especially on 3G and slower connections. So, just to have the CSS that you need right there is kind of amazing; it starts to correlate your round trip time to the server with the time that it actually takes to start rendering the page and it guarantees that you’ll see something in under a second.
Mat: So I’m curious about this. In the same vein: Yesenia, if you went to an internal or an external dev team and you said “Put a bunch of the CSS in the head of every page,” do you think that would fly? How would you even begin to approach that topic?
Yesenia: That would be a little bit challenging because it definitely requires people changing workflow and people have to be willing to commit to a change in workflow. I feel like with performance and dealing with different people on the team, there has to be an understanding that everyone is going to have to give a little, because the end result is going to be better for the user. But if people aren’t willing to do that then it can be really challenging for the internal team and also for the client team. I’m also wondering—this may be a little off-topic—how that technique would work if you have to load a lot of external scripts or ads, so if that’s something that I’d run into a lot where the ads just block anything else from loading on a page.
Lara: That’s an interesting point. I feel like the stuff you’d be inlining has to deal with your actual website chrome, so hopefully you get around some of the blocking issues. But for this case, I think that you wouldn’t necessarily be inlining the stuff that the ads need to see, it’s really the stuff that’s part of the site chrome. The ad stuff is a whole other complicating factor.
Mat: Third party stuff is not pleasant to deal with. Ads in particular use a lot of really janky old JavaScript that actually makes it incredibly difficult to load them asynchronously. It’s almost like they went out of their way to make it a thing that you can’t just layer on after the fact—it blocks the page right there, it slows everything down. I’ve had a little luck mitigating that with some wild hacks, like with spacer divs and iframes. It’s doable but it’s something where it really helps to have a direct line to somebody on the ad team with stuff like that. Like, “This is going to be a responsive site. You probably want responsive ads so everyone sees them. Let’s figure something out for how to load these in a more responsive way.”
[40:00]
Mat: All right, so we’re soldiering on. Q&A… We have a Chris Coyier—
Lara: Oh, who’s that? [laughter]
Mat: I dunno. Some guy. So, we have Chris Coyier, asking: “What are some strategies for not regressing in your web performance?” which we kind of went over a little bit. But what would be cool is if you guys could give me soundbites, something super-tweetable. How do we prevent regressions after we’ve put all of this work into all of this performance? What’s your one big thing?
Lara: This is really hard. Thanks Chris. [Laughs] I love that guy. So, one thing that I have tried to prevent regressions is to make it really clear when people are making performance wins, so that people are thinking about this all the time. Oh, that’s not a sound bite! I’m so sorry. [Laughs] We celebrate performance wins!
Mat: You don’t have to soundbite, you can talk more.
Lara: [Laughs] We actually have a dashboard that we put up, and it’s a picture of me and the guy or girl that made the actual performance win, so we have the graph of what the speed used to be and how it improved. It’s up on a big wall; we have a quarterly performance hero. This really does help us prevent regression.
Yesenia: That’s amazing. I love that.
Lara: It’s pretty good. Also, baked goods help to bribe people to make their stuff good.
Yesenia: [Laughs]
Mat: Literally my first reaction was “Oh, so there’s cake? A cake is involved?” Because I’m sold. I’ll do pretty much whatever for the cake.
Scott: I like that. Let’s see… Get the client to think like they’re a user, put themselves in their user’s shoes. What does the user care about? What’s the most valuable thing to them with regards to the service that they’re trying to provide?
Yesenia: I saw a tweet today, and I think it was a Karen McGrane quote, that said “If all corporate executives had to use only their phone for a month, sites would instantly become faster.” I think the other thing for after handoff is the idea of designing modularly, not creating a style that you don’t need. Also, throughout the entire design process, not just at the handoff, educating your client about why you designed that way, like why I chose to design a series of components and why I kept the type and the colors very limited, and educating about that thought process, leading that into a documented pattern library so that if someone is trying to add new pages or add new components afterwards, they can start from components that have already been optimized instead of starting from scratch with really bloated code.
Lara: To underscore that point, the style guide we have internally includes copy-and-paste-able HTML, CSS, and JavaScript, so people don’t even have to think, they can just copy and paste existing highly performant stuff.
Scott: Yeah, that’s so important.
Mat: So… we’ve actually covered a lot of these so far… which I think kind of means that we’re nailing this thing. But I’m no expert. Hm, this is interesting: how much of the content of the page should be lazy-loaded? Besides obvious stuff like images below the fold, should this apply to all content that doesn’t need to be immediately available? Should we lazily load text in a collapsible, like an accordion or a carousel, for example?
Lara: You love your carousels, huh?
Mat: I can’t get enough. I love carousels, I love Flash intros; those are my two main things. Both mission-critical.
Lara: [Laughs] The obvious stuff is obvious, like you just said; obviously things that are hidden, that are not available to the user immediately are great things that you can lazy-load. My general concern with lazy-loading is how editable it will be in the future—how easy is it for someone who is new to working on the site or who wants to come and redesign it later, how organizationally optimal is that going to be? Because often that can create more problems than it has initially helped.
[45:00]
Scott: We don’t do as much of that as we used to, I think because we’ve started to just use other techniques that we’ve found to be just as successful. To Lara’s point, chopping up a page like that is not something you should consider lightly: it affects the CMS side of things. But yeah, I’d agree, a lot of types of content should definitely be loaded lazily, like advertisements. Especially if they’re talking to third-party networks, they can be pretty slow and we don’t want that to hold up the page content.
A lot of times, ads are actually critical to the site’s content, it’s something that’s depended on being there. So, it’s not a question of whether or not it will show up, but trying to de-prioritize how that ad-loading affects the rest of the page showing up or not sooner can be really important.
Lara: Yeah, and I’ll clarify: there’s a distinction between lazy-loading and asynchronous loading, and I think what we’re really aiming for here is always going to be asynchronous loading. “What stuff can we delay grabbing until we absolutely need it?” I think when we’re talking about lazy loading, it’s much more about “How can we fade in these images as you scroll down the screen?” which adds a whole lot of complexity. But really the question is “How much can asynchronously load? How much can you actually wait until you absolutely need it to load?”
Scott: Yeah. Sometimes social buttons can be brought in lazily on user interaction. My colleague at Filament, Zach Leatherman, built a tool for that just because they tend to be quite heavy, like Facebook’s buttons and things like that.
Mat: I was going to say, would you consider those to be ridiculously heavy or nightmarishly heavy?
Scott: I’m not up to date on them—I know they all work pretty hard on trying to get them to be as light as possible. That was pretty diplomatic, right…? [Laughs]
Mat: This is a more sound-bitey one. What are the most important front-end performance metrics to focus on? So, like, you’re in an elevator and you’re talking to somebody wearing shoulder pads, they’re very important, and they’re like: “How do we know our website is fast?”
Lara: The thing that I usually hit first when I’m talking to focus on metrics is Speed Index, which is a metric provided by WebPageTest, and it provides a visualization or a number that helps represent how fast the above-the-fold content loads for the test that’s been run. Speed Index is a pretty good measure for perceived performance—obviously not for scrolling jank and other things like that, but it will help you basically get a sense of how fast your site is immediately loading for a user on that screen size.
Scott: Do you have a number that you try to shoot for as far as Speed Index? Does it vary per page?
Lara: We aim for 1,000. We try. [Laughs]
Scott: The top three things for me: compression—make sure you’re transferring everything in a good GZIP. It’s such an easy thing to do; any text files can be lightened so much just by transferring with compression; looking at the critical path, figuring out what’s blocking the page from showing up as quickly as possible and just get them later—video, whatever kind of media you’re loading on that page, just make sure they’re light.
Mat: Yesenia, what are your big things from a design standpoint?
Yesenia: A lot of what we’ve already heard: making sure that things are seen, that the site is loading. So, again, just perception, making sure that it doesn’t take a minute before they even see that something is happening. From a design perspective, absolutely, images and making sure that they’re optimized is huge.
[50:00]
Mat: So we actually have a couple of related questions, going back to that… Is there a way to load certain fonts in a responsive manner? Meaning: load two weights for a larger viewport and maybe only one font file for a smaller one, and it’s baked into the design, it’s not compromising anything in the process. Is there a smarter way to load those, based on device components? And, to make things worse, how do you deal with that when it’s coming from font providers?
Lara: Scott, I think you should take this one. [Laughs]
Scott: Okay, sure. Yeah, we’ve done a lot of writing on font loading this year. We kind of thought we had everything figured out and then a month later we wrote a post that said: “Ah, this works even better than the first thing we found.” So, originally we were loading all our font files as data URIs baked into the CSS file and we would just load that CSS file asynchronously so it wouldn’t block the page and then would just sort of snap into place whenever they loaded. But that loses a lot of the benefits that you get from using @font-face and the native capabilities in CSS to reference fonts.
So our latest recommendation is to use @font-face to reference your fonts. What’s nice about that is by referencing fonts through @font-face, that doesn’t necessarily trigger them to download. They’re not going to download until… Well, it varies by browser. I see Lara shaking her head. [Laughs]
But generally, to get back to your breakpoints question, if you were to, say, apply weights to a couple elements at one breakpoint and then another one at another breakpoint, in theory, if things were working properly, that third font would only be requested if that breakpoint happened to be in play. I can’t think of a site where we’ve loaded particular fonts differently per breakpoint, so that’s sort of new to me. But what is pretty fresh in my mind is how we apply the font to the page to make sure that the browser shows text before the custom font comes in. And we recently wrote an article about that… but the approach we’re using basically mimics a new thing coming into browsers , font events, which allow us to wait for a font, a custom font, to load before applying it to the page. And I think that’s really nice and important because it helps us defend against that often very annoying behavior where you’re staring at a blank page while fonts load.
Lara: Yeah, and to support that, we at Etsy use that breakpoint trick so we don’t load custom fonts unless you’re on larger screens. So, we use breakpoints to help us figure out when to load different fonts, and so we’re doing a little bit of testing there. We’re also doing some testing with caching, so we can check a cookie to see if a font has already been loaded for a user, and if not then we can download the font asynchronously and show the regular text on the first page load.
Scott: Nice. So when you do that you don’t even show the font until they visit a new page?
Lara: Right, you got it. We’re testing it.
Scott: I like that. It’s hard to convince the design team sometimes to buy into that one. [Laughs]
Lara: Totally.
Yesenia: Designers… [Sighs]
Mat: Yeah, I was going to ask what you had to say about that, Yesenia.
Yesenia: I have been in situations where we have loaded a smaller amount, maybe like one web font for smaller devices, and then as you get to a desktop width then you can have a more rich experience. That was actually not even only for performance but just because creating a type scale for a smaller device, having a ton of variation can be a little bit confusing, whereas for a larger viewport you can have a little bit more of that typographic variation and it doesn’t start to look, I don’t know, overly cluttered. So, that initially started just because, from a design perspective, scannability was easier with a more limited type system for smaller devices.
[55:00]
Scott: That’s a great point. Lara, when you were shaking your head, have you written anything about some of the discoveries you’ve run into with how it should work versus testing it and seeing “Oh, it’s not quite there yet”?
Lara: Yeah. Thankfully this is really local to old versions of IE, the issue that I was shaking my head at before, just because IE8 and lower download all the fonts that are referenced in a CSS file whether or not they actually apply to the given page, and IE9 and above with compatibility mode turned on also exhibit that same behavior. That was the only reason why I was shaking my head when you were talking about it, because modern browsers do a great job of it.
Scott: Thanks. That’s important to consider.
Mat: All right. So I think we have time for one more big question from an audience member, who, I stress, is not me. And there’s no pressure here. So, with many sites using visual storytelling with large images that are the content, how do you ensure fast load times if you’ve already ensured the images are properly compressed? You know, everyone has done their jobs correctly—because compressing them too much looks very bad on retina… Are there any solutions to this tricky issue of serving context-appropriate images to users of the web?
Lara: I would love to hear what Yesenia says.
Yesenia: I’m wondering if Mat is asking himself a question.
Mat: I wanted you guys to talk about responsive images for a while, but that’s a real question somebody asked, that’s legitimate. There’s probably some cool stuff out there to solve this, I bet… But y’know, you guys discuss. The key to moderating is putting the panelists in the most awkward possible position.
Lara: [Laughs] Just so the audience has context here, one of the writers of the picture spec is also our moderator, and he is teeing us up to answer a question that really is directed at him.
Mat: Well, I mean, it’s directed to you guys. I’m just relaying; I’m just the messenger here. But how do you ensure fast load times when you have a ton of images, and you’ve done all the compression, and you’ve stripped down all the metadata, and you’ve done everything Photoshop will allow you to do to make those images smaller? What do you do in terms of making a fast website despite that?
Lara: Go for it, Scott. [Laughs]
Scott: Okay! Well, Lara mentioned the new responsive image features that are now landing in browsers natively, which is really neat. We have the picture element, which is an HTML element like any other; it lets us control the source of an image element. It gives the browser several options and criteria to determine which particular appropriate source should be applied to an image within that picture element. So that’s pretty neat. It works pretty well for art direction when you’re trying to pair particular content images with whatever happens to be happening in the layout at a particular breakpoint.
Yesenia: Yeah… I will say that someone on a marketing team loves the idea of being able to art-direct an image based on the device size. So, the image can be vast and show more background if you have a wide screen, but you might want a close crop when you’re on a smaller device. So, that’s something that I think people that are focused on the marketing of a site are really excited about.
Scott: That’s a great point. On the flip side of the spec is hue attributes that we can apply to image elements—SourceSet, Size It. Using a combination of these, we can sort of just offer up potential images that the browser can choose between based on conditions that it knows a little bit more about than we might as developers. Those conditions could be anything from device resolution, viewport size, network speed—anything that the browser deems relevant for the future, those attributes sort of put the control in the browser’s hands, which is nice if we’re not looking for particular crops and stuff like that.
Did you want to add anything to that, Mat? Did I miss anything? [Laughs]
Mat: Me? No, I’m just an impartial observer.
[60:00]
Scott: What about browsers that don’t support those things, Mat?
Mat: Yeah, are there any good polyfills out there for that? I heard about this “Picturefill” polyfill, written by our own Scott Jehl.
Scott: And a larger team these days. Yeah, so there are scripts that you can use to make those features work in browsers that don’t understand them today. You can find all of those online. [Clears throat]
Mat: Alright, I promise I’m not gonna close on that one. We have brought up the fold like 20 times. What is the deal? In terms of the above-the-fold critical CSS, are we drawing a new arbitrary line there? Does that matter? How do you decide where the fold is?
Lara: Yeah, that’s definitely not an awkward way to end this…
[Laughter]
Mat: We’ll do one more after this.
Scott: There is no fold, right? It varies between every device and every viewport size on those devices. But it is fairly standard that web pages load from the top first; the first part of the page usually means the top. So, if we can guess even a vague notion of a large subset of that page that constitutes the top that most users see, we can start to optimize how quickly we can make that portion render compared to the bottom of the page, which can take a little longer if we’re not going to see it right away in the initial rendering.
To me, it doesn’t need to be a controversial thing. We use this term a lot now. We stopped using it, now we’re using it again. But I think it’s useful shorthand to just say: the critical portion of the page, the top.
Yesenia: I wish we could find another name for it. [Laughs]
Lara: To be real clear, the reason why we keep on throwing this to Scott is because he wrote a really great book called Responsible Responsive Design that’s all about the squishiness of the web and how weird it is to talk about these things.
Scott: Thanks, Lara. But to back up from that, this technique is not my own creation. [Laughs] So, a lot of developers were the first ones to blog about these ideas. It really changed the way we’re thinking about perceived performance these days, so it’s pretty neat.
Mat: What I take away from the fold discussion is that the web is squishy and weird. That’s the bottom line.
We are officially, even though we ended on a still pretty awkward question, out of time. I want to thank all of the panelists for joining us here today and I want to thank all of the viewers at home, or at work, or at lunch eating a sandwich. We also want to thank Pantheon again, our sponsor, which has allowed us to try out new things like this.
We’ve got a bunch more ALA events planned, so be sure to sign up for our events emails or keep an eye on the Twitter account, or alistapart.com to hear about what we’ve got coming up. We look forward to seeing everybody at the next one. Thanks, guys!
