Despite the growing abundance of bandwidth and computing power available from desktops to cell phones, putting attention on the performance of the code you write is still a worthwhile skill to cultivate that will help you avoid issues down the road. This week we’re getting our hands dirty looking into techniques that will help you identify issues that will impact your code’s performance so that your next project comes out as sleek as possible.
- A Lifehack for removing unused JS/CSS.. or just unminify
The following is a machine-generated transcript of this episode. It will contain errors until it has been reviewed and edited, and we apologize for the difficulty that may cause for screen readers. Do you want to help us speed up our transcribing process? Consider sponsoring an episode.
Well hello ladies and germs, this is The Drunken UX Podcast. I am your host, Michael Fienen. This is episode number 110 for March 14, 2022.
Did you say ladies and germs?
Ladies and germs. I know
are i Good? Evening?
So come back, listen to that. We’ll wait here or do it afterwards, whatever. But be sure to become one of our fantastic Patreon backers at drunken ux.com/support Join the group over there and give us a yell and say, Hey, this is what I’d like to hear. And we get that probably queued up very quickly for you.
Let’s see. Outside of that. Coffee,
lots of coffee second Coffee of the morning. I know not Irish coffee. Not.
No, it’s fine. So
I’m also medicated, I hopefully I’ll be more on point because I’ve just taken my medication so my brain will be
fresh and why and prickly, prickly brain.
Although I would say that, this is going to be definitely like more of your wheelhouse here. So I’ll just be asking a lot of questions.
Hey, I’m gonna teach you, we all have stuff to learn. And that is just all right. I just took a drink of my coffee. And for folks who’ve never seen me in the real meat space, I have a giant beard and mustache and it’s a whole thing. And I I said prickly brain. And when I when I popped that P I saw myself in the camera and coffee just sprayed. It is a problem. Oh my god, I gotta I gotta swallow that pee a little bit when I say it. Okay, let’s dive in.
Let’s Oh, sounds wrong, dude.
It’s everything. Sure. Yeah.
I mean, they they sent the they sent the Apollo 12 To the moon with like, 132 kilobytes or something, if something we can tiny. And I think that computing power has made us lowercase L lazy. I not in a bad way, but in a way that we don’t have to concern ourselves with things like memory allocation, and pointers and stuff that can all be handled, which lets us deal on a more abstract level. And I think that being able to deal at a more higher level of abstraction affords us more like latitude with the kinds of things we can do, which is really cool.
hand, there are a lot of ways and this goes to computing in general, not just web development, but this notion of Yeah, we don’t have to concern ourselves with XY and Z in order to make a functional product, whatever that product may be. And now I’m saying that not because I believe it, but because I think that is the prevailing sort of theory that is traded in different spaces. Why this is a problem, because it’s easy to say things like, oh, but you know, there are still people on very low power devices, or Oh, mobile devices, you know, that, you know, they’re on cell networks.
And all of this, and the counterpoint people are gonna say is, yeah, but even cell phones are getting wildly powerful, their battery life is ever increasing, network speeds are ever increasing. So it’s just going to catch up to the same point. So why Why worry about these things? To which I say, first and foremost, it is a matter of refinement, it is a matter of professionalism, and quality of product. Caring about those things, is what really differentiates, you know, a senior developer from a junior or associate developer, but more importantly, it’s how we prevent mistakes from happening.
You know, if you have no sense whatsoever of memory handling and garbage collection, and you’re just writing code and letting objects grow, and because of the way you’ve scoped it to the window and bound properties, that stuff never gets cleaned up, or garbage collected or anything like that. You risk introducing security vulnerabilities. Do you want bugs that take it bugs? Do you want bugs, that’s how you get ants. That’s really, I think the big problem is when you have badly optimized code, you create surface area for things like attacks, you create opportunity for problems, maybe not attacks, but ways for things to fail unexpectedly,
I actually started looking at specking out a new PC, which initially began as Hey, I wonder if I can get more RAM, which I can’t, because my motherboard only has two slots. And that started because Chrome was using up so many gigs of memory, that my system was running out of swap space. And to be fair, I usually have 40 to 60 tabs open. But in this particular case, I only had maybe 10, or 20, they just happened to be high memory usage. I think even with all this computing powder power we have, I’ve got a it’s like five years old as a core i Five, it’s a decent machine, it does fine.
probably some so look ahead, you know, some typing look ahead and stuff. And we’re gonna get into a little bit of this in this episode, in terms of things like event handlers, and how badly optimized event handlers can be a major problem for performance. And that’s one of those cases of like, you know, how we say all the time, you know, there’s, there are a million ways to build a house, and things like that. And it’s like, I can make code where people can write really terrible code that does exactly what it’s supposed to do, or
Stop hoarding your code.
Don’t tell me what to do, man. No, I’m
telling you, this is the thing. You need to stop hoarding code
to go look at my Documents folder on my computer.
So I know DHH is a comp as it has over the last one year and a half kind of become somewhat of a content reverse shell figure a little bit
DHH if you don’t know is the guy who he runs base camp and he is the inventor of Ruby on Rails.
They’ve been Heinemeier Hansson, he’s written a couple books, things like,
he has always been a controversial, it’s probably not far off. He was, he has a lot of hot takes, I’ll put it that way. Whether you agree with them or not, they’re hot takes and he has a lot of them. And he loves talking about them. And in the last year and a half, he’s he’s had some extra nuclear hot takes. And there’s one going on right now. And that’s episode isn’t about that. But I just wanted to acknowledge that we are both aware that presently, when this episode airs, there’s still stuff happening in that community handled delicately, that but but I think you and I both agree that sometimes your faith can be problematic. And sometimes artists in the art are a separate thing as
a separate the art from the artist moment. Because I think it’s one line, it’s a one line quote, like it’s very, very easy to fire it is the greatest tool for creating good software is the delete key.
And I think that’s great. I sometimes say it as read diffs, or best stuffs. Yeah. But I agree. So artists decide, I think this is good art right here.
it’s C++ that are in high school.
So in Dev Tools, there is a panel called the coverage panel now, and I said we’re going to have some stuff in Dev Tools, that kind of references. If you don’t know how to find the coverage panel, the easy way, it’s Ctrl, Shift P that’ll open up the command palette, just type in the word coverage.
If you’re not comfortable with that there are browser tools pages that you can just go to and put in a file and it’ll minify it for you. I will say, if you’ve never done a build process, creating one whose only job is to just minify a file is a great starting place because it’s very, very easy. So
I have a kind of a noobish question. Is there any difference in performance or execution of a minified. JS file versus a non minified file?
it’s it’s the same, right?
Yeah. minifying is all about saving space on the wire. Right? Okay. That’s what that’s all because, you know, when like, when things get parsed and stored to memory, they’re like, if you have a variable called my super long, very variable name, and then modifies the code. And when it modifies, it changes that to a, you know, like the word like a symbol or something, yeah, it will take it down to the shortest possible length string that it can do. But when the computer stores it into memory, it is stored as a memory reference. It’s not stored is just the letter A, and those memory references are all that however, you know, I don’t 16 bits long, 64 bits long.
So our build process strips all that out, which saves in some cases, those JS Doc’s are as long as the function is, you know, or longer or longer. Yeah, depending on what it is like there’s an Dincer, certainly a lot of the times, so like taking all of that out actually can be very meaningful, it also then makes the file easier to compress. Because most web servers are going to G zip that file. And the smaller minified file is going to crunch down better than that file full of whitespace full of all of those code comments that have no patterns, they aren’t the same. So like it gets, it is, it’s crunchy, or to then process down and encode. So there is actually a lot to be gained.
It also when when you work with smaller files, it reduces the amount of unorganized code you have, which isn’t necessarily a big deal for performance. But it can be a big deal to developer performance. By getting rid of all of that stuff, it’s now easier to find the things you need to find it’s easier to make sure the right stuff is grouped together or module together, things like that. So my advice minify smaller files, don’t overlook the importance of that. Okay, anyway, down the rabbit hole on that we go to the next topic is using targeted DOM manipulation.
And then when you need to bind your drop down functionality or whatever to it, use get element by ID don’t use query selector, don’t use query selector all. That’s one of those things. Most people will learn all of those right around the same time. And you might think that oh, well, query selector is super good, because like, I can pass anything to it, including an ID. Right? But it is less performant. And we’re talking milliseconds, you know, you’re probably looking at like, 20 milliseconds versus 39. Yeah, this is all about aggregate, right? If you’re using
it and using it in a listener, or if you’re using it in a function that runs frequently or is triggered frequently, and or it happens on a lot of elements, like that’s going to add up fast. Yes,
absolutely. Because DOM manipulation itself is a fairly expensive task, creating elements, passing them around those, like, creating a simple variable object, you know, with a couple properties, you know, A is true, and B is four and store that, that’s super cheap. That’s it’s so small, but storing an actual Create Element div with all of this stuff in it. That’s an expensive memory task to do.
Could we talk for just a moment about the different ways the different kinds of hooks you can create for doing queries? Because I think this is something that maybe like you and I like are just it’s like second nature to us, because we’ve been doing it so long. But this is definitely feels like something that could be not intuitive to someone newer. Sure. So there’s, there’s IDs, and like they, the robot ID is in this isn’t strictly enforced, like the page will still load. But you can create weird behaviors. But the rule is that on any given page load, an ID attribute should only appear once. Yeah.
And you won’t, you will fail HTML validation if you have two IDs on a page.
And yeah, so you could do a get elements by class name. Like, let’s say red, right? Like, right, get everything with the class red. And maybe that’s some links, maybe that’s some paragraph tags, whatever.
But then if you use the, what is it? It’s just, it’s just query selector, right? That’s the one that lets you do like a CSS query,
query selector, and query selector all will accept any valid CSS selector.
So you could do a dot read or dot read in those cases, right? Yeah. And then you can also do, you can do query selector looking for data attributes. And I’m actually I, I used this at work recently, I had a form that had a bunch of different kinds of divs on it. And some of them had an attribute called active and some of the had one called inactive. And I created some filter buttons that just grabbed the like, either active or inactive data attributes. And that way, the, there was no like collision with CSS. And but it was still like meaningful data. So there might might be others, those ones I can think of, though,
yeah, no, there, there are a couple others we’ll all throw out there that you can look at which, like one of them is get elements by tag name. So you could just say, get all a tags. You know, again, this is very similar to query selector all but it’s just limiting itself to a very particular part of the the DOM tree that way. And so it won’t crawl through the entire class lists. Because remember, that class list is really big. That’s why query selector and query selector all are really pretty inefficient overall.
And then you can get into all kinds of stuff about like child nodes and Create Element append element append child. So that’s sort of a great thing, though, because here’s what you do, right? If you’re doing a lot of this DOM manipulation, if you’re creating a web app, first and foremost, cache your damn elements. So what that means is don’t run those queries every time you need to do something. If you’re acting on an element all the time, get that element once and store it as a variable. So that you can reference that every time so you’re not rerunning the lookup every single time once it’s that once you’ve stored it,
that’s caching and scripts.
I mean, yeah, it’s I’m using it like that. Think of it like a lowercase c cache. It’s like, okay, you’ve stored it as a variable. As long as that reference stays active, it won’t be garbage collected, so it will stay there and be available to Gotcha. So instead like if I was running query selector all every single time to get all my links? Well, that’s super inefficient, right? We Yeah, we get back that’s a heavy lookup.
But if I’m getting all the links on the page, ver links equals document dot query selector all, you know, a dot link or whatever, or get elements by tag name a, then store that list as links. Now, every time you need it just reference links, because then it won’t rerun that lookup every single time. Right? So it’s, it’s a cached quote, unquote. If I
recall from a previous episode, I think it was the one we talked about CSS specificity. The Id like Id attributes are like the fastest, like, the best. Absolutely. Um, but I think from a practical standpoint, referencing everything by ID specifically makes the code harder to maintain, in my opinion. Because I mean, you have to, you then have to generate a unique ID for each element.
And also, it’s not don’t have to do it for each element, though. Each element that you’d want to Yes, strictly speaking, you only need to do it on the elements, you know, you want to act on. Sure. And if you are doing something that requires a lot, then it makes sense to not do the ID. So a good example, right? If you have a main nav with drop down menus that need particular functionality, it doesn’t make sense to give each one of those an ID and then recall all that,
you know, you want every a tag with a class or something like,
I’m not gonna, I’m not saying never use query selector and never use query selector all, just don’t use them, because you aren’t going to use other things that would be better for the use case. Right? Right. The other thing you can do is go into the Performance tab on dev tools. Now this, if you’ve never used this, this can be very daunting, the Performance tab, because it’s very complex looking. And it’s going to show you this big graph full of colors and stacks and labels of all kinds of things. But what it does is it’ll give you a little donut chart in the lower left corner that will show you layout, time render time, things like that.
And you can start to see like if you pull out the rendering pieces and start hovering over chunks of your code, you’ll start to see where layout shift happens. They’ll be highlighted in in the performance graph. And those are good examples of like looking at how your DOM manipulation is happening. And seeing like, is it all happening? Like in one nice clean block? Or is it happening like smeared across that timeline? Because that will affect things like your web vitals? You maybe have heard us refer to cumulative layout shift before? What is that this, this is a web vital one of Google’s like, you know, PageRank components type things.
And it’s exactly what it sounds like layout shift is when things move around your page. And cumulative layout shift is the amount of that that it does over the lifespan of a page load. And so ideally, you want to try to keep that very limited and consolidated. And you can see that happening in the Performance tab. So if you have a lot of DOM manipulation that happens on page load, this is a good way to see is it scattered and unfocused, or does it all happen in one nice, very clean, boom done type thing, because it measures layout shift as measured frame to frame.
And so doing it all at once, keeps it nice and clean and tight, and it spreads it over fewer frames, whereas if it happens, at 12 different points in the page load, you’ve got way more frames that it’s measuring against. And so that will count more highly against you. Because it’s things moving around a page, it makes the page hard to use this goes back to this. Like they’re trying to abstract UX into a metric. And the notion that things on a page move around think ads, right? Dynamically inserted ads that kind of try to trick you into clicking them by not being there, right. And they pop in to your way talking to hate that it’s that’s the kind of thing they’re trying to prevent. Exactly. So
so this is stuff that if I recall, this was episode 68. Where we talked about page performance. Probably we’re talking about Contentful paint and all that. Yeah,
yeah, okay. Doesn’t feel like that long ago, but maybe it was
it was a 2020 just look it up. Um,
let’s, let’s go to event handlers because this is another area where like, it’s it’s a singular kind of thing that can have a really big impact on the way your code performs.
This would be like onmouseover all that unload. Yeah.
make a make a very simple page, like literally just like a word of text, and put a put an event handler there to track the mouse move and snag the x&y coordinates and dump them to the console log, and then just move your mouse around on the page a few times, yeah, and watch your console, it’s pretty great. Wow, it’s a
ton. And so depending on what you’re doing, it’s one of those like, this is one of those areas where we said, like, you can make something that works exactly the way you want it to. But using these kinds of functions needlessly or in the wrong way, can cause that to be very inefficient, especially if there’s a lot of code bound to those functions, you can create a lot of lag, like very visible, you know, perceptive lag in things. If you do that,
And don’t just don’t use use this use a regular link tag, you get exactly the same behavior. And I, it just like, blew my mind that this happened. I know that there’s like sometimes like, you know, on submit or something, you want to have validations. And so you need to like capture the onsubmit event, and then run your validations. And then if it passes, then submit it, I get that, that’s fine. But if there is a default behavior in the document, go to that first, and then add the intervening things you need to in like inside of
it, I’ll jump down actually, because your point is a good one for something, I do have an in the notes here, which is passive event listeners. Now, this is not available for every single kind of event listener, but it is specifically available to any event listener dealing with like touch or wheel events. So you know, scroll or touchstart, or some of these, like these interactive behaviors. And what you can do is you can say passive true in the the configuration properties for your event listener. And it basically turns that event listener into a secondary thread. This is not the best way for me to describe this.
But so you know how there’s a thing called prevent default, right? So like, if you are using an a tag, and you’re using it improperly, you know, you’re using it to like act as a button, for instance, to open a modal or something like that, you might have prevent default on it, because you’re going to say, oh, but we’re going to open up a modal with it, or we’re going to cause a behavior to happen. So I don’t want you to actually go to the link, I, I’m going to determine what happens, right? So you would not set passive to true in that situation.
By setting passive to true, what you’re saying is, I promise that we are not going to override the default behavior of this thing, which means it will not block the browser’s default behavior. Okay, so what this means is like if you’ve got an anchor tag that goes halfway down the page, right, and you have an event listener on that link to do something to, you know, to, let’s say it’s just to track the the click, you know, it’s an inpage link, you want to know people it’s like a jump to top that’s a great one, right? Okay, to the top.
a lot of like, double entendre Oh, today,
we have the nav node, right, like, NAV is a node that exists in HTML, as our a tags, it is more performant. If you want to bind behavior to like a menu and like the links in the menu, it’s more performant to target the nav element that wraps your menu. And then when you fire that loop, just get the target that’s been clicked on, rather than binding it to every single a tag inside of it, you will reduce the number of event handlers in memory from, you know, 10 to one that way.
So you just you have reduced the memory footprint of that by targeting like if you’ve got a list, and you’ve got like, this is an app, and you’ve got some kind of like, maybe you can drag and drop the order of items in the list, you know, instead of binding to every loi, bind it to the UL, and then do e dot target and get the target element that’s been clicked on and then act on it. You right, you only need the one event handler because the parent wraps it. And so it’s gonna capture then whatever activity you’re trying to do,
I forget what I learned that but that was a really neat, like thing where you can assign an event listener to like a, like not at the body level, but like at a specific localized scope. And then it only listens to stuff directly underneath it. That was a real like, real revelation.
The other last item for event handling is to learn about debounce functions. And this is a really simple concept that I think, also can be very confusing. And I’ll try to explain it real simply. So we mentioned for instance, things like the scroll event happen a lot on a page, like when you’re scrolling, it’s constantly firing the scroll event.
And so that can be very, very bad for any event that’s bound to it. But have you seen like, let’s say a site that has like, maybe an animation behind the panel, and when you go to scroll, instead of the page scrolling? it animates something behind whatever’s happening, like maybe on Oh page or something like that, or, or it’ll snap to that very next panel, you know, even though you’ve told a little bit, what is that called?
Because I stopped doing CSS professionally around the time that that was becoming popular. And so I never learned how to do it. What does that call Well,
the ladder things like snap scrolling, that idea of like scroll jacking, you know, for like the purposes of animations and things like that, or infographics is, scroll jacking is the work that I know it by. But what you can do is you can debounce that function so that when somebody scrolls, you aren’t firing your animation events 1000 times. And all a debounce function is is it says, Hey, have you fired this event? Yes, you have, how long has it been? It’s been 800 milliseconds. That’s not long enough. We have to wait at least a second before we try to do this thing again.
There is another concept very similar called throttling And I’ll have an example of this to de Belson throttling are very similar, the main difference being that throttling, literally just make sure the event fires on a cadence. So every 500 milliseconds. So no matter what’s happening, it will run that event every half second, maybe it’s capturing the mouse position, you mentioned XY earlier, maybe you get in the xy position of the mouse to like, update the cursor look or something like that. Or to track that maybe your heat mapping something. And so you’re like, Well, you know, I want granular data.
There is a function, this is where I’m getting into like actual function stuff, there’s a function called Request Animation Frame, that if you use that, instead of something like a set timeout, then when somebody isn’t looking at it, the animation will be stopped on that tab, as long as they are looking at something else. This releases the CPU, there’s an article that will have in the shownotes, it says animations taking place in inactive tabs or stopped meaning if a user navigates away from your tab, and you have an animation that releases the stranglehold it has on the CPU, because of the better performance, battery life and paid responsiveness are better on low end devices and mobile browsers.
This is all about just how the browser in queues that animation and triggers it. It just makes it smarter, and therefore more performant. So cool, it’s yeah, it’s just like a little, little known function that is used for helping that along, rather than just writing your thing, because what a lot of people will do is to measure whether or not to run an animation, they’ll include a set timeout. And so if the animation hasn’t completed yet, then it’ll wait. But those set timeouts very much like event handlers, go into memory and sit there and sit there and sit there. Whereas request animation frame is very intelligent about knowing whether or not something is still going or not.
Do While for each, you know, map functions, all of this, especially if you have nested loops, which you should always try to avoid nested loops get very nested loops. And for anybody who’s done like algorithmic stuff, computer science stuff, nested loops, increase performance impacts exponentially as you add them in. So like that’s something you want to avoid that at all costs. You want to add these performance marks that will give you a good idea of how well those loops are running. Because loops are an area where you can get very heavy and do things like maybe you say, oh, you know what?
Whatever the dirty threshold is, the dirty threshold is like the, how fast does something have to be, so that it seems imperceptible to the user? Like it, it feels instant? Maybe you store that in your test, and you include those performance measures. So that when your Cypress test runs, it’s above the Doherty threshold, it’ll fail your test? Like, that’s cool. Yeah, like you can actually make this part of your process. So it’s not something you do manually, it’s not something you have to just remember, build it in that way. It’s kind of a neat, you know, high, you know, high level way of approaching these kind of problems.
We talked about using Cypress for testing in Episode 91. Yeah, with Jessica. Jason. Exactly.
If you open up your dev tools and go to that memory panel, you can turn on allocation sampling as the page loads, and record the memory usage over the course of that page. Okay, this is super handy for going in and seeing like, which functions are using up the most memory. So this kind of comes back to like, if you want to use those performance marks that I was talking about, you could target those functions that appear to be biggest with that, and see, why are they big, because keep in mind, just because it’s big doesn’t mean it’s bad.
I think it’s still cool that like, it’s kind of full circle. Like we’re, we’re back to being being concerned with, like memory allocation and stuff.
The other part of memory management is a feature called heap snap snapshots. Now, especially if you’ve done Java work, but I’m sure I don’t know. Is there something similar to this in Ruby? Aaron, like, is the heap something that comes up? Is that what do you mean? Does that a lexical reference that blank uses?
Possibly like, what what do you mean? So heap generally
refers to the pile of stuff, that heap of stuff in memory, right? Like all the references all, you know what’s going on? Java is very concerned with like memory usage. So like you’ll you will get heap snapshots of threads to see what everything is doing. If you’re debugging, like Java code, things like that. You can do a heap snapshot of all of the threads in the browser in a window in the memory area. Keeps snapshots are very Much like allocation sampling, except they are literal snapshots, they are a picture of a moment in time. You can do multiple heap snapshots. So you can do it, save it, reload the page, do it again.
And again, this entirely depends on your code, you can’t always delete every reference. But if you do have references that you don’t need anymore, and you’re trying to optimize that code, targeting things that have a high retain the size, could be very useful. So that’s my list of suggestions. Oh, it’s a lot. And like I say, this was a lot of like, technique stuff. And,
you know, is it is it, you know,
But I think even just as professionally, if you’re doing this as a job, like it’s a craft Yeah, like, there there is, artists and artistry behind like writing good code, and you should care that you’re not being wasteful or like using a lot of extra cruft when you don’t need to
be and it shows in the end product at the end of the day, like you know, a good metaphor Have you ever like been on YouTube or Tik Tok or something like that and seen like,
APE that sort of videos Yes. Very much video internet.
Have you ever seen somebody who is a professional drywall finisher?
Oh, I’ve seen seen professional like contractors and things including drywall including grout laying. It is so sad like to watch them work
what and I consider myself very good at drywall finishing my dad was a construction guy, I’ve I have done more mudding on walls and I could even count I’m good, I can produce a good finished piece of work. I’m a little slow at it. And my technique needs a lot of work.
And you watch some of these guys like they make their living doing it and it is nuts because a they’re they’re wicked fast. But the quality of their work in that amount of time is also so high and it’s like they could do it just like me they’re paid by the hour they could go slow and and get that but right there is a quality of craftsmanship there that really is apparent when you have honed those different techniques and this is just like that the walls still ends up painted in the end you still walk into the room and it feels the same in a lot of ways.
But that but they the the way they do it though like a really good drywall or the when they put the the mud on. A lot of times it looks like they don’t have to do any sanding at all. Yeah, like there’s just mud on the screw head or the nail head. And it’s like, awesome. It’s actually it was watching. I saw a video this morning of someone applying grout to a bathroom floor and there was no grout to be cleaned up. It was only going into the cracks and it was like a perfect little like white finish and Oh it’s beautiful. Yeah,
I’d be interested to know about, like, either within coding, like in what ways do you see like your work as, like an art, or artistry. And if not coding, like if you’re, they’re newer to coding, or that’s just not an important thing to you? What are the things that you care about to the level of artistry or like, artists and ship? I think that like, if you really care about doing something like you want to do it the best you can, and you want to learn these nuances and things that is kind of like requires extra effort to learn. And I always love hearing stories about the kind of stuff that people really get into, it’s really fascinating to see when you see
beautiful. Yeah, there’s
something about like, seeing like, some really incredible use of conventions and shorthand and all of that, like, that’s well formatted and structured like, you know it when you see it, and there is something very satisfying about that.
You can share with us on Twitter, or facebook.com/truckin, UX, or trucking ux.com/discord. And you can see occasional memes that we post about these sorts of things, instagram.com/truck and UX podcast. And last but not least, come help us make transcripts, you can support us for just a couple bucks a month, that would be fine. At trek, new x.com/support, which will redirect through to our Patreon.
You know, you’ve we’ve all been there where like one tab starts to crash on us. And it pulls your whole browser down, you know, like, these little things matter. And even though you are a developer writing code, you can directly impact the experience a user is having on your site like that is a power you have that as a superpower that is ingrained in you. And so, spinning this time isn’t necessarily just about oh, making clean code or or making fast code, because you are interfacing with that human being and you are having an impact on the way they use your site.
So by focusing on this stuff, by finding these tweaks, and these little like dials, you can turn to make your file a little smaller, make your function a little faster. It’s all keeping your personas close and your users closer. Bye bye