The Alphabet Soup of Performance Measurements - JSJ 622

Well, hello folks, and welcome back. It's a bright, beautiful day and even more bright sooe and beautiful so because of Dan Shapiir, who's going to be telling us a little bit about Oh gosh, we've got six acronyms in a row here, Dan, what's what's our topic in summary? Yeah, I called it the web performance alphabet soup. Don't worry. I'll get into all the various acronyms during the show. But yeah, stuff like FCP

and TTFB and and etc. Whatnot. All right, for those of you following along at home, those are all letters in the alphabet, all right. Also on the show, we've got Amy Knight Hello. Oh my gosh. Yeah, so don't have primnavirus, but have something so Hello from Nashville. Don't listen too closely you might catch it. And also Steve Edwards Hello, Hello from sunny Portland. And with that, this is JavaScript jemmer By

start. Hey, folks, this is Charles Maxwell. I've been talking to ahole bunch of people that want to update the resume and find a better job, and I figure, well, why not just share my resume? So you if you go to topendevs dot com slash resume, enter your name and email address. Then you'll get a copy of the resume that I use that I've used through freelancing through most of my career, as I've kind of refined it and tweaked it to get me the jobs that I want. Like I

said, topendevs dot com slash resume. We'll get you that, and you can just kind of use the formatting. It comes in word and pages formats and you can just fill it in from there. All right, Dan, I think that means you're on. Yeah, I guess so. So today we're going to talk about a topic that's really near and dear to my heart, which is web performance and a whole bunch of acronyms and metrics and measurements

that are associated with it. As some of our listeners may recall, my day job is a performance declely at Wicks, where I deal with the performance of millions of websites hosted on the WIGS platform. Literally billions of websites, even more hundreds of millions, I don't know. Anyway, this means that I'm constantly involved with how to best monitor and optimize performance on the web.

That's like what I do day in day out and today I wanted to talk about performance monitoring, specifically about the alphabet soup, which is web performance measurements and metrics. I mean we mentioned a few, I'll mention them again. I mean metrics such as TTFB, FCP, LCP, TTI, TBT, and et cetera. Lots and lots and lots of acronyms. Now when one algorithm do you have TTFN for now? From here? Yeah? Wtf?

I guess as well. Anyway, Yeah, I got to say, like maybe start us off, so I know that not everybody knows about like the changes from light how the six five? Would that be a good starting point to kind of like frame our conversation. I actually wanted to start a little bit back in front of that because I really wanted to talk about what performance measurement really is and why it's important because we get to a specific measurement tool,

which is Google Lighthouse. But yeah, once we get to there, that's definitely an interesting topic of conversation. So I found that, like I said, that many web developers are actually not familiar with the various performance metrics, are confused by them. They're not sure what metrics, what the metrics mean, which metrics are the most relevant for the particular use case. In

fact, it's even worse than that. I have a talk that they give which is titled my website is slow Now what, which is essentially a laundry list of action items that you can take to improve the performance of a website or a web ap And essentially the first item on this list is to measure and monitor. And you'd be surprised by how many web developers or companies or teams or whatever neglect to measure and monitors performance at all of the websites that

they build, let alone do it on a regular basis. So you know, we're going to be talking about all these metrics and measurements, but the most important thing that you actually do it, regardless of which ones you ultimately choose and which tools you ultimately use. There's a quote that's attributed to a well known management consultant by the name of Peter Drucker, which I actually like, which is, if you can't measure it, you can't improve it.

And I definitely think that measuring in monitoring performance is a prerequisite for being able to actually improve it. Otherwise there's a very good chance that you'll waste time and effort on changes that provide very little benefit, and you'll totally neglect significant possible gains. So folks, please please please measure the performance of the websites that you build. So okay, So let's say I convinced you hopefully I

have how do you actually do that? So it turns out that there are really two main ways to measure performance if I put them in like in categories or buckets. One is known as synthetic monitoring, and the other one is known as real user monitoring, which is also has an acronym, which is rum rum. Synthetic monitoring is about monitoring the performance of a website in a quote unquote laboratory environment. Often it involves some sort of automation tooling, but

you can really just do it manually yourself. You create some sort of a synthetic environment that simulates typical user scenarios or maybe the worst case user scenarios, depends on you, and then you measure the performance of your website in those

environments. So say, for example, you know that a lot of your users are using mobile devices that say Android, and they're coming from let's say, Okay networks, So you might use some Android device on a four G network or maybe a fast feed GIN network to try to measure the performance of

your website. If you want to also account for the users who have lower end devices and networks, then maybe you'll buy some cheap low end mobile device for one hundred bucks and then connected via like three G and try to measure your performance on that, and you can also simulate those environments these days, then something like the Chrome debv tools actually lets you specify both a CPU slow down and the network slow down, so you can actually even do that on

your computer. But you need to do that. So, like I said, there are many options and tools out there for synthetic monitoring, but Google Lighthouse has become something of a standard. In fact, you can run it directly from within the Chrome debv tools in the audit stab, so you literally have it built into your browser. You can also integrate it into your release process using something called Lighthouse CI, which is an open source project by Google.

Lighthouse itself is an open source project, or you can use it online using sites like Google Paid speed Insights, which also has an API which you can connect to do it as part of your build process. As I said before, I highly recommend incorporating some sort of synthetic monitoring into your CI process if you're building any sort of a website that you hope will see some production

traffic. This will enable you to specify stuff like performance budgets, which are just a fancy term for limits on various performance related aspects of your project,

for example, the total size of the JavaScript that you download. So you can say I have a performance budget that my total JavaScript download doesn't exceed say one hundred kilobytes of or the wire and then if you actually exceed that, then your build brakes and you need to make hard decisions of whether to remove some functional JavaScript and maybe some functionality, or maybe to increase your limit, knowing that it will have an adverse impact on the performance that your users experience.

Any questions about synthetic monitoring before I move to real user measurements, have you guys played around with various tools like that. I'm definitely familiar with the stuff that's in Chrome, and it is so refreshing when you try to tell someone, hey, your site's slow, and they're like, no, it's not, and you're like, well, even if I just simulate a poor

connection, it's terrible. So that's kind of what I've used those tools for quite a bit, is letting other people know and like, no, really, like, here's how you can see for yourself that when you're not on Viber Ethernet, it doesn't work that well. And then Lighthouse is something I'm fairly familiar with, though I don't know when I've looked at it, I've

often been confused about how to take full advantage of it. Okay, that's hopefully something I'll have enough time to cover this episode, or if not, we can do a continuation one. Okay, So in any event, like I said, the other bucket or method of performance monitoring is real user monitoring

or RUM, which measures the performance of pages in real live sessions. So you add some code, you instrument your code so that it actually measures and reports back performance of actual user interactions, and you collect this information into some sort of a database that you can then run queries over. If you recall my previous JavaScript Jabber episode where I spoke about this stuff, that was episode three three four, I spoke about the Web Performance API. That's actually how

most RUM measurement tool these days gather all the information that they do. You can do it yourself, or you can get a third party tool that will do it for you. Interestingly, Google is actually now also exposing rum data themselves, at least from sessions that run on Chrome. There's this thing called the Chrome User Experience Report or CROCS for short, which collects performance information from Chrome itself. When you install Chrome, you have this option to opt out

of Google gathering information to improve their service. If you don't, then it turns out that they also gather anonymous performance information about all you know, your browsing, and they put this information into a database that's actually open to anybody to query. If you run big queries on it, it might cost you a bit, but you know, anybody can do it. There are actually

even tools out there that give you free access to this information. So, for example, there's this free CRUs run service by a company called Edgemash which provides access to this information. Also in the Chrome search console itself, they actually now have performance information from there, and Google Page Speed Insights also shows

you information that it retrieves from that from that database. So Google Page with insights now shows you both information from the synthetic tests that it performs and from real user sessions Now there's a caveat with that because first of all, crocs Google kind of updates it one month back, so you can do queries on data for your sessions, but if you make changes, you'll also you'll only

see the impact of those changes like a month later. And likewise, guys, they only actually maintain information about sites that have or pages that have sufficient traffic. So if you're like putting up a new page, you might not actually get any data for that from crocs because it's just not getting enough traffic yet. Be that as it may, there are many many third party services out there that you can add to your site. Obviously they cost some money,

but they can provide a lot of benefit. And I'm not going to advertise any one of them. You just you know, Google search for Web performance monitoring and many such services will come up. So that's that's RUM data. Have you actually have you guys actually used Rum in any of your project I can tell you that we at wigs use RUM like a ton. We are very data driven company, but we're kind of you know, huge. I'm wondering if you guys had the chance to use stuff like that, wean

don't. Unfortunately, the use it where we are I want to though, Yeah, I highly recommend it because at the end of the day, if you're just doing synthetic measurements, then you're kind of guessing what your users are experiencing. Like I said to begin with, I would highly recommend for you

to use something like crucks run to look at your current situation. Like I said, it's a month late, but it's better than nothing, and you can actually look at how your performance in the field changed over the past six months. I believe in that using that tool, so it's actually quite informative. I'm looking at it right now for my blog and I'm not sure what to make sense of all the numbers, but it's cool to see them,

that's for sure. Well, they mostly show you I'll get to what that means, but they show you stuff like your TTFB and FCP and the DCL. I'll get to that hopefully in a bit. One thing that I see here is that it looks like there can be quite a variation in where things are falling in these different composite sidebar So I'm not sure what to call this type of graph. It's almost like a pie chart, but it's a bar graph instead. So it's like ten percent is on the left, fifty percent

in the middle, thirty percents on the right. Yeah, Google kind of defined the scale somewhat arbitrarily of what it means to have a good, average, or bad performance. So, for example, they might say that for first content ful paint, which we'll get to FCP, having a value of under one second is good, having a value of one second up to two and a half seconds is average, and having a value that's over to and

a half seconds is bad. So, since my site is a static site, and granted it's with some blog temperate template from a while back, so it probably isn't optimized, and I don't even I don't know if it's even No, it isn't menified. I'm pretty sure anyway. But I know when I've looked at Google Analytics, like half of my traffic is from India. Maybe it's somewhere in that range. It's quite a bit of by traffic because

it's a technical blog, and I think that's why. And so I'm wondering if as I'm looking at this data, because historically month over month, my blog hasn't changed, you know, it's the same server. I add a couple more articles now and then, but seems like there's quite a bit of variation in you know, say in January, lots of people were in the fast segment, and there's also a fair number of people in the slow segment, but then in November not so many people in the fast segment. Almost

everybody is in the average segment. If we go back to September, almost everyone's in the fast segment. And so I don't know how to make sense of this historical data. Do you have any light to shut on that? Well, crucks Run being free is somewhat limited in the amount of information that it shows. If you actually go to the Crux database itself, you can actually query, like, you know, geographical locations your visitors are coming from,

and you can get more fine grained information. So it can definitely be the result of you know, fluctuations. It might be for example, if there's a holiday in India, for example, like you said, you've got a lot of visitors coming from there, then that can obviously impact your you know, the distribution of your traffic and consequently the performance that you see. So so yeah, just looking at the overall numbers is useful, but if you really want to dig in and make sense of them and turn some of

them into actionable items, then you probably may need more information. For example, if if you know you're doing your blog is like out of the goodness of your heart, but if you actually make it into a business, for example, and you say, hey, I've got a lot of quote unquote customers coming from India, that maybe it makes sense for me to have either a server in India or use some sort of a CDN service that accelerates access from India so that they don't have to wait for the data to count,

you know, for the request to go all the way to my server in the States and then come back to their computers in India. Maybe you'll want to replicate your server onto an Amazon cloud in India or something like that in order to provide them with faster access. But yeah, so in order to

turn it into actionable items, you do need the appropriate information. When I think about the performance, you know how, when I try to analyze performance and what performance actually means, I like to use a model that's called the rail performance model, which is also created by Google. Google will actually feature quite a bit here. They're doing a lot of work related to web performance,

and good on them for doing that. I think we're really lucky that the good of the web happens to at least currently align with the benefits to Google's business. So they have business interests in improving the web. Hopefully that this will continue in any event. They have this model which they proposed or created called RAIL, which stands for Response, Animation, idle, and load. So response deals with measuring how quickly a web page reacts when you interact

with it. So like, if there's a button, you click on a button, how fast do you actually get some visual response to that click. Now, don't confuse response with responsiveness, which deals with how pages react to different display sizes. This is about just reacting to user interactions on the page. So having good performance means that when a user interacts with some element on the page, you want the page to respond to that interaction in under one

hundred milliseconds. According to researchers done that gives your users your visitors the feeling that the response is kind of instantaneous. Now, it doesn't mean that the actual operation that they're looking for happened within that one hundred millisecond. You know, they might be doing some really complex operation that you need to send back to your back end and perform some lengthy computation or database look up or whatever.

I'm talking about the fact that they need to see some visual indication that the system received their input and is reacting to it. It can be you know, even something like you know, popping up some sort of a spinner, if that's what you can do. But anyway, like I said,

you want to do that within one hundred milliseconds. Now, to be able to do that within one hundred milliseconds, it means that the actual event handler should not take longer than fifty millisecond, and that any background operation that the browser is performing should be broken up into segments that are also not longer than fifty milliseconds. So if a user happens to click right at the beginning of such a segment, you have to wait fifty milliseconds for that segment to finish,

and then another fifty milliseconds for the exact event handler to finish. All in all, you know, one hundred milliseconds or less, well preferably less. This kind of has to do with how browsers work. As you know, browsers are single threaded. So if the browser is busy handling some sort of a JavaScript task, it can't react to your clicks or intro or whatever, you know. Until that JavaScript finishes, the browser is like effectively kind

of frozen. I'm sure we're all familiar with that, so so yeah, and whenever a background task like that takes longer than fifty milliseconds, that's referred to as being a long task. And we will see that long tasks are kind of feature quite a bit in the performance metrics that you know, once I start elaborating on them. Animation is the a in RAIL. It deals

with how smoothly the browser performs transitions and animations. For animations to appear visually smooth, you want them to happen at sixty frames per second or FPS. A sense of browser itself needs something like more or less six milliseconds to render a frame. That only leaves like ten eleven milliseconds max for your code to generate the content for the frame. And that's definitely not a lot of time. But that's a whole big discussion in and of its own how to do

like efficient and effective animations on the web. And I'm not going to talk about this today. Maybe this is a topic, so for some future discussion. I is for idle, which isn't really a measurement. It just means that you should schedule background tasks for when the browser is idle and break them down into segments that are shorter than fifty milliseconds each. For that, you can use request the idle callback dom API, which I think Amy you recently

found out isn't available on all browsers unfortunately. Yeah, it can be simulated kind of we set time out, but yeah, yeah, it's really a shame that it's missing. Basically, you give it some a callback and it will schedule your call back when the browser seems idle. But really, these days it's actually better to move lengthy background operations into workers so that they execute

completely off of the browser's main thread and don't block it at all. If you recall, this is something We had Soma from Google as a guest explaining this in detail on episode three ninety three. It was an excellent episode which unfortunately wasn't able to participate in. I was, you know, I think I only joined around episode four hundred, but yeah, it was a really good one. When I think about like the most intense application I use daily.

I think it's got to be either Gmail or Slack, which neither of those seem like they should be intensive. But they're the things that seem like if I look at my browser usage, they're the things that are pegging it right. And then the other thing is like maybe a news site because it loads six hundred ads. Now I use an ad blocker so that that doesn't crash my browser anymore. But it's actually fairly common for a news site to

crash the browser because it's loading just too many ads. And then beyond that, I mean, I'm looking at a lot of blog articles, I'm shopping on Amazon, I am I don't know, I don't know. I listen to music online sometimes I don't play games online. What what are the types of applications where you see these types of metrics that you're talking about, you

know, having a scheduled background tasks and have an idle time. Where where do they fall in in like either what you think a lot of these people they're listening or building, or that you know we experience on the day to day. So we had some conversations in which we splow not necessarily on the

air about boot camps. For example, and we talked about the fact that people at boot camps usually learn something like React, and if you're building a web page using React, there's a good chance that you'll run into long tasks because React either renders or hydrates. And unless you're using some really new React

technology like React, suspense that React rendering operation is a blocking operation. And if you've got a sophisticate IT or complex a UI, which a lot of websites now have that can actually take a fairly long time to render any old websites, that the website that users React can easily have long tasks. And as for animations, I think we've all of us seen animations that stutter or aren't smooth on websites. In ninety percent of the time, that's just loading

animation. You know, it's like, yeah, but what does that matter? It is what it is. For example, these days, people on you have this situation on mobile in particular, where people have come to expect really smooth and responsive behavior when they're using their mobile devices because they're used to native apps, and then when they use web apps or web pages, they don't get that because people build really heavy websites for noness is not necessarily a

good reason. Again, what comes to my mind on my phone is anytime I'm reading a news article, like just the thing just comes to a halt, like can barely get it to scroll up. Yeah again, but again, if you even go into some you know, store, or you do some online shopping and for some reason you do it from your phone, then you will find that a lot of online retailers the web performance that they provide

isn't necessarily that great. Again, especially on lower end devices anyway, which which brings us to the final letter in the rail, which stands for load. And this is what most web developers currently focus on when they're like, you know, decide to work on web performance. So so load is kind of the loading time is kind of front and center for most web developers. That's because we've come to learn to know to learn that uh, lengthy load

time means a high bounce rate. Just to clarify, I assume a lot of our listeners are familiar with it, but clarified nonetheless, a bounce rate is when somebody visits your site or your page and then leaves without clicking anything. So it's kind of like if you want a physical analogy, It's kind of like somebody walking into a store physical store, looking around, and then turning around and leaving without speaking to anybody, without trying anything on, without

actually you know, checking anything, certainly without buying anything. So you've managed to get somebody to your site. That person actually started loading your site and then just left without doing anything for some reason. So you've apparently disappointed them in some way. And it turns out that slow load or sow loading site is a great way to disappoint users and cause them to leave and increase your

bounce rate. So, unfortunately, load performance is one of those things that can is easily easy to experience, so you can go to a website and say, hey, this website loads quickly or this website loads slowly, But it's it's much more difficult to actually describe specifically what exactly does a web For example, when does a website actually finish loading when the content is visible, When some of the content is visible, when all of the content is visible,

maybe just when the main content is visible, But then how do you define the main content? For example, aja you gave an example of news sites, most a lot of the content, sometimes even most of the content are ads. Obviously, visitors don't care about the ads finishing loading, so you kind of want to maybe disregard the ads as from the visitors or the

user's perspective when you're thinking about when the page is loaded. But you know, if you're using some sort of a synthetic tool to measure performance, how does that how will that tool distinguish between the actual interesting content and the noise? And maybe you actually want to base your measurements on interactivity when are some

input elements interactive or maybe when all the input elements are interactive? So how can you even tell when all the elements on a page are visible and interactive? You know, the page, the JavaScript in the page can keep creating additional elements and then making hiding and showing stuff. So how do you know, like when it's the end of the load process and starts like being like

the page just doing its stuff. And as I previously explained, it's not enough that the elements just become like that you attach the event handlers to the various input elements. You also want to handle user input quickly, like I said, preferably in under one hundred milliseconds. How do you know that you've reached that point. Are you going to simulate the click at each on each and every element and each at each and every stage of the loading process and

measure how long it takes to respond? You know, obviously that's not something you can visibly do. So because of all this, instead of thinking about a page load as a specific point in time, like saying I've gotten to this point and now the page is loaded, we should really think about as

a sequence of events or milestones. And on top of that, instead of measuring a concrete currencys, we often have to make do with various heuristic metrics, which gets us to all those terms that I threw out at the beginning of our conversation. And that's why we do have so many performance metrics and why it's important and important step in the performance monitoring is deciding which metrics are relevant to you and which metrics you should focus on depending on your particular use

case. Hey there, this is Charles Maxwood. I'm excited because I wanted to let you know about this thing that I pulled together that I had just I've been dying to have this for years and I never felt like I could, And then I just realized that there's no reason why I can't. So I'm putting together book club and we're going to read development focused books, career books, you know, technical books, whatever. The first book that we're

going to do is going to be Clean Architecture by Uncle Bob Martin. If you're not familiar with clean code or some of the other stuff that Bob has done, check that out. And I've also talked to him on the Clean Coders podcast which is on top End Devs. But yeah, we're going to

get on. He's going to show up to some of our meetings. And what I'm thinking is we'll probably have like five or six people part of the conversation along with Bob and I at the same time, and we'll just so somebody can come on, they can ask their question, and then we'll just rotate people through, so we'll mute one person, unmute another person when it's their turn to come on and be part of the discussion. So we'll do

that for like an hour hour and a half. And then the other part of it that I'm putting together is just kind of a meet and greet gather area on gather Town, and so after the meetup and the call we we'll do as we'll all go over to gather Town and you can just log in, walk up to a group and have a conversation, and that way we can all kind of get to know each other and make friends and get to

know people across the world. One thing that I'm finding is that, yeah, the meetups are starting to come back, but a lot of people don't have the opportunity to go to a meetup. And I really want to meet you guys and talk to you. So we're going to put all that together. It'll all be part of that book club. You can go to topendevs dot com slash book Club to be part of it, and I'm looking forward to seeing you there. The first book club meeting will be in December,

the beginning of December. We're starting the first week of December, and you'll also be part of the conversation about which book we do next. I have one in mind, but I want to see where everybody's at. So there you go. So before I start going down the list, any comments or questions, Okay, then let's run down this alphabet soup. So when reviewing the different performance metrics, I like to proceed more or less sequentially from the

session start as time progresses. Roughly this translates to first looking at the metrics that measure the network performance, then to metrics that cover visibility, and finally to the metrics that deal with interactivity, because usually that's how things go.

First, it needs the stuff needs to be downloaded over the network, over the from the you know, from the web server whatever, and then the stuff becomes visible, the browser renders the various elements, and finally we hook up the various event handlers so that and the JavaScript kind of finishes running so that the site can actually respond quickly to user interaction. So starting with the network stuff, as I said, one of the first metrics to look at

is time to first bite or TTFB. Basically, that's the time from when like the user, let's say, clicked on a link in a Google search for a particular website and until the first byte is received by the browser from that website. So it incorporates stuff like the DNS lookup to figure out the

IP address of the service you're connecting to from its domain name. It involves establishing it TCP connection if you've not yet, if they're not yet using quick it involves established if it's you know, it should be a secure connection, so there's a SSL or handshake that needs to happen. You just mentioned QUICK.

I was under the impression that that was still very experimental and very few web servers had something in place to be able to handle like, for example, I don't think node can handle it, and I don't I don't know that it can probably handle anything, so somebody probably wrote a module for it.

I wouldn't be surprised. But if, for example, you're using the Google CDN to deliver your static assets, they use quick and your browser supports quick, they will use quick at Google of course because they invented it, but like the average, but it's not really part of h GDP two or three, so so eventually we will get it everywhere. It's not that TCP is bad, is great. The Web was built on TCP. The Internet was built on TCP, and the Web is built on the Internet, so

it's built on TCP. But you know, the behavior of our networks have changed since the sixties and seventies whenever TCP was invented, so so stuff like you know, I'm not going to go into that because these are really big topics, but and you can, and our listeners can definitely find great talks about this stuff on YouTube for example, or articles that they can find if

they google for it. But Quick is basically built on UDP instead of TCP, and it's just it's it's more it appears to be more appropriate to modern networks than TCP is. For example, TCP starts with a very fairly small window, which is then it then grows as it sees the quality of your network connection. So it's kind of throttling itself for the first packets because you know, back in the day networks were much slower than they are today,

and Quick does this better. So in any event, TTFB, just as I said, talks about how quickly the bite start arriving at the browser after the user click the link. And it mostly has to do with, for example, either just making sure that your place your server as close as possible to where your users are. So we were talking before about the fact that UAJA have a lot of visitors from India, so maybe it makes sense for you to also have a server in India. Can be a virtual server of

course, or just making sure to use some sort of CDN. If you look at solutions like GATSBJS or next JS or Netlify, all of these guys, all these companies, they actually have solutions where you can actually statically generate your HTML files and then push them onto CDNs, which makes the delivery of these files down to the browsers a lot faster and more efficient because they're just that much closer to the actual user devices. The request needs to go through

far fewer hops to actually get to the data. So we had time to first bite, and then we have kind of time to last bite, which is when the HTML finished downloading. That's not such a common metric to use. More commonly, people use something called content loaded or DCL, which means that HTML is loaded and has been parsed. You can actually have a JavaScript event tender for that if for those of us remember jQuery. jQuery already actually

fires at DCL. So when you look at something like crucks Run and they show you the TTFB metric, let's say they also show you the DCL metric. So this way you know when your HTML started arriving, and you know when your HTML finished arriving and also finished parsing, which is also kind of dependent on the size and complexity of your HTML. It used to be that the main metric for performance was onload, and now it's hardly used anymore.

It's not that interesting. That's because modern websites are so dynamic and with single page applications and JavaScript that keeps on running and downloading more and more stuff even after the page is loaded, so onload is not really that useful anymore. But just to touch on it, the main difference between DCL and onload is that DCL just looks at the HTML itself, and onload also looks at all the resources that were requested by the while the web page was still downloading.

So, for example, if you have an image tag inside the HTML and that image tag starts downloading an image as soon as it's received by the browser, then onload will also wait for that image to finish downloading before it's fired.

If, on the other hand, you have some JavaScript that runs later and just assigns creates an image element or signs and new image to an existing image element, if that JavaScript runs after the HTML finished downloading, it's not actually counted for the onload, so that more or less covers the network key part of the performance metrics, which moves us over to the visual parts or

the visible parts. So the first metric. There is something called first paint or FP, which is just when a pixel changed as a result of the HTML. I don't know if a lot if you've noticed that, but it used to be that when you started navigating to some web page, let's say again from a Google search, the page would immediately become like white and then eventually you will get the actual page that you were navigating too. Browsers kind

of change their behavior there. What they do is they actually keep the old page content around until they actually get the HTML from the new page and start passing the new HTML and being able to render the HTML that new page. So there's like more continuity between pages. This is especially useful if you have like a multipage application for your site, so as you're moving between the pages and your site, you don't see those white gaps in between the pages.

They're not as obvious, but still you know, once the HTML arrives, then the previous content is erased, you get that white background, and then pixels are starting to be drawn. And when the first pixel is drawn, that's a first paint. It will often be something like a background color or whatever. So it doesn't provide a whole lot of value, just shows the

visitor that something's happening. So yeah, so because of that, because it doesn't provide a whole lot of value, this is not a metric that's so commonly used. A much more commonly used one is something called first content ful paint or FCP, which means that the first pixel of some content is drawn. And content is an image or text or an SVG or canvas, those

are basically the things that count as content. So if it's just a pixel that's part of a background color, that's not counted for first content ful paint, but if it's part of an image, then it is counted. Often though, I see that FP and FCP are pretty close to each other, maybe even the same, if the first pixel drawn is part of an image, for example. So what I would say, for example, is if you're considering text, for example, it's often not just enough that the HTML

w a text arrive. You actually need to wait for the font to download because unless you use the font the new font display CSS attribute Chrome for example, if you've got the custom font associated with the text, will not show the text until either the font has arrived or some internal timeout is reached,

in which case it will go to a full back font. You can now tell the browser to immediately go to the full back font, but then that can cause a sort of a flash effect when when the browser then switches fonts. So you know which one is preferable to you depends on you know, your own design considerations. That's something i'd say, I'd see like every day is the fun flash and it's kind of it feels amateurish to me, feels like I'd rather you just picked Telvetica. I would I would not have known.

Yeah, but you're not a designer. No, No, I like, I love fonds, I love them, like, but you have to have some sort of value being brought with a fund and most of these sites I don't think that they really have any value being brought with the font. Like if they had the designer that chose that funt on purpose, great, But I don't think that's the case of most of these sites. I think most of them is just like, oh cool Google fonts, let's pick one and it's not. But yeah, I guess like I would say too.

I mean, this is something that I'm hitting where I'm at right now, and that's like to AJ's point, I think this is where like dav and design you actual really need to work together because like branding is important, but you don't want it to come at the cost of page speed because of how closely that's tied to revenue. And I see stuff fail all the time, because it seems to me like if you just pound refresh on any site that's loading Google fonts, if you let it reload like twenty times, it'll fail

at least once. That's that seems to be a very fragile area of the web, the font loading. Yeah, but look, there are workarounds for this sort of thing. So, like I said, there's a CSS attributes

which can actually lets you control the behaviorally somewhat. So you can either have it wait a little bit for the font that you want, but then go to the fall back font if you take downloading the font takes too long, or it can immediately go to that fallback font and then switch to the custom font when the custom font finally arrives, or it can actually there's even the option of having it the fallback font for the first session, download the custom

font, keep it in the browser cash so that when the next time you visit, it comes from the cash, it arrives immediately, and then it will use the custom font. So the first time you visit a certain site, you will get the fallback, but for every consecutive visit, you'll get the custom font. Look. It's like Amy said, it's a part of the brand. Marketeers and designers agonize over this sort of a thing. They will tell you that they want to convey the spirit and the intent and whatever,

and it has to be on brand. And it's not something that we can just say, oh, you know, oh bah humbug and ignore that. But if it comes at the cost of conversion, then we don't have jobs to design things. So you can you can also, like I said, there are also like various workarounds that you can do. You can use preloading to try to get the phonts down faster. You can even go as far as inlining the font as data URLs inside the htmil itself. There are

various like tricks and hacks that you can use. But yeah, at the end of the day, it's all about compromises. That's our life as developers and people working in tech. Continuing from first content ful paint, the next one is first meaningful paint, and that's when when are the pixels the When does the browser paint the pixels that actually have a meaning for you as a

site visitor. For example, if you're visiting let's say a weather website, then the pixels that you care about are the pixels that have the temperature and whether it's going to raise or not. You don't really care about the ads. You don't even care about the logo of the site. All of these pictures count for first content ful paint, but they're not meaningful for you. The problem with first meaningful paint is that it's at the end of the day,

it's least subjective. Certainly, generic tools like Google Lighthouse don't really know what's meaningful in any website out there. You know, they can try to guess. There are certain heuristics around it, but any heuristic is really problematic in this context. Because of this, first meaningful paint is kind of being sort of deprecated in favor of a new metric, which I'll get you in

a second. I just want to say though, that if, for example, you know that a particular image on your website is the meaningful content, you can even just put an onload on that image and measure the meaningful paint of that image yourself. So, like I said, because of this problem with meaningful paint, Google recently introduced in the proposed to the W three C Web Performance Working Group a new measurement calling called largest contentful paint or LCP.

Basically, they figured out that the most meaningful content is probably going to be the biggest content on the page. So the biggest image or the biggest headline,

that's probably going to be the most important one. So largest contentful paint is basically just an event that you can get from the Web Performance API that fires whenever there's a bigger, something bigger being drawn that whatever was drawn before, which is a really powerful mechanism but also highlights its limitation because first contentful paint is like accurately defined, you know, a particular pixel that's the first pixel. Any pixel that is drawn afterward is not going to be the first

pixel. Largest contentful paint raises the question of when do I stop If something big is drawn, maybe something even bigger is still being downloaded then will be drawn later, And sometimes things are intentionally delayed by the way all of the stuff that I'm talking about all these painting operations are for I neglected to mention there for stuff that is above the fold, So anything that is below the fold doesn't count for fp FCP or does that mean above fold below fold?

So you know how maybe if you know, we're old enough to remember, but once newspapers really really big, so that when our dads used to go to the bathroom with a newspaper, they would have to fold it so that they could hold it while they were sitting there comfortably. And as a result, when newspaper men thought about where or people thought about where to put based back then it was bothly men, I guess, but now it's certainly a

newspeople. When they thought about where to put the most important content, they wanted to put it above where the people used to fold the newspaper. So the most important stuff was at the top of the front page, above where people would fold the front page. The less important stuff was below that fold. Even less important stuff was on the back of the newspaper, and the least important stuff that you really didn't care about was in some center page.

So the term above and below the fold now in the browsers mean the content that's visual where the page loads before the user does anything like scroll or zoom out or whatever. So what's initially visible in the browser's viewport, that's the content that's above the fold. Anything that you need to scroll down to get to that's below the fold. A long story for a fairly simple term. I was just going to add really quickly to you to the largest content for

paint. So I don't think that's something because as part of white House Pie six, it's reporting on just yet in page speed Insights. But if you go to web dot Dev, they have code provided to you that you can inject into basically like you're under pipeline on your app, and it will tell you what the largest note is. Actually even even like even page speed Insights

already collects this information, they just don't display it yet. So if you use if you use the paid speed Insights API, you will actually get the largest contentful paint. But yes, they've they've announced that in V six, which was already supposed to come out, I think, but you know it'll be there when it gets there, that they're kind of eliminating the first meaningful paint which is still there, and they'll replace it with the largest contentful paint.

So going forward that that's the metric to use, and like I said, it's actually already supported in the Web Performance API. So I assume that the various, like I said, tools that you can use to gather performance information from real user sessions will also start reporting largest contentful paint. Two more items that I want the measurements that I wanted to mention in the context of visibility, one older one and one a newer one. The older one is

something called speedy deck Speed Index or SI. That's not one that Google invented, that's one that they inherited. Think about it this way. Let's say you have a page that loads and needs to display or render some really complex scene. It can work one or two ways. You can have nothing, nothing, nothing, nothing, and then bam the entire scene. Or you can have the scene built up gradually until finally so they finish. Let's say it at the same time. But one there was nothing and then suddenly you

got everything, and the other one built up gradually. From the performance perspective, then building up gradually is preferable because the user has something to see, hopefully something that's going tenful and maybe even meaningful. While the page is building up. You know, one of the things that really annoy me about some news apps, even native apps, is that they don't show the content and

at all until after the ads are loaded. They have like a spinner or something that until everything in the page is downloaded, they don't show you anything. And that's really annoying to me because I'm waiting on the content that I don't care about, while I could have already been reading the content that I do care about. So in terms of performance, you do want that gradual

build up, and that's what speed index measures. It kind of takes, uh, like screenshots of of the of the browser as it it's as it builds up the display and and and and sees how much content is available at each point in time, and based on that it gives you the score. Now, because of that, because of this whole process of taking screenshots and whatnot, the speed Index or SI score is really only relevant for synthetic tests

because you can't really take those screenshots in real user sessions. But Google Lighthouse, for example, that's one of the measurements that they currently use. A new measurement that they recently introduce and one that can be measured in The field

is called commulative layout shift. I'm sure you've all encountered the situation where you were reading something and then because let's say something additional was downloaded, it pushes everything down, and suddenly you lost your spot in whatever it is that you're reading because everything shifted down because something on top just finished downloading. It can be even worse if you're trying to click on something in the document that explains

this measurement. Good They actually even have like this animated gift or video or something that shows a really amusing scenario when somebody trying is trying to cancel a purchase, but because something appeared and pushed everything down, they click the purchase button instead by accident because it got pushed down the instant that they clicked.

So obviously you want to avoid that. So commulative layout shift or CLS for short, that kind of is a measurement that combines how much the size of the content being shifted down, how much area of the screen is being shifted down by how far is it shifted. So it's like a combination of these two values, and you want to have this as small as possible. You want you don't want stuff jumping around as the as the user is, you

know, scrolling through your page. So just recently and you know, thanks to Dan, I've been able to like chat with him and get his insight to which I like immensely appreciated. But some of the tricks that I've been kind of doing is so one of the first ones was because I work for an e commerce company, we have a lot of different like tracking pixels and all kinds of stuff. We also have a chat box that is pretty heavy on initial page. So what I did I couldn't use the request idle callback

because it wasn't available. What what I did do is, since that was like a huge chunk blocking the page from being usable to the user, is I delayed that to only occur once the user has actually interacted to the with the page, so that it can load more quickly. Does another thing just like make sure you're auditing like all your caching headers and especially if you're using

third party services. So we at work use zite and the app was not always on site, and so we had some headers that were actually interacting with the default caching that Zite gives you. And then the last thing that I've been working on, which seems a little bit more creative is we have because we're building out multiple properties, we have some reusable chunks of React code in

a Mona rebo, it's not necessarily needed on the page. So what I did is using like dynamic imports and JavaScript is I'm only loading those things if a certain user interaction is required to load those things. And that's also cut down pretty drastically on this kind of stuff. So basically you're doing tree shaking and lazy loading of stuff only as needed. By the way, I completely agree with you about the caching. One of the easiest or quickest wins is

just making sure that all your resources have the appropriate cash headers. I've seen so many cases in which stuff that's totally static is either not cashed or cashed for really short duration. Another quick win that's similar to that is making sure that all your downloaded content is compressed. I mean, everybody, every browser

these days support JESIP and even broadly for even greater compression. So you know, downloading your HTML or JavaScript without compression or CSS without compression is just like sad, and there's no reason not not to take advantage of that. But but yeah, I totally concur with you, there's there are there are a lot of wins that can be achieved. You know, we spoke with with Bruce a couple of shows back Bruce Lawson about semantic HTML. I forget the

number of the show. You can check this out later, but he was talking about the picture element, for example, as a means of downloading appropriately sized images. Because let's say your more the mobile screen is going to be smaller than the desktop screen, so why would you want to download a huge image for your mobile device? So you can use media queries to uh download them more proper, properly sized images using using that you don't even need JavaScript.

I think this also one thing Amy that you discussed on a couple of shows is the ability that now exists in some browsers to lazy load images, so images that are below the fold don't download until the user actually scrolls to them, And all you need to do in order to get that is just to add an attribute to your image tag. You don't need to write any

jobscript or anything for it. So so yeah, there are a lot of winds that can be achieved without too much effort, especially if you know what to look for and then you can kind of measure what you where you were

before these changes and measure where you are after these changes. And you know, if you're if you're looking for a raise, for example, it's it's really useful to be able to have this graph that shows how much you improved something when the next time you're you're negotiating your salary and I guess, yeah, and I'll have to hop off. My pick is just going to be the web dot dev docs. I think they are not a lot of people know about them necessarily and they're absolutely amazing. Yeah I do. My pick

is Dan as well. Thank you very much for that. And two seconds, just want to point out something. You can use picture now. It

is backwards compatible with other browsers. So your default image inside of your picture tag is an image tag, which means that no users that don't have supported browsers will have any deficit, and all users that do have a supported browser will get the benefit and supported browsers for that, like any browser from twenty sixteen, you will definitely get a lot of benefit for stuff from stuff like

that. But I totally agree with you Amy about web dot dev. In fact, more or less all the terms that I'm talking about have definitions on web dot dev. So if one somebody wants to look like wants to reread the definition, or wants to see like images or graphs that show what these terms are, want more, who needs more clarification, they can definitely find it web dot dev. It's an excellent website. So I guess I'll resume. So I finished more or less the visual metrics, So now it's time

for the metrics that kind of measures interactivity. The most explicit one you could say is simply called time to interactive or TTI, which kind of looks at when does the page become consistently interactive? And by consistently interactive, it means that you can expect reasonable reaction, that all the elements that should respond to user input have the event handlers associated with them, and that they'll respond relatively quickly to that user input. The problem is how to measure that. Now

Google has some fairly complex and sophisticated heuristic algorithm inside of Lighthouse. I have to say that I'm not such a huge fan of that algorithm, and I think there are you know, be improved and maybe I'll do that or this. I'll propose an alternative to the existing algorithm. Let's see how they respond to that. But in any way, it's really only appropriate for synthetic tests

because measuring it in the field is kind of problematic. For example, if the user interacts with the session, that actually impacts this whole measurement of TTI, so you might get wrong TTI value simply because the user actually interacted with the session. So that makes this measurement kind of problematic, and like I said, it's mostly using synthetic tests. A newer measurement is something called TBT,

or total blocking time. This measurement, if you recalld I talked about, long tasks, are those segments when the browser is busy for more than fifty milliseconds, which means that if the user does some sort of interaction, it's highly likely that we won't be able to respond in under one hundred millisecond.

So TBT essentially counts all those longer than fifty millisecond segments. It looks at all the long tasks that happen until the time to interactive, and then it looks at how much longer than fifty milliseconds they were, and just sums this all up. So it's it's like a sort of again a heuristic value that gives some sort of a measurement of how likely or unlikely the web page

is to quickly respond to user interactions. And the last measurement that I want to talk about, because I really I think went through a whole lot is again a relatively new one called first input delay or FID. That's a measurement that's intended for actually for the field, and it looks at when the user

interacted for the first time with anything something in the session. So, for example, if there's a button, the user clicked on that button, so it looks at when the first interaction occurred relative to the start of the session, and how long it took the browser to respond to that interaction. And by respond, they're looking at how long it took until the first screen or update after that interaction, essentially the time that it took from that interaction until

something visually happened in response to that interaction. So the values that you can get from FID are like, you can get like three things from it.

How many sessions actually have FID. You can say that those that don't have an FID, those are that's your bounce rate, how long relative to the start of the session did FID happen because people probably don't interact with your site before it's like visually sufficiently complete for them to interact with it, and how and the length of that duration until it responded to the browser responded to that interaction, and as I keep harping, you want that to be as under

one hundred millisecond or close to that as possible. So those are the values that you can get from FID. The final thing that I wanted to say about about metrics is that you can also create custom performance metrics for yourself that match your own particular use case. For example, there's a well known story

that Twitter created when they went to their big performance push. They created their own custom metric called time to first tweet, where they measured the amount how long it took from when the page started until the first tweet became visible. So for them, obviously when you visit Twitter, that's what they really can care about, how quickly do you see the top tweet in your feed,

so that that's the thing that they measured. But let's say you're built, Let's say you're building an online store, then you may decide that one of the most important metrics for you might be a measurement of how long it takes until the visitor can make a purchase, for example, when does the buy now button become interactive and quickly responsive, So that might be your metric for for deciding you know how quickly your how how well your web page performs.

Or again, you can use a whole combination of all the various metrics that I mentioned, along with your custom ones. Now, just to finish off, if you use a tool like Lighthouse or Paid Speed Insights, then you get the sort of a score, and the score that they do is just the weighted average of of some of these metrics. So they use a certain

combination in Lighthouse version five, which is what you currently get. But like I said, they're about to release Lighthouse version six and they intend to make some changes there use different metrics in different ways, so it's likely that we'll see all of a sudden different scores. For anybody who's using pagebed Insights, for example, will suddenly see different scores when they do that, we will see if it's more accurate, certainly hope so that more or less covers all

I had to say. I know that I said quite a bit all right, enough said certainly, well, thanks Dan, thanks for that in depth explanation. I was really well repared, prepared and researched, and I think there was a lot of value there. So I hope that our listeners got that as well as always feel free to tweet a us with more questions and comments. We'd love to come back around to some of these topics and discuss them again with more information. So so don't forget to check us out on

Twitter where what js jabber these days? Yeah, and also this topic is definitely my passion and like I said, what I do day in, day out, So if anybody wants to reach out to me, the best place to get to reach me is also on Twitter. I'm just Dan shapp here on Twitter, so you know, feel free to reach out. That's with two p's and no e at the end. Correct. Have you ever wished that you had a group of people that were just as passionate about writing code

as you are? I know I did. I did that for most of my career. I'd go to the meetups, I try and create other opportunities and it was just really hard. Right the meetups. I got some of that, but they were only like once or twice a month, and it was just really hard to find that group of people that I connected with and really wanted to, you know, talk about code a lot, right,

I mean, I love writing code. I think it's the best. And so I've decided to create this community and create a worldwide community that we can all jump in and do it. So we're going to have two workshops every week. One of those or two of those every month, are going to be Q and A calls right where you can get on you can ask me or me and another expert questions. The rest of them are going to be

focused on different aspects of career or programming or things like that. Right, So it'll go anywhere from like deployments and containers all the way up to managing your four oh one K and negotiating your benefits package. Well, we'll cover all of it, okay. And then we're also going to have meetups every month for your particular technology area. So we have shows about JavaScript, react, angular view and so on. We're going to have meetups for all of

those things. I'm going to revive the freelancer show. We'll have one about that, right, so you can get started freelancing or continue freelancing if that's where you're at. And I'm working on finding authors who can actually do weekly video tutorials on some thing for ten minutes. That's related again to those technology areas, so that you can stay current, keep growing. So if you're interested, go to topendevs dot com slash sign up and you can get in

right now for thirty nine dollars. When we're done, that price is going to go up to seventy five dollars, and the thirty nine dollars price gets you access to two calls per week. The full price at one hundred and fifty dollars, which is going to be seventy five dollars over the next few

weeks. That price is going to get you access to all of the calls and all of the tutorials and everything else that we put out from top endevs, along with member pricing for our remote conferences that are coming up next year. So go check it out topendevs dot com slash sign up. All right, well, thanks very much for being our guest today, and do you

have any picks for us? Yes, so I actually do have a few picks, actually just too really so The first pick is that a few days ago, I found out that there's this neworks stability feature in the Chrome deav tools, and I want to highlight that you can actually simulate vision deficiencies from within Chrome dev tools. So if you want to see how, yeah, if you want to see how people who are let's say color blind or have blurred visions or whatever, how they perceive your website, you can now actually

simulate that and see it for yourself right now. It's not in the production version of Chrome. You can find it in Canary, but you just you know, open the depv tools, go to the bottom of the rendering tab and you will find a drop down there that you know, you can choose the what kind of vision deficiency you want to check, and just see how the browser window adjusts. It's really really cool and really really useful, and I'm really happy that Google has done that. So that's my first pick and

my second pick. You know, you guys keep picking TV shows and I never did, so I decided to pick one as well. And the one that I want to pick is one that I really really I'm currently enjoying. I really love it. It's a better called Soul I was a huge fan of Breaking Bad. You know, it's up there, like I would guess in my top three shows of all time, and Better Call Soul is just awesome. When it started, I was really worried that they couldn't live up

to Breaking Bad, but they have. It's really different. The pace is completely different, and the characters there's a lot of similarity, but the main character is certainly different than the main character of Breaking Bad. It's a totally different personality. But the show is still is just so great. I'm really really loving it. I'm really enjoying it, and I can't recommend it highly enough. So those are my picks. Awesome. So in terms of media,

I have got to pick Brandon Sanderson's The Way of Kings. I think that it might be I haven't watched that dirty, filthy, soft porn show myself, but I think that's Some people say it's tactically a similar idea to Game of Thrones, but in a family friendly way where you know, yeah, there's a little bit of blood, but there's no just lewdness to it. So I can't say for sure, but it seems like the two have some level of comparison. But I just I just love it, Oh my

gosh. And Brandon Sanderson is just such an amazing author. He's I mean, I would have never picked fantasy as a genre that I was interested in, But the way that Brandon Sanderson writes, it's so methodical and logical that the fantasy feels more like science fiction that he writes. It's interesting that you use that as the comparison. I just want I've read it as well. I've also enjoyed it a whole lot. I just want to make sure people

are aware that the series is not yet complete. I think he's supposed to write quite a number of additional books there. Hopefully this won't end up like what's going on with Game of Thrones, where you know it never actually happens

and where it kind of stuck. So Brandon Sanderson has a good track record of rotating through his novels and completing them, so I like it may be a decade before the series is complete, because it seems like this one is like his masterpiece that he's been working on here and there, letting it float around in the back of his head since like the nineties or something, and has finally gotten it to a point where over the last several years he's been

publishing. But I have faith that Brandon Sanderson will actually complete his works because he seemed to have demonstrated that in the past, and he's talked about his methodology of how he writes his books, and from what I understand, he writes the outline of the of the series so that the plot points are developed, and then starts writing each book and revises as he goes. So he makes a point of talking about how he knows where the story is going before

he publishes the first book, which I think with some other authors. I the Name of the Wind comes to mind. Yeah, he stuck. I understood that he wrote the book and then threw it away or something. Supposedly the third book he wrote it and didn't like it and is revamping it, But I don't know. Like it started so strong, Like the Way of Kings is what I wanted out of Name of the Wind really like that's what

I thought that I was getting into. It has very similar vibe and feel and storytelling technique and jumping back and forth between time periods and so like. To me, the books feel very similar, except that the Way of Kings. I step confidence that the whole thing's going to come to a conclusion. Whereas Name of the Wind, it started becoming tangent after tangent, after tangent after tangent, and then it's like, okay, well, like even if you could wrap this all up, does it mean anything anymore? So,

yeah, I know what you mean. It's kind of like lost in a sense the TV show that you create this really amazing yarn, but then you have a problem pulling all the threats together. Another issue that I have, though, even with that book, is that by the time the next book comes out, so much time would have elapsed. I might start forgetting the

plot. I don't know what the plot is, my wife. So my wife and I started reading it last year, and then I kind of felt like, I don't know if this guy's going to deliver, So I became less invested. And then she read through the second book on her own and kind of like gave me the recaps, and every time she told me what was going on, I'm like, this just seems like it's less and less

focused. Anyway, not a bag on it, because I think that the premise was awesome, and you know, he could tie it up really well. The execution of the third book. Maybe why he's waiting on it so long, as you know, is to get it just right. So he yeah, maybe he'll just nail it and hit it out the park, so hopefully. Well so yeah, one last thing I'll say about that is that it's set in the same universe as his other books, the so called cosmir

Oh. Yeah, if anybody wants to go through a series that he did start and then finish, they can look at his excellent miss Bourne series as well. Yeah. The miss Bourne is a wonderful work, and I in some ways I prefer Lantris, which I think was more his entry into his own you know, like his first popular book that he did himself. But

at Lantris is very interesting. It takes like five chapters to get into because they rotate through the characters, and it takes you the five chapters just to kind of understand like, oh, this is the place that we're in, and this is how these characters are relating to each other, and you can start to imagine a path where they start converging that it's not just three separate stories, but the first three chapters it's just like three completely different stories.

And that was a new way of storytelling for me. The way of Kings kind of bounces back and forth. It's not methodical, like this chapter is about this character, this chapter is about this character, this chapter is about this character. But it does bounce back and forth where it's like, here's two chapters about this character, now here's a chapter about this character. We're gonna skip this other character for a little bit because nothing's going on in their

world right now. We've said all we need to say about them, and then come back to them ten chapters later. So I'll throw in another retroactive pick. If you've listened, if you've listened to my other picks. Throughout all the episodes of jas Jabbra that I participated on, I actually described various

fantasy classics like books fantasy books that I really really love. So if you go back even just look at the pick section on the jas Jabbra website, you will find quite a number of really excellent fantasy books, most of them complete series is that you can chew that I would definitely highly recommend for you to check out. So if you're into that kind of stuff, you know, please do then you know, since I haven't babbled on long enough.

I'm also going to pick Taco Bell. If you don't have a Taco Bell in the country where you live, let me tell you you are missing out on the finest American misrepresentation of Latin food that you could possibly be missing out on. A ninety seven cent burtas have never tasted so good, and I just I can't stomach the authentic stuff in comparison, I really don't like most

Latin food, but I do love Taco Bell. And there's a couple of like American Latin fusion restaurants that I do really like because they, you know, they do the things that Americans like. They have nice presentation, they put on the mole i sauce on probably things that maybe Mola doesn't traditionally go on. And which way, yes, yes, the I forget how to say chicken, but you know the chicken fingers with with with vinegar, tomato sauce. Uh no, anyway. Uh So that's all. Thanks for listening

in. Thanks for everybody that was on the show today that was already left now. Yeah, and we wore them out. We wore them out, we wore them down. We'll catch you next time on a new episode. Of J. S. Jabberz Bye ideas