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