Jeremy Wagner: I’m smashing. How are you?
Drew: And sort of as you mentioned there, sometimes it’s the individuals who have the sort of stand the most to lose by not being able to access a service who get penalized by this sort of thing. Those people without fast data connections or without very capable devices are sometimes accessing services that mean everything to… it means everything to them that they’re able to gain access. So it becomes almost a humans rights issue in some ways.
Jeremy: Yeah. I mean, we tend to see web performance get framed in terms of business value. I was a performance consultant for some e-com and like a major food company, a major e-com… like a store, like an electronics outlet and it’s very tempting to do that, right? Because when you work for a business, I mean, obviously you want financials to be healthy and web performance does play a role in that I think. I think there are a number of case studies that prove that out. However, there is that human aspect and even for businesses, like say like grocery stores and that kind of thing. Yeah, they’re revenue driven. They want to have healthy finances and so web performance is part of that, but they’re also serving a critical need, right? Like you have to eat, right?
Drew: I mean, we’ve, we’ve seen a sort of glimpse of that over the last 18 months or so with COVID and people going into isolation, and as you say, needing to order groceries to be delivered. The web becomes a lifeline for them at that point. They’re feeling under the weather, not able to leave their accommodation because they’re isolating and they have to get food and they have to get essential supplies. So yeah, it’s an ever increasingly important part of just everyday life for us all, I think.
Jeremy: Exactly. And going back to the sort of device story, Tim Kadlec wrote an amazing piece a couple years back, I think it was two years, maybe it three years back, but it was called Prioritizing the Long Tail of Performance. And when you look at that… so in web performance parlance, we kind of talk about lab data versus field data. And lab data is like when you’re running lighthouse or you’re throwing a website at a webpage test to see how it’s doing. Those are all really useful tools, but when you look at that field data, you really start to get a larger picture and a larger view of who your audience really is. And in this article, Tim Kadlec talks about what it means to prioritize the long tail of performance. Meaning all these devices that… are maybe not as beefy and as powerful as the devices we as developers may have.
Jeremy: And the idea behind that article is that if we can focus on that 90th or 95th percentile we’re… and improve that experience for those people, we’re building a faster web for everyone, including those on fast devices. And attack a data point on that in the US and this is just from like statcounter.com. Something like 28 point… around 28% of people are on an iOS device that this tool captures. And around 21% of them are Android. And Android tends to represent a good chunk of that long tail of devices, because Android’s not monolithic. Multiple device manufacturers make Android phones, but to kind of contrast that with the world, because the world is more than just the United States, it’s around 16% of people who use iOS and around like 41% of people who are on Android. So it really does pay to prioritize those slower or potentially slower experiences.
Drew: I read in your book about device thermal throttling, which isn’t something that I’d really ever considered before. What are the concerns there?
Jeremy: The concerns there, and I’m not like an expert on microprocessors by any means. I’m just the web developer who probably writes a little too much, but… so the idea behind thermal throttling and this exists in all systems, not just like phones and tablets, is that a microprocessor will… when it takes on excessive workloads or really just workloads in general, the waste product of that work is heat. And so devices have ways of mitigating this. Like your laptop has both a passive and an active cooling device.
Jeremy: So like a passive cooling device is like a heat sink or some kind of heat spreader. And the active portion of that is like a fan to more efficiently disperse heat. Some like custom PC builds might use like liquid cooling, which is sort of a more relatively extreme example, but a mobile phone doesn’t have that because where are you going to really fit a fan in all that, if portability is kind of your thing, right?
Drew: So it’s a sort of a negative feedback loop. Isn’t it? You give the device lots of work to do. It gets very hot and then is less capable of actually executing that work because it’s having to throttle back.
Jeremy: Right. And again, I’m not a microprocessor expert. I’m sure that if, if, if an engineer who was really intimately familiar with this, could probably correct me on some of the particulars, but the general idea is that yes, as that environmental pressure increases, the device is less able to cope with these heavy workloads until that pressure decreases.
Jeremy: And that if you don’t critically evaluate the runtime performance of a framework, you might be leaving some opportunities on the table to better serve your users. So a good example, I always like to use is react versus pre-act. I’ve been kind of banging this drum for a while. I did an article for CSS-Tricks a while back that profiled a basic click interaction for like a mobile navigation menu. And it sounds trivial, but what you find is that across all devices is that react delivers on better runtime performance, but it has basically the same API. There are differences, there are some tad differences and stuff that can be papered over with pre-act compat, but that simple… and I shouldn’t say a simple choice, but that choice, that fundamental choice can be the difference between an experience that works really well for all users or at least most users, or an experience that only works well for some. Hopefully that made some sense.]
Drew: I mean, with all the frameworks and build tools, they seem to be getting better all the time at doing things like tree shaking and optimizing the bundles that they ship and how they’re then delivered to the browser. When using big frameworks, is there a tipping point you think where you are writing such a big application, so much code of your own, that the framework is enabling you to ship less code because of all of its abstraction?
Jeremy: That’s kind of a difficult question to answer. One aspect of that is that the framework itself represents an amount of code that you can never optimize away. So having like a thin framework, like pre-act or any number of like… Or like spell for example, that that helps a lot. But the problem that I’ve seen and I think the data from the HTTP archive kind of supports this point is that it seems that anytime we have these advances in microprocessors and networks getting faster is that we tend to consume that gain, right?
Drew: In the book you talk about websites and web apps and how understanding the difference and which one that you’re working with helps you choose your strategy for how you develop and optimize. Tell us a bit about that.
Drew: Is there a big chasm, do you think between the people who take the approach of we’re going to publish a website and it may have whatever interactive functionality and those who say, “We’re a software company, we’re making a product, a software product and our platform that we’re going to deliver it via is the web, rather than native applications for multiple platforms.” Is it likely that they’re approaching the problem in completely different ways? Are the considerations different depending on your outlook at that point?
Jeremy: That’s a tough question. So-
Drew: It was tough for me to say.
Jeremy: I would say that a company that… so a good example would be like a news, right? They’re well served by the sort of website model, because it literally is a collection of documents, articles. And the people who develop those experiences are probably going to have a different skillset than say a company like Spotify or a company that has like a large web application like Envision or that type of thing. And so yeah, I think they’re going to come at this from different angles. The way I’ve kind of looked at it is that there’s a segment… or at least this is how I perceived the web development community at large is that there is a segment of people, of web developers who came from non-traditional software development backgrounds, right? And I’m one of these people, I was tinkering with the web when I was kind of like a kid, right?
Jeremy: Like in middle school and doing stupid fan pages for all like the video games at the time that I really liked. And I never had that sort of computer science education. There are computer science concepts that I’ve picked up along the way. Then there’s also a segment of developers, especially I think that have come around in the last five to 10 years who approach this in a more computer science oriented way. And I think that’s going to… those differences and experiences are going to lead each of those groups to draw their own conclusions about how best to develop for the web. But I think the only way that you can really… That you can sustainably develop for the web is to critically evaluate what it is you’re building and to try to align around an approach that best serves users of those products. And that’s sort of where the website and the web app models kind of sit in my head when I evaluate these things.
Jeremy: You don’t have to have like deep knowledge of like… of state management stores or state management frameworks to really pull these kinds of things off. And I think that noticed is well served by that particular approach. But to your point, I think there are opportunities in any website to move closer toward the middle of the spectrum without going all in on all client side routing like heavy like frameworks that manage everything on the client and that type of thing. I think the island’s approach is starting to explore what that looks like. And I’ll admit, I’ve probably have unintentionally done some of the islands type thing. I think we have for quite a while, we just haven’t really put a name on it. But I think now that we’ve kind of identified that as like maybe a midpoint, we might start to see web experiences that deliver on a good user experience, but are still more interactive. Hopefully that wasn’t terribly meandering.
Drew: It sort of harps back a little bit to the days when we would embed an island of Flash or-
Drew: Something in a page where this is our little interactive section, and the rest of it sort of flows around.
Jeremy: Yeah Like Flash, oh my God, three iterations of my personal portfolio out of college were really crappy to advanced Flash knockoffs and like hover effects. And that stuff was really, really fun. And I miss it sometimes like there’s a whole just wealth of content that’s just going to kind of disappear because we don’t use Flash anymore. And that really sucks, but in a way it was kind of the precursor to this sort of islands thing that we’re talking about. Which is you could just have like a static webpage and everything, but then you would have this really richly interactive experience just kind of like plopped right in the middle of it.
Drew: For a long time, progressive enhancement has been considered a best practice way to build web experiences. Is that still the case, do you think?
Drew: When it comes to measuring performance. We hear a lot about core web vitals, mainly from Google. Are those really the benchmark up that we should be measuring against? Or is that just what Google wants us to think? I now appreciate this might be a difficult question that you started working at Google.
Jeremy: Yeah, yeah. You know, so I’m speaking for myself here. I think that web vitals are… the initial core web vitals are a good attempt at defining what parts of the user experience are important. I do think that metrics such as cumulative layout shift and largest Contentful paint start thinking about the experience in ways that we really hadn’t started to quantify. Before particularly cumulative layout shift, because if there’s ever been a moment where you rage tap it’s because a button likes to move around the page or something. I mean, I think that that’s a helpful thing to measure it. It is imperfect. And I think anybody who works on core web vitals would agree that improvement is desired in some of these metrics. There are other metrics that I don’t necessarily agree with entirely. Like first input delay is a metric that is kind of difficult to put a pin on.
Drew: I guess it’s, it’s one of those things that you can always measure against yourself, measure your own improvements or whether your experience has got worse if your score changes, not caring so much about the traffic lights, but caring about what you know about the context of your site and how a change has made an improvement.
Jeremy: I think that metrics such as cumulative layout shift are excellent, but they too could benefit from a little bit of improvement. As it stands, cumulative layout shift, mostly measures layout shifts that happen during load. And as we know, when a user visits a page and lands on a page that layout shifts can occur at any time, right? So there’s definitely work I think that that can be done to improve how we observe of that kind of phenomenon, for sure.
Drew: I think layout stability is one of the things that’s actually a little bit more difficult to achieve when you’re working with progressive enhancement. Sometimes when you load a server rendered page and then begin enhancing it in the client, there can be a danger of creating that sort of layout shift, can’t there?
Jeremy: Absolutely. And that’s kind of where hydration of components becomes kind of tricky because the dimensions of that component may change for any number of reasons. Like there could be content present in the client side component that just doesn’t render on the server because of state that isn’t evaluated until it’s executed on the client. It’s an extremely difficult problem. I’m not going to sit here and pretend I have like the silver bullet for it.
Jeremy: So I would recommend the tail end of what you just said is a good way to lead in with this. We shouldn’t try to prematurely optimize unless of course those optimizations can be achieved very quickly and easily, but if it takes a lot of effort to optimize early on, when there aren’t really a lot of performance issues, I would argue that code splitting is probably something that doesn’t have to happen. You can probably just load that functionality up front.
Jeremy: So that hopefully by the time, and I would hope because it takes a little while to fill out a form that the network has enough time to pull that down so that when the dynamic import is called, it can just hit the cash to get what has already been preloaded. It’s something I’ve been working with a little bit here and there, and it’s difficult to do in all situations. Like for example, you can’t do this reliably all the time on hover because some devices don’t have a fine pointer. They have… they’re… it’s tap inputs, right? So a hover occurs at a different time than if you had a fine pointer, for example.
Drew: That’s nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that’s sent over the wire.
Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don’t quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.
Jeremy: In the case of the NHS or literally any government service, I would say that it’s virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don’t know where they’re going to be accessing the web off of, right? The constraints we develop for are incredible, it’s really, really hard. It’s thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.
Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.
Jeremy: Or we have access to these layout modes now where we don’t really need. If we invest the time to learn these layout modes like grid, we don’t really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what’s great about that is with layout modes like CSS grid, if they’re abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what’s possible, I always like to point to Jen Simmons, her experimental layout lab homepage.
Jeremy: Kind of an ongoing thing that I’ve been doing since it came out is messing with the CSS paint API. I really like the paint API. I mean, it’s kind of always existed in its own…. like in its own way, since like the canvas 2D context has been a thing. Because that’s… for those who are unaware, the CSS pain API is a way in which you can embed a 2D canvas context and parameterize it and control it with CSS, which opens up a lot of really interesting possibilities, like you can animate things that you couldn’t previously animate and that type of thing.
Jeremy: And recently I’ve been doing a blog refresh. That is… I’m a huge Final Fantasy geek, like Final Fantasy II I just replayed and so, there’s like 15 of them and 16 is coming out sometime, but it’s kind of a retro field. So I’ve been using the CSS paint API to generate a random over world using different tiles. So there’s like rivers and stuff that like run through and grass tiles and trees and that type of thing. And parameterizing that so like if the user visits my website in dark mode… that paint work will be rendered as though it’s night. It’ll just have like kind of an overlay on it and that type of thing.
Jeremy: But the painting API is amazing. I got to give a shout out to Tim Holman. He, I saw him at JSConf Australia and he did a talk about generative artwork. That was really just, it really like got me interested. And then Sam Richard, in that at CSSConf the day before talked about the CSS painting API, when those two things came together for me, it was just like, “Wow, this is so cool.” And so I actually did a thing called Paintlets! It’s a Paintlets.Herokuapp.com if you visit and Chrome and you have to, unfortunately, because it’s not super well supported yet. You can see like a bunch of different, random artwork randomly generated artwork and.. yeah, I’ve just… that’s what I’ve been into, sorry. Long tale on that.
Drew: Amazing. That sounds great.
Jeremy: Yeah. Yeah.
Jeremy: Just go forward and build for the web the best way you can and try to keep the user in mind. That’s kind of my mantra and I’m hoping that this book makes that stick a little bit.
This content was originally published here.