tag:world.hey.com,2005:/tannerhodges/feedTanner Hodges2021-11-29T04:21:00Ztag:world.hey.com,2005:World::Post/172352021-11-29T04:21:00Z2021-11-29T04:21:00Z#18 New Website + Newsletter<div class="trix-content">
<div>Last week I realized it was time to switch gears. Keeping this weekly “mini blog” for 3+ months has helped me gather my thoughts. Now it’s time to move into the next phase: work.<br><br></div><div>You can read the latest draft of <em>Catching Up With Web Performance</em> at <a href="https://catchingup.dev">https://catchingup.dev</a>.<br><br></div><div>For all future updates, I have a new, dedicated newsletter: <a href="https://buttondown.email/CatchingUpDev">https://buttondown.email/CatchingUpDev</a><br><br></div><div>What should you expect? A lot more nitty gritty details, experiments, and rabbit holes.<br><br></div><div>This next phase is going to get messy. Less philosophical, more technical. Less theory, more practice.<br><br></div><div>I’ll start with the world’s fastest website (an empty HTML file on your localhost) and work my way up to a full-blown application in the cloud, complete with 3rd party code and the works.<br><br></div><div>It’ll be a journey, for sure.<br><br></div><div>Follow along at:<br><br></div><ul><li><strong>Website</strong>: <a href="https://catchingup.dev">https://catchingup.dev</a></li><li><strong>Newsletter</strong>: <a href="https://buttondown.email/CatchingUpDev">https://buttondown.email/CatchingUpDev</a></li></ul><div><br>🙏 Thanks everyone for your support this far!</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/170912021-11-22T00:49:50Z2021-11-22T00:49:50Z#17 Cars, Pareto, and Performance<div class="trix-content">
<div><a href="https://www.howacarworks.com">How a Car Works</a> is an <em>incredible</em> resource—literally building an entire car from scratch, starting from the engine block.</div><div><br>And it’s amazing how often “performance” comes up.</div><div><br>Building a car, performance is constantly top-of-mind. How does the block’s material affect its fuel economy? How does vibration in the crankshaft affect RPM?</div><div><br>It’s all about precision.</div><div><br>When discussing <a href="https://www.howacarworks.com/video-course/watch/the-pistons">the pistons</a>, Alex Muir said something that reminded me of web performance:<br><br></div><blockquote>“About 60% of the engine’s power gets lost in friction from the piston assembly, so any improvements to that make a huge difference to the power output of an engine.”</blockquote><div><br>Compare that to Steve Souders’ <a href="https://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/">Performance Golden Rule</a>:<br><br></div><blockquote>“80–90% of the end-user response time is spent on the frontend. Start there.”</blockquote><div><br>Gotta love a good Pareto Principle when you see one!<br><br></div><div>I think this could be a really interesting angle to take teaching web performance: spotting the “pareto points”, those parts of the engine, or the parts of web design, that have a disproportionate impact on performance.<br><br></div><div>Really though, just the idea of breaking down a website and building it back up from scratch with the same level of rich detail and raw demonstration that <em>How a Car Works</em> shows would be so helpful—nothing detached or abstract, everything grounded in context as you build up the site.<br><br></div><div>I think this is where I want to go next: build a site from scratch and talk about each element of performance in rich, loving detail.<br><br></div><div>I’ve circled the philosophy of performance long enough, it’s time to get down to the metal.<br><br></div><div>Next up: the world’s fastest website…<br><br></div><div>—<br>P.S. Expect more car metaphors. I’m enjoying this series so much, I may just end up buying myself a junk car to tear apart in the backyard.</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/169522021-11-15T02:20:57Z2021-11-15T02:20:57Z#16 Looking for everyday problems<div class="trix-content">
<div>I’ve been getting back in the weeds of things, raw engineering instead of just theorizing. It feels good to get my hands dirty with code, feel the pain of everyday problems (“Why isn’t webpack working?” “How come my CSS won’t load?” “How am I supposed to…?”).<br><br></div><div>How do we talk about performance at this raw, everyday level? <br><br></div><div>Abstractions are inevitable—that’s literally what software is. But somehow I want to viscerally sense what’s going on. Not just metrics, not just theory, not just high-level patterns and code, no… Somewhere down here I want to understand physically what performance is, what it means, and how I should feel about it—how I can feel my way through it.<br><br></div><div>I want to learn about web performance the way people learn about cars.<br><br></div><div>What makes an engine start? How do I go fast? When I look under the hood and see all these parts and wires, where should I even start?<br><br></div><div>There’s a huge overlap between performance and general engineering. I mean, shoot, you can’t make a thing work well without understanding how it works first (at least, not on purpose). So on one hand, good performance is simply good engineering, but on the other hand it’s set apart. Performance is its own discipline, much like accessibility. It’s a specialized superset of knowledge and skills on top of those core competencies.<br><br></div><div>Does that mean performance should be left to the experts? Something we only teach in dev graduate school?<br><br></div><div>I’ve gotta believe performance can be a gateway too, a lens for developers to look through.<br><br></div><div>Maybe I just need to start something new myself to see that angle more clearly.<br><br></div><div>Guess it’s time I started learning about cars, huh?</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/167872021-11-08T04:13:42Z2021-11-08T04:41:16Z#15 Diagnostics and triage<div class="trix-content">
<div>Most of the time, <a href="https://en.wikipedia.org/wiki/Performance_tuning">performance tuning</a> is about fixing problems. The site was slow, the checkout was unavailable, etc.<br><br></div><div>Like a doctor trying to diagnose an illness, we jump into a situation with little context, searching for clues to what could be causing the problem.<br><br></div><div>Metrics are tests that help narrow down causes. “They have a high LCP? How about their TTFB? Maybe it was a slow server causing high response times…”<br><br></div><div>The more you know about how the human body works, the more quickly you can identify the issue, the better you can prescribe a solution.<br><br></div><div>But we also have to prioritize. Often times we have limited resources and need to triage issues, deciding which issues to tackle first and how far to take them—or whether a fix is even possible. “They have a high TTI? How about their TBT? If FID is still OK, let’s focus on LCP first because we know that’s causing breakage in the funnel.”<br><br></div><div>Metrics are only half the story.<br><br></div><div>They’re diagnostics, not prescriptions.<br><br></div><div>Every metric needs to be interpreted and judged in context.</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/166492021-11-01T05:19:00Z2021-11-01T05:20:27Z#14 Performance happens over time<div class="trix-content">
<div>Performance is an infinite game.<br><br></div><div>One of the most interesting aspects of performance to me lately is how <em>it doesn’t stop</em>. It goes on. It’s long. It’s historical.<br><br></div><div>Like, we’re keeping track of this now! (<a href="https://web.dev/chrome-ux-report-data-studio-dashboard/">Just look at those CrUX dashboards!</a>) And the time scale isn’t just day-over-day, or week-over-week. No, it’s month-over-month, pushing year-over-year. It’s even seasonal!<br><br></div><div>I think this is one of the most under-appreciated aspects of web performance—especially to developers working on it day-to-day. It’s so easy to forget the context we’re in. <em>Performance happens over time</em>.<br><br></div><div>One of my favorite web performance stories is from Pat Meenan, how every year at AOL they used to have “fire drills” at the the beginning of summer because their performance metrics would suddenly drop and they couldn’t figure out why. And every year they’d forget that it was just the school season, that students who had high-speed networks at school were coming home to much slower connections, and now all their page views were reporting much slower load times. All that stress! And it was just a natural shift. (<a href="https://vimeo.com/254728119#t=27m40s">Hear Pat tell the story at SmashingConf London 2018.</a>)<br><br></div><div>We talk a lot about immediate, short-term improvements (and granted, we have a <em>lot</em> of that work to do) but the biggest changes come from long-term trends.<br><br></div><div>What’s the “payback period” for performance? Which time scale are we on, which level of pace and size?*<br><br></div><div>I don’t want to get too philosophical, but I do think it’s worth remembering that performance happens over time, and to consider what time scale we’re on. What changes do you expect to see? How soon do you expect to see an impact?<br><br></div><div>Beware noisy signals:<br><br></div><blockquote>“Fast learners tend to track noisy signals too closely and to confuse themselves by making changes before the effects of previous actions are clear.” —James March (quoted in <em>The Clock of the Long Now</em>, by Stewart Brand)</blockquote><div><br>I think that’s where a lot of us are right now dealing with Lighthouse scores, stuck in “snapshot land”. We’ve barely scratched the surface with field data…<br><br></div><div>It’s a distant world to most developers, and a mind warp when they finally see it, but “histogram land” (I have no idea what else to call the world of field data yet) is a world we’ll need to live in sooner or later if we’re going to follow this path of performance—because the journey never ends.<br><br>—</div><div>*<a href="https://blog.longnow.org/02015/02/08/pace-layers-stewart-brand-paul-saffos-conversations-at-the-interval/"><em>Read/hear more about “Pace Layers” from The Long Now Foundation.</em></a></div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/165142021-10-25T00:48:21Z2021-10-25T00:48:21Z#13 Functional vs Non-Functional Requirements<div class="trix-content">
<div>When you say “Jump”, performance says “How high?”<br><br></div><div>It’s not just the thing you do, it’s how well you do it.<br><br></div><div><a href="https://en.wikipedia.org/wiki/Functional_requirement">Functional requirements</a> focus on <em>what</em> you do (your function) while <a href="https://en.wikipedia.org/wiki/Non-functional_requirement">non-functional requirements</a> focus on <em>how</em> you do it, on the <em>quality</em> of that thing you’re doing.<br><br></div><div>It’s a subtle but powerful shift in thinking:<br><br></div><ul><li>The car drives, but how fast, how far, how straight? Did it drive continuously or was it interrupted?</li><li>The plane flies, but for how long, how steady? Did it go where you wanted it to go or was it just “falling with style”?</li><li>The man speaks, but how clearly? How well was he understood?</li><li>The boy reads, but how much did he retain? (Shoutout to Brian Regan: “I took a speed reading course and my speed shot up to 43 pages a minute, but my comprehension plummeted.”)</li></ul><div><br>You can go on forever: the house shelters, the AC cools, the restaurant feeds, the doctor heals, the engineer codes, Netflix entertains, customer support responds, etc. And for every one of these you can ask “How…?”<br><br></div><div>The art of performance is going beyond the functional, thinking in non-functional terms—almost lateral thinking. “Yes, this works, but how <em>well</em>?”<br><br></div><div>Defining how well something works takes insight.<br><br></div><div>How do we gain that insight? Are there shortcuts, rules of thumb we can use? Or is it just a matter of experience?<br><br></div><div>My hope is that if we can build a clear mental model of the “rules” of performance, that insight will come naturally… we’ll see!</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/163732021-10-18T04:31:14Z2021-10-18T11:14:40Z#12 “Who did it better?”<div class="trix-content">
<div>How do you decide what to measure?<br><br></div><div>It’s a question I keep circling around.<br><br></div><div>Sure, we have metrics other smart people told us to use, but how should we use them? How do I know they matter to me in my situation right now? How do I know when they’re not enough?<br><br></div><div>A game I’ve started playing is “Who did it better?”—but for website functionality.<br><br></div><div>You can do this for anything: compare two basketball players, two cell phones, two boxes of cereal. It’s best when you compare a good vs bad example. Functionally, they do the same thing, but one is clearly better than the other. How? What makes that one better and the other worse? These are your criteria, your signs of quality. Measure them.<br><br></div><div>If both websites load, which loads better? If both websites search, which searches better? If both websites deliver custom flower arrangements, which one does it better?<br><br></div><div>The trick is talking about real examples out loud. As soon as you pit two real examples against each other, you intuitively construct a hierarchy of metrics—things you can use to rank a site’s performance. Talking about it out loud helps expose your priorities, and talking with someone else forces you to explain your thinking, to articulate which qualities are most important to you.<br><br>Use the “Who did it better?” game to help validate your metrics.<br><br>If your metrics aren’t telling you whether you’re getting better, define new ones that will.</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/162332021-10-11T02:26:41Z2021-10-11T02:26:41Z#11 Performance by proxy and metric trees<div class="trix-content">
<div>You’re trying to make something better.</div><div><br></div><div>How do you know it’s better?</div><div><br></div><div>At the core of every performance metric is a belief, a fundamental belief about what makes something good.</div><div><br></div><div>Some things are obvious—a vacuum cleans, a flashlight lights—but most things worth measuring are anything but obvious.</div><div><br></div><div>Most of the time what we want to measure is impossible to measure directly, so we measure indirectly instead. Most of the time we measure performance by proxy: schools measure graduation rates, hospitals measure length of stay, businesses measure revenue, etc. But what we really want are educated students, cured patients, and satisfied customers.</div><div><br>How do you know your metrics measure what you want them to?</div><div><br></div><div>Metrics come in trees.<br><br>When you can't measure what you want directly, you start with a goal, an outcome, an end (the top of the tree) and work your way back through the branches of causes and effects (a story!) to sift out things you <em>can</em> measure (the leaves of the tree).</div><div><br>The end goal, the <em>lagging indicator</em>, branches out into clusters of other metrics, all hanging off each other like chains of cause and effect. The further down the tree you go, the more <em>leading indicators</em> you find—things that help signal success early on. But beware: the further away you get from the trunk, the less reliable those indicators become.</div><div><br>Every metric is a theory, a hypothesis that needs to be tested and validated by something else.</div><div><br>“Does <em>this</em> make <em>that</em> better?”</div><div><br></div><div>Does site speed improve customer satisfaction? Does customer satisfaction improve sales? At the end of the day, it often takes a judgement call—a belief in cause and effect—to decide which metrics matter most, and then data to back them up.<br><br>Proxy metrics require a separate, ultimate goal to ground them in reality.</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/160202021-10-04T03:45:24Z2021-10-04T04:00:01Z#10 Good metrics tell stories<div class="trix-content">
<div>Good metrics have <em>causality</em>. They tell stories. They say “if this then that”. They clearly measure progress towards a specific goal: run fast win race, study hard pass test, save money buy house, etc.<br><br></div><div>Goals say where you want to go. Strategies say how you plan to get there. Metrics measure your progress, and objectives are like checkpoints along the way.<br><br></div><div>Metrics need stories to stay grounded.<br><br></div><div>It’s easy to get lost in metrics, especially when they get more attention than goals. But every so often we need that reminder: What are we measuring? Why are we measuring it? How much is good enough?<br><br></div><div>When in doubt, follow your users’ stories.<br><br></div><div>Here’s an example from this weekend: I need a new shelving unit for my closet, so I go to lowes.com and search “closet kit”. I don’t know which item to choose so I click on the “closet configurator” app. I fill out my room specs and click through the designs, then select one and add it to my cart. I go back and forth searching for nearby stores with enough parts in stock so I can schedule the fewest number of pickups as soon as possible (and not have to wait on additional shipping). I place multiple orders and wait for each store’s email notification that my parts are ready. In one round trip, I go to each store and use curbside pickup to collect my purchases.<br><br></div><div>There’s a lot to measure here!<br><br></div><div>But how do we decide?<br><br></div><div>Often times it’s easier to define metrics by working <em>backwards</em> from a goal.<br><br></div><div>Just spitballing, let’s say we’re Lowe’s and our goal is to enable customers to have stress-free, same-day purchase & pickup for DIY home improvement projects. We do this by providing product search, a room design tool, in-store availability, and curbside pickup. Our most important metrics are the realtime accuracy of product availability and the response time for curbside pickup.<br><br></div><div>Obviously, there are other metrics you could (and perhaps should) focus on. We completely left out things like speed of search, or the room design tool’s ease-of-use, or the number of times a user had to modify their order before feeling comfortable clicking submit.<br><br></div><div>The important thing is that your metrics have a clear tie-in back to your main goal: if this then that.<br><br></div><div>Look for metrics that tell a story.</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/158682021-09-27T02:36:31Z2021-10-04T00:03:21Z#9 What’s on your dashboard?<div class="trix-content">
<div>When you’re driving, what information do you keep in front of you?<br><br></div><div>What’s so important that you’d put it on your dashboard?<br><br></div><div>“I need to know X, Y, and Z.”<br><br></div><div>In the car, you definitely want to know your speed, and you want to know how much gas you have left.<br><br>What else?</div><div><br>There’s other information you need access to (like the volume of the radio, or your AC temperature) but they’re not critical—you don’t need them at a glance, just within reach.<br><br></div><div>What about your website? What information do you need at a glance? Speed? Hm… What would be your site’s “gas” gauge?<br><br></div><div>We talk a lot about site speed—what about site <em>fuel</em>?<br><br></div><div>What’s the thing that keeps your site going?<br><br></div><div>As we think about what metrics matter most for web performance, the dashboard is an interesting way to frame the question: You need something to keep going, what is it? Then go from there… (You can even consider scale: Are we driving a car, or a commercial airliner? We may need a bigger dashboard!)<br><br></div><div>Once we’ve decided how to measure fuel, then we can revisit speed: speed of what? Is load time the speed that matters most, or is it speed of search, chat, payment—or is it speed at all? Is it accuracy, precision, or something else?<br><br></div><div>Building your site dashboard can be a helpful, visual exercise in determining performance metrics. (Almost like test-driven performance! Now there’s an idea…)</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/157152021-09-19T23:38:57Z2021-10-03T23:59:06Z#8 Winning the next game<div class="trix-content">
<div>Why don’t we just use the same metrics for every website, every business?<br><br></div><div>The answer sounds obvious when you first ask—“Because they’re different, duh!”—but that’s an awfully hollow answer. Fundamental questions like this deserve more attention.<br><br></div><div>If every business needs money to survive, why not just measure all businesses by the money they make and call it a day? That would be simpler, right? If that’s all businesses did (making money) then sure, I’d say yeah, that’s true. But that money comes from somewhere—a whole bunch of different places, actually. Every business gets money in a different way (and spends it, invests it, etc.).<br><br></div><div>Look at it another way: if businesses were like running (the sport—and I apologize in advance to all my runner friends out there) you could just measure how fast people run and that’d be enough. But business is more complex—it’s more like football than running. Sure, football players run (read: American football) but they also tackle, dodge, catch, throw, huddle, kick, coordinate, strategize, defend, and score to win a game. There are more functions to measure, more moving parts, more types of performance. It’s not just about how fast players run, it’s how well the whole team works together to outscore their opponents.<br><br></div><div>“But Tanner, why not just measure win-loss records for football teams?”<br><br></div><div>Good point… I suppose whether you’re talking about business, running, or football, you could always just pick one metric and say, “This is the only thing that matters!”<br><br></div><div>So why care about anything else?<br><br></div><div>Because we want to know whether we’ll win the <em>next</em> game.<br><br></div><div>We want to know whether we’ll keep winning. And if not, then what should we improve? What do we need to do to win next time?<br><br></div><div>Win-loss records and quarterly earnings don’t tell you whether you’re going to win next time (let alone <em>how</em> to win). They’re measures of progress, sure, but they’re not performance <em>indicators</em>—they don’t predict future success.<br><br></div><div>Performance drivers, performance indicators, help you prepare for the next game, the next race, the next customer.<br><br></div><div>“How did we do the last time around?” We made money, great, but was the customer satisfied? Will they come back? If we didn’t make money, why not? Did the customer cancel? Why did they abandon their cart?<br><br></div><div>One data point won’t do. We need a story to answer these questions. We need judgement and decision-making. We need strategy.<br><br></div><div>That’s where I’m at now with performance: how do you decide what to pay attention to, what to measure, what to prioritize and improve? It all depends on goals and strategy—but <em>strategy</em> is so misunderstood. Every optimization has consequences. How do you know which ones are worth it?<br><br></div><div>Past results don’t predict future results. We need a guiding policy, a strategy, something to help define our key performance indicators—the drivers that lead to success.<br><br></div><div>If web performance is how well your website provides value to people, then <em>optimizing</em> performance means focusing on the features that matter most.</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/155742021-09-12T23:50:25Z2021-10-03T23:56:31Z#7 Core Restaurant Vitals, and other analogies<div class="trix-content">
<div>What if we translated <a href="https://web.dev/vitals/#core-web-vitals">Core Web Vitals</a> to the restaurant world? What would those metrics look like?<br><br>Here’s my first stab at it:<br><br></div><ul><li><strong>Time To Menu</strong>: From the moment a customer walks in to the time they can read the menu.</li><li><strong>First Waiter Delay</strong>: The delay between a customer trying to and actually getting a waiter’s attention.</li><li><strong>Cumulative Table Wobbles</strong>: How much a customer’s table wobbles during their visit.</li></ul><div><br>Looking at these metrics in a different context, like a restaurant, adds a fresh perspective (at least for me) for web vitals. I feel like I have a lot more intuitive sense of the value of each metric, how they interact with each other, and what I’m missing when I focus on just them.<br><br>For example, I immediately ask, “What kind of restaurant is this? Is it a sit down restaurant or a fast food joint?” And the questions go from there: How important is the menu? How fast can I cook and serve the food? Is it any good? Would a different process help? What do my customers really care about? Etc.<br><br>Web vitals are similar: they’re a great gut check on the health of my website, but they’re specifically designed to be simple—they don’t tell me how valuable my content is or how happy people really are with my product. I need to dig deeper for those answers.<br><br><em>Vitals don’t prove you’re alive, they just say you’re not dead.<br></em><br></div><div>But back to restaurants, it’s interesting: if I focus on, say, Time To Menu, I can come up with clever ways to improve that metric, like posting a “critical menu” on the front door of my restaurant. But if it still takes people forever to actually place their order and get their food, what good does it do them?<br><br></div><div>And so with First Waiter Delay: if my waiters are hyper-attentive and responding immediately to every customer response, but my kitchen is consistently slow, churning out poor quality food that needs to be taken back, how much am I really improving my customer’s experience?<br><br></div><div>(Everybody should fix their wobbly tables, by the way, because they’re just the worst. Please and thank you!)<br><br></div><div>Vitals are important, but let’s be careful not to miss the forest for the trees. Translating metrics to other contexts can help regain that sense of perspective.<br><br></div><div>What are some other analogies you use for web performance?<br><br></div><div>—<br>P.S. Here’s a first stab at “Core Car Vitals”: Time To Ignition, First Acceleration Delay, Cumulative Bounces and Vibration. What else?</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/154212021-09-06T02:38:47Z2021-10-03T23:54:27Z#6 Measure what matters most<div class="trix-content">
<div>Why “vitals”?<br><br>Why measure heart rate when what really matters is winning the race? After all, vitals don’t prove you’re alive, they just say you’re not dead.<br><br>How do you measure success? In a perfect world, if you could measure anything, how would you measure your performance?<br><br>Often times, we can’t measure exactly the thing we want. Take this blog post for example: I’d like to know whether it makes a difference to anyone, if it helps them understand performance better. I don’t have access to the people reading this, let alone a way to read their minds and check, “Yep, they learned something!” If I had analytics running, I could check the number of pageviews, time spent on site, scroll distance, clicks, etc. But even then, none of that would tell me what I really want to know. At best, it would suggest “engagement”—but engagement is just a proxy. The simplest, most direct metric for what I really want to know is comments: people responding to the post and saying, “Hey, thanks for sharing! I never thought about that before. It was really helpful.” Another decent metric would be number of new subscribers. More people want to read, so I must be doing something good, right?<br><br>But are comments and new subscribers the best metrics for every blog? Maybe. Maybe not. They’re not “vital”, but they do tell me, for my blog, whether I’m actually doing a good job.<br><br>This is the art of performance: knowing how to define, measure, and improve what matters most to you and your business.<br><br>As I analyze the strategy of my business, I can pick apart the different actions I perform and the requirements that support it. Layer by layer, I can step down until I reach the core vitals—the fundamental qualities every business needs (at least in some degree) to survive: How do I teach people? They learn by reading my blog. How do they read my blog? The web page loads in their browser. If that web page doesn’t load, people don’t learn. And that’s that. It’s like breathing.<br><br>Vitals are a baseline. They’re fundamental. They’re something everybody needs. Whether your job is in sports, education, government, software, finance—it doesn’t matter—you’re dead if your heart stops pumping. You need to keep breathing… but that’s not what matters most.<br><br>Breathing may be vital, but it’s not your main job.<br><br>Keep an eye on your vitals, but focus on the real target: how well you provide value to people.<br><br>After all, it’s not the breathing that matters most. It’s what you do with it.</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/152312021-08-30T04:46:34Z2021-08-30T04:46:34Z#5 Metrics, rewards, and success<div class="trix-content">
<div>Lately I’ve been thinking about what web performance measures, what it could measure, what it should measure…<br><br></div><div>Why load time metrics?<br><br></div><div>Well, for one, that’s all websites used to do! But since then, the Web has grown to do so much more.<br><br></div><div>Are we stuck in the past?<br><br></div><div>I don’t think so. There’s plenty of discussion—especially with Core Web Vitals—about whether we’re measuring the right things, and what we should be measuring instead. This is good! Take Philip Tellis’s recent post about <a href="https://tech.bluesmoon.info/2021/08/the-metrics-game.html">The metrics game</a>:<br><br></div><blockquote>In my opinion, [CrUX] should also include measures like rage clicks, missed, and dead clicks, jank while scrolling, CPU busy-ness, battery drain, etc. Metrics that only come into play while a user is interacting with the site, and that affect or reflect how frustrating the experience may be.</blockquote><div><br>We’ve only scratched the surface.<br><br></div><div>At the same time, how do we avoid “metric burnout”? After all, that was one of the big problems Core Web Vitals set out to solve: to simplify the metric landscape. “What should I pay attention to?”<br><br></div><div>The Web is only getting more complex. What should our message be to developers facing that ever-growing complexity? More metrics? More tools? Or…?<br><br></div><div>Separately, when people are gaming metrics, how do we shift the game so it actually helps people? How can we turn “private vices into public benefits”?<br><br></div><div>We run the risk of “teaching to the test”, training developers to optimize without understanding. How do we teach performance beyond metrics and rewards? To recognize a website’s true factors for success?<br><br></div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/150502021-08-23T00:32:20Z2021-08-23T00:32:20Z#4 The scale, power, and future of the Web<div class="trix-content">
<div>The scale and power of the Web today is mind boggling. The number of things you can do with it is, in theory, only limited by the number of things the devices connected to it can do. And today’s technology can do, well, almost anything. (Just imagine the technology of tomorrow!)</div><div><br></div><div>Someone makes something, puts it on the Web, and all of a sudden it’s available to everyone, everywhere. That’s the power of the Web.</div><div><br></div><div>As a discipline, web performance ought to be able to measure all those things—all the things that web technology can do. At the least, it should be able to speak to them, to give guidance and equip developers to measure and improve the quality and value they provide.</div><div><br></div><div>How should the KPIs of a progressive web app compare to those of an ebook, or an online game? What about real-time collaboration tools, or voice assistants? What about wearables, robotics, cars, and smart cities? The technologies keep expanding. What metrics should we recommend? What best practices?</div><div><br></div><div>Where will web performance be in 50 years?</div><div><br></div><div>We’ve only scratched the surface.</div><div><br></div><div>I hope the Web survives that long. Really, I hope the Web stays relevant that long. Will it? Who knows. Assuming it does, what will web performance have to offer?</div><div><br></div><div>Will we still be measuring load time?</div><div><br></div><div>Or will we have stretched our skills, our field of vision, to match the task ahead?</div><div><br></div><div>—</div><div>P.S. For more Web inspiration, read Alex Russell’s <a href="https://infrequently.org/2020/06/platform-adjacency-theory/">Platform Adjacency Theory</a> and <a href="https://infrequently.org/2021/07/the-core-web-loop/">The Core Web Platform Loop</a>.</div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/149052021-08-17T03:54:59Z2021-08-17T12:01:11Z#3 What does the Web do?<div class="trix-content">
<div>Well, it’s a global information system. It exchanges information between people. It connects people. It’s a communications system. It is “the universe of network-accessible information, the embodiment of human knowledge”. <a href="https://www.w3.org/WWW/">https://www.w3.org/WWW/</a></div><div><br></div><div>“The social value of the Web is that it enables human communication, commerce, and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.” <a href="https://www.w3.org/Consortium/mission">https://www.w3.org/Consortium/mission</a></div><div><br>The W3C’s goals sum it up: Web for all, Web on everything, Web for rich interactions.<br><br>In other words, help everyone everywhere do all the things.</div><div><br>Apart from the raw technical details, the Web is all about being “universal”: I can access this thing, do this thing, anywhere on any device.<br><br>The goal of the Web is to provide universal access to information technology.<br><br>Technology helps people do stuff. Information technology manipulates data. The Web links data and services across technology, making them accessible to as many people, in as many contexts, as possible.<br><br>Another way to think about it: What can we do with data? How can we use technology? How can we connect those things together? That’s the Web.<br><br>The goal of the Web is to connect and enable.<br><br>So web performance boils down to how well Web-enabled technology works. Can it be accessed? Can it be used? <br><br></div><div>The trick is figuring out how to measure those things. Access is relatively straightforward (e.g., page load time) but use is not. You can compare page load times across websites, but what about usability? How do you compare the use of an online magazine, to a banking app, to a fitness tracker, to a video chat service, to food delivery systems, to blogging platforms, to e-commerce, etc.?<br><br>But that’s where the heart of web performance is: how well the Web supports the things we're trying to use it for.<br><br>What does the Web do for <em>you?</em></div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/146842021-08-09T00:28:11Z2021-08-09T00:28:11Z#2 Activity-based vs Subject-based performance<div class="trix-content">
<div>Kinds of performance describe either the things you’re trying to do well (the activities) or the thing you’re trying to make better (the subject).<br><br>You can measure “financial performance” (how well you do financial things) or “business performance” (how well your business works).<br><br>The interesting thing about subject-based performance (as opposed to activity-based performance) is that it can can basically include anything that has to do with your subject. Any action the subject performs, or anything that contributes to the quality of those actions, is fair game as a metric for the subject’s overall performance. You can correlate almost any property of a subject to its performance—which is kind of wild.<br><br>In other words, I could measure “fruit performance” if I really wanted to. What does fruit do? It’s consumed, it’s eaten, it nourishes—but it also scents and flavors, it grows, it sells. Depending on who you are (consumer, customer, or supplier) your view of “fruit performance” will be completely different—whether you care about its taste, nutrition, cost, or sales. To form a holistic measure of fruit performance, I could take key performance indicators from each of those viewpoints and group them together to create a kind of “balanced fruit scorecard”.<br><br>Subject-based performance is cross-disciplinary. It groups together other lower level activity-based kinds of performance to describe how well a thing works.<br><br>So web performance… does that include anything the Web does? Any action the Web supports?<br><br>Yep. Yes it does.<br><br>The only question then is how many metrics we’ll all share together—what common standards for web performance we’ll come up with. But how interoperable can those metrics be? What things do all websites do? And on all devices? Will we form lower level branches of web performance for specific devices and kinds of applications? Only time will tell.<br><br>In the meantime, the most interesting web performance metrics are the ones most unique, most specific to your subject—to your website. What exactly does your website do? How do you measure that?</div><div><br>—<br>P.S. Now that I’ve written and re-read this, I’m thinking that actually “measurement-based performance” may be more accurate than “activity-based performance”. Thinking through a list of different kinds of performance (academic, athletic, economic, mechanical, physical, technical) I think those “kinds” actually describe the type of metrics more than they describe the type of activities. Financial performance focuses on financial metrics more than financial activities, right? Hm… Food for thought!<br><br></div>
</div>
Tanner Hodgestannerhodges@hey.comtag:world.hey.com,2005:World::Post/144862021-08-02T01:58:19Z2021-08-08T23:06:25Z#1 Kinds of performance<div class="trix-content">
<div>What is “performance”?</div><div><br></div><div>And what about performance makes it “web performance”?</div><div><br></div><div>Because performance comes in kinds. At the very least, we’ve had business performance and economic performance since long before we had the Web.</div><div><br></div><div>Even if you focus on a single object, you can measure all sorts of different performance for it.</div><div><br></div><div>For example, a car can have mechanical performance, economic performance, social performance—all different ways of looking at the same object, but each measuring how well it performs a different job. Depending on which lens you look through, you get a different definition of performance. How fast does it drive? How much money does it save me on gas? How well does it reflect my personality? Etc.</div><div><br></div><div>How many ways can you look at a website?</div><div><br></div><div>Up until Core Web Vitals, I basically thought of web performance as “site speed”: how fast does your web page load? How long does it take to render? To respond? But now that our industry is looking beyond load time metrics, introducing completely new non-time metrics—things like “stability” and “smoothness”—I can’t help but wonder…</div><div><br></div><div>What else should go under the “web performance” umbrella? Privacy? Security? Accessibility? Should bounce rate and conversion rate belong there too?</div><div><br></div><div>What is “web performance” exactly? And how is it different from other kinds of performance?</div><div><br></div><div>If performance is how well something works, what jobs does the Web do?</div><div><br></div><div>What jobs should “web performance” measure?</div><div><br></div><div>…and where should it stop?</div>
</div>
Tanner Hodgestannerhodges@hey.com