Well, hello, hello everybody, and welcome back to another exciting episode of
JavaScript Jebber and this day, well, I'm supposed to introduce our panel first,
and then our guest Steve has corrected me, so you got me aj
I'm your hostess with the mostess or whatever. And then we got Dan Hey,
and we also have Harry Roberts, also known as the infamous CSS Wizardry
nothing to do with well, hello everyone. Yeah, I don't write any
CSS anymore. Also, I picked that domain when I was seventeen years old,
So that's a portion retail for everyone watching. Don't let your children pick
their own domain names. Yeah, but parents need to really be on the
ball on that one, especially with the credit cards being like twelve year olds
have credit cards. Now, I don't know how that happened, but that's
the thing I haven't seen that that's terrifying. It has it built into the
iPhone. It's like the credit card that you can create a subcredit anyway.
But today's topic is what are we what do we doing? Not child that
child? I think today I'm talking about web performance. Yeah, not the
bottles. Well, we can have a drink afterwards if we want. Yeah,
No, I'm I'm jealous. You know, it looks like a really
nice collection anyway, So let's go ahead and jump right in and Harry,
why don't you tell us why you're famous and your most three recent controversial tweets?
Well, I would. I don't think I'm famous. I certainly wouldn't.
I mean, I think if you do. If you work in the
web performance space, you might have my I've come across my website before.
But Mike most controversial tweets, I don't know. I don't really tweet controversial
things anymore. Probably the most controversial ever was when Imagure i mg u R
dot com switched to a single page, fully client rendered app. Don't if
you've noticed, if you look at an X profile now a Twitter profile when
you're logged out, it doesn't show X's, it doesn't show tweets chronologically.
It shows them in the most liked first find out. Seeing my own profile
logged out, and it reminded me of a tweet from quite a while ago.
I really went on an Imagure immature because they switched a fully client or
rendered status so that in group. Honestly, you're probably right. I've never
heard it set out loud I've never tried set out loud untill just now,
but they switched one simple image tag out for about two point seven meg of
javascripts, and I got flamed for that one. People like you don't understand
the business case of imager. They need to serve ads. They can serve
ads, but need to serve the image first, and the white people willtop
turning up. So I got flamed for that one. I got flamed for
saying people shouldn't use emojis in professional contexts or gifts in presentations. People.
Really one guy wanted to fight me for that one, but I'm not a
very controversial person. It doesn't really suit my style and certainly doesn't suit business
about famous though, I have to say that I said it before we started
recording, and I promised to say it again that in the particular space of
web performance, you, Harry, are one of my tech heroes. And
I've been following your content for a long time. You know, your talks,
you your posts, and I've learned a lot. So yeah, thank
you. That really means a lot, especially because, as we were saying,
just before we started streaming, you and I met like years ago.
I reckon, we must have met six eight years ago and we have stayed
in such ever since, but never again in person, which is a real
shame. But that really means a lot, because likewise I keep eyeing what
you're getting up to, and yeah, that means a lot, thank you.
Yeah, so I wanted to have you on the show because there are
a lot of interesting things going on in the web performance space, and in
particular we are a few months away literally actually a one month away I think
now from Google switching up Cowork vitals. I mean they've kind of kind of
done it before when they changed the meaning of CLS commulative layout Shift. They
have modified LCP over time a little bit in certain ways, but this is
by far the biggest change that they're making. So maybe we can start with
that. Yeah, I mean swapping first in put the layout and replacing it
with IMP I think is it's drastic. It's a huge change, and I
think a lot of businesses are going to struggle, speaking purely on it.
Gotally, I have clients who've got twenty two million good URLs in search console
and in what is it, the twelfth of March, so it looks like
one month and two weeks or whatever. It is these companies are going to
have twenty three million bad URLs in search console. The difference is stark,
and one thing I do kind of worry about, and it's not Google fault
at all, but people have known this update was coming for a long long
time and people are kind of I've not had a single client who's trying to
get ahead of the curve here. I worked with the client only last week
who were kind of only just starting to really worry about this, because I
don't think I don't think a lot of companies were just how big the shift
is going to be. I think it needed to happen. I think IMP
is a much more suitable replacement for first Delay, but I do think it
may have helped a bit in a stop gap period because the difference between the
two as well, you know, is just enormous, and trying to go
from FID to IMP in one hot this is going to be a real struggle
for a lot of companies. So maybe it's worthwhile to set the stage a
little bit on that, to maybe talk a little bit about what co work
vitals are, what I f ID was or is but you know soon will
be deceased, and what IMP is that replaces it to give a little bit
of context happily. Yeah, so without slides or visual aids, I guess
the best way to talk about core revitals would be Site speed has been a
thing for well over a decade now, a long long time, but historically
we had to lean on archaic and kind of esoteric events like the browser's load
event. We talk about load times, but a load time is invisible to
a visitor that they don't know what the load event is. You can have
a really feeling page with a terrible load time, and the load time would
be completely irrelevant to what the customer experienced. So Google, to their credit
very thoroughly researched, have tried to get some one size fits all metrics,
metrics that can apply to every site in the world, and try to quantify
the user experience of how fast that site felt. The nearest equivalent to a
load time would be the largest contentual paint, which is simply one was the
biggest bit of content presented on screen. We've got culative layershift, which you
already mentioned, which is did the page move around as it was loading or
as you were interacting with it. That's not a performance metric at all.
Isn't measure steed one bit, but it does measure the user experience and sort
of measures with this page frustrating to load. And finally, yeah, we
had first input delay. And the whole point of first input delay is,
in fact, I've got a really good analogy for first input delay and I
inp and purely coincidentally, I'm sat in the right place for it. First
input delay is when someone clicks a button for the first time on that page,
how long did it take before the web application could start responding. And
it only measures the first click, and it only measures how long before the
application could start repon responding. So this misses out to I must have some
kind of emojis. I don't know what that was. So anyway, that
miss two crucial things. The first thing that misses is it only measures the
first click on a page. Now, if the first click happens to be
really slow, but the next two hundred clicks are really fast, you only
measure on the really bad one. Conversely, if the first click is really
fast and all the next ones are slow, it looks like your page is
really click The problem with that is it's really easy to gain you could wait
for a use as a click before booting all your JavaScript. You could say,
well, wait for the first click and that's just gonna be a click
on anything and it'll respond really quickly. Then load all your JavaScript. You
know that every subsequent click will be slow, but you know it won't get
measured. That's the first problems first into the day, to just what quick
is doing. Although yeah, let's let's let's put that. You know,
quick is an interesting topic, but let's push it off a little bit.
I did want to say that in most cases you really didn't need to even
gain uh f i D that much because you just got to do the FID
score almost regardless of what. Oh yeah, by definition, I said that
like we kind of that measurement kind of won in the sense that, you
know, if anybody was a laggard and I worked at Twicks, and initially
when we started we were even bad at FID, and then we fixed it
and now Wicks has good f I D and it's that's that's that there's nothing
more to do in that context. So if you look at most web pages,
they just have really good FID and it it's like that if if you
know, like have an examined in school and everybody gets an A or an
A plus, then you know that test is kind of meaning is meaningless.
It doesn't really provide any information. So we needed to replace if I do
with something else. Yeah, exactly. So that was the kind of core
problem was that it was like ninety websites past FID despite we all know that
JavaScript is a huge runtime bottleneck, so how could ninety plus websites be passing
that metric. The second problem with FID is that it didn't measure how long
it actually took to do the work. The way I explain this to non
technical stakeholders, very non technical stakeholders, is imagine you went to a bar
and you wanted to order a drink. Now, if you get to the
bar and the bar is really busy, there are hundreds of people and only
one bartender, it's going to take you a long time before you can place
your order for your drink. And that's first. In book delay, it
measures your first order for your first drink, and it only measures how long
it took you to order the drink, So it doesn't matter how quick the
bartender is or how long it took them to get the drink to you that
doesn't get it doesn't get counted, whereas interact from to the next paint.
The analogy would be you might go to a really really busy bar and you
might order a drink, and it might take you a long time to order
that drink because there are so many other customers there. But if you just
order a glass of water or a bottle of beer, then the bartender can
produce that drink very very quickly. If you order a really complicated cocktail,
then the processing time of the drink will be increased. If you just stay
at the bar and they slide it over the bar too and you take the
drink, that's your presentation delay, and they can get the drink to you
very quickly. However, if you say, oh, I'm going to go
and set over in the corner and the bartenders to bring the drink over to
you, that's your presentation delay. So what ironp does. It doesn't just
measure how long it takes to order your drink. It measures howing it to
make your drink and how it took for the bartender to put the drink in
your hand. And it does that for every drink you order, not just
the first drink, so I think I feel like first time. But the
lay was really easy to gain for those two reasons. It was only the
first click, and it only measured the delay to start the work. I
NP is much harder the past because it measures well between ninety eight and one
hundreds percentile, so more or less your very worst clicks, and it's not
even clicked. It's interactions, so keypressers and stuff like that, and then
how I'm accepted to process that, and how except to display that to you.
It measures a lot lot lot more work. And that's why most sites
are going to go from green to red overnight. It's a few more thoughts
both about FID and I and P. So from the get go, I
had prompt issues, let's say, with FID, and I was very upfront
with the people, with the great excellent people at Google about it, you
know, Anny Sullivan, Michael your Wise while he was there, and others.
Patrick And the problem is that in many cases, if your website was
especially slow in loading, you actually got better FID because if your JavaScript took
a long time to download, so long in fact, that the user interacted
with the page before the JavaScript actually even loaded, then when and on the
other hand, the page had let's say SSR or SSG, so the content
was actually already visible. Then you would click a button that would literally do
nothing because the JavaScript wasn't even wired up yet, and from the fid's perspective,
it would be you know, instantly responsive. You know, the response
would be effectively nothing, but your FID would be excellent. And that was
one of the issues that we had that again at Wicks that initially, when
we started to improve the download speed of the delivery of the JavaScript, they
actually had, you know, hit this kind of valley where it seemed to
be getting initially worse before it started getting better, simply because you know,
we were the pages were getting interactive sooner and that problem I just described was
less likely to happen. But yeah, you know, yeah, go for
it. Sorry. I've run into the exact same thing on client sites.
Clients very aggressively deferring their JavaScript would end up passing fit purely because even clicking
a native browser input like a button, you don't have to wait for the
JavaScript devan handles to be attached. Browsers have their own event handles attached the
buttons already, so exactly as you say, if someone interacts with an interactive
element before the JavaScript is booted, it will still capture a valid input.
Even that input doesn't do anything because it's the other thing first input delay and
iron p well, sorry, just imp Even if there isn't a UI up
day afterwards, even if there isn't a next paint, you still capture a
score for every click. So what that means is, in the case of
FIT, the button doesn't have to do anything. It doesn't have to do
anything at all. It only captures the fact that you clicked a button,
and if it needed to do something, we could have done it immediately.
So exactly as you say, a big risk was people really really aggressively deferring
and lightloading their javascripts could sort of skirt around the system purely because the chance
of someone clicking before the JavaScript had run was actually quite high. Now,
you talked about the fact that you're seeing customers and it maybe it's worthwhile to
mention that you work as a freelance consultant and you work with customers looking organizations
looking to improve their performance of the websites, so you're obviously exposed to a
lot of poor performing websites and a lot. Yeah, you mentioned that you're
seeing scenarios where they currently have really good FID and even LCP and CLS and
consequently are really passing coed vitals on most of their pages in for example,
in the Google Search console, but that once they switch over to I and
P that the situation will be much worse. Now, it's interesting because I
brought up this concern with the people from Google a while back. I don't
remember if it was with any or with Rick or with Michael one of them,
and their response was that according to their tests, most what they saw
was that most organizations that have a poor I and P or will have poor
I and P also already have poor LCP. So their argument was that the
overall ratio of passing websites won't change that much because the score for like you
said, this score for that interactivity, the interactivity score will drop, but
it will have less a lesser impact on the overall commodative score of all speed
core work vitals. Would you agree with that or not based on your person
Yes, I haven't seen things that necessarily corroborate that, And do you know
what I don't have? I really don't have the access to the data that
they do. So I look at a small enough number of data sets that
non no two look alike, and every single site seems to have unrelated issues.
So you know, really I see sites that. Yeah, so I've
got a client at the moment who doing really well in LCP, really bad
in CLS, and I n P their LCP is great, It's been great
forever. I don't typically tend to see patterns, but I'm looking at a
really small scale. So I'm not talking HD archive. I'm not talking you
know, Google's crook data. Based at large and on my own clients,
I can't really there's not contently decipher or see any patterns that suggest that.
I have to say. That kind of surprises me to an extent because I
would expect for you to be seeing the same issues over and over and over
again. Yeah, I mean, really, it's really surprising. Some issues
are really common. But we've had I think the performance industry and people who
care about performance even a little bit. Why is the fact that some things
are always just gonna will always cause you problems? Client side rendering is a
terrible idea. So if you want to be fast, certain things are just
starting to get filtered out, and those same mistakes that I would see five
years ago are far less common now. What I'm seeing on a per project
basis is every client has pretty significantly different problems to the last. So,
you know, that kind of moves us over to the next part of the
conversation. I guess because when we were talking about, you know, what
we should discuss on this podcast, I thought that an excellent topic would be
to talk about, you know, what you are encountering in various customer site
obviously without naming names unless you really unless you really want to, yeah,
but probably you know, yeah, basically, yeah, basically things like on
the practical side, you know, things that you tend to see in you
know, mistakes that people tend to make, but also amusing stories if you
can share them. Yeah. Well, like I said before, it used
to be five years ago everyone had gone full client side reacts and that's always
gonna start. And then everyone now knows that service side render and then rehydration
is faster, not perfect, but certainly faster. So of the age old
problem seems to be filtered out. I was I think, well, I
think I don't know, how about it was a tweet of mind that was
responsible for a lighthouse check for are you lazy loading your LCPM? And because
that was so commonplace even before WordPress plugins enabled that by accident, all these
really common problems. I think even just non performance engineers are now so aware
of web performance that basic mistakes, certainly on the projects I'm seeing, don't
really get made so much anymore. Where if I can interject, for one
thing you mentioned, you mentioned client side rendered React you know, basically websites
or projects that initially started with the create React app, yes, I have
essentially by definition will have poor core performance as is measured by core advitors.
And that's not rising because obviously, you know, if you need to download
a ton ofavascript, then you know, run that JavaScript, makes several AJAX
requests, run more JavaScript and only then actually start showing stuff, then obviously
that's going to be much lower than a website that just download stuff from the
get go. But the interesting thing is that I'm when when speaking with various
let's call them larger companies, companies that build let's call them quote unquote web
applications, a lot of them still work this way. Uh, if if
the app, if the web app is not seoed. Uh. If if
it's you know, if it's something that's behind a login screen or whatever,
then from their perspective, you know it's it's it's so it's okay to work
this way. So I'm kind of agreeing the market's splitting on this regard,
Like some sites care about load performance and a lot of sites really don't.
Yeah, and I do agree with that sentiment. So, for example,
my accountancy software is all web based and it's slow. But if I look
into my accountancy software, I have to do it, and I know it's
going to take me at least thirty minutes anyway, But I don't mind it
being slow as long as once it's there, it's usable. And the sensitivity
there is a lot less than if I just want to find out if I
just want to quickly buy some groceries on the way home or something really quick,
I try to buy something quickly and leave. Again, there's a lot
more friction and a lot more sensitivity. If the task itself should be a
two minute tests, you don't want to spend ten percent at that time just
waiting, Whereas if the tasks are thirty minute tests, you don't mind the
different cost. I don't have any research to prove this, but I do
sympathize with the use case of we're a web app. I'd be happy to
wait for photoshop in the browser. I wouldn't be happy to wait the same
amount of time to work out what time my next train is. There is
no way of quantifying that sensitivity, but I do believe it exists, and
I do think that there is there's no definition between what's a web app and
what's a website. One thing I do think is if you're a company who
can name five different pages on your website, Oh, we've got the homepage,
a product details page, a product listing page, a search page.
If you've just listened four different pages, you're not a single page app.
So don't build a single page app building the page. If you can name
pages, you aren't a single page app. Trello is a single page at
Google. Sheet is a single page app. Your e com site is not
a single page app because you've got your homepage, your category page, your
product listing page, your product details page, you've got your faqu's page.
They're all different pages. So a mass Twitter is I mean Twitter and Facebook,
Right, would you say that the feed is one app, and then
because it seems like the the in between is don't try to build a single
page app where you literally everything that you do in a single application. I
agree, that's I mean, that's beyond silly, except that you know that's
what's been done the last ten years and and there's no sense and if you
have a lot of interactive stuff doing server reloads for every single interaction, but
like there is some sort of delineation, like your feed is a single paye
ab, your account settings is a single paye ab, but your feed and
your account settings are not the same ap it. I mean, so so
if I can, if I can touch on that. So we've had Alex
Russell on on the podcast actually twice, and I think we had them almost
a year ago the last time. And the distinction that he kind of makes
is based on the amount of interactions, like is it is it something that
you like click? Like are you clicking a few times to maybe a few
dozen times or are you going to be clicking hundreds of times? And now
I don't remember exactly where Alex draws the line. I know that he's done
a bunch of research on this topic. You you know, you can chase
check his website, which is slightly late I think is No, that's actually
that is handled. I always forget frequently not yeah, I and frequently noted,
so you can check his Yeah, he's he's funny like that. So
anyway, so he's done research on this topic. Uh, and and that's
the delineation that he makes. And I kind of concur with that. So
I don't know where the cluster point is and I wouldn't. I don't use
I agree with him, but the way I've always would, I'm not.
I kind of I've never heard him say that, but I agree with him.
The way I've always described it to my clients is how big is the
feedback route. If you've got Photoshop in the browser, you don't want to
wait a full round trip before you notice the pixels turning green. If you've
got Google sheets, you don't want to notice a full round trip of latency
before sell A and cell B gets summed together. So if your feedback loop
where you expect feedback is instant, then that is what I would consider more
app like if read and write are almost one to one, whereas if you
look at an e commerce site or buying. Yeah, just look at an
e commerce site or a news website. You don't have feedback loops. You
spend most time consuming, especially on a news website, your scroll, you
read, your scroll, you read. That. Didn't want to be a
single page app if you are flicking through an article every half a second,
which you wouldn't ever be doing. But it's not until you're doing really frequent
and you need that feedback loop to be super tight, that you need to
build things in the browser. So I think for the most common news cases,
eCOM publishing, certainly publishing a single page app is not the right process.
Now your checkout flow, that might be a single page app, because
it might be a case of like as you say, it's behind a log
in, it's not indexed anyway. By the time someone's got into the checkout
process, they asked statistically less sensitive. Studies have shown that once people have
committed to buying something, they are more like to stick with it, so
they're less sensitive to site speed. There your check out, So that could
be an SPA. That's absolutely find because by and large every pages the same,
just different form details, your address, you're billding details, discout code,
et cetera. That's where your feedback loop is. Okay, I've got
my credit card in my hand and I'm going to do that. So I
think Alex says interactions. I think I'm saying the exact same thing, which
is nice because Alex is very smart. But I always describe to the clients
as where do you want that feedback loop? Trello, you want to drag
a card from one column to another and see it land there instantaneously. If
you're clicking a related product that's another page, and that feels like the feedback
weroop doesn't need to get anyways near as instant as dragging a card from one
column to another. So going back to the topic of the issues that you
encounter as as a consultant coming in on ICE mostly to assist with projects where
performance is an issue. What are common problems that you encounter and what are
amusing problems that you encounter? Really common problems are things like festicization of things
like microservices, micro front ends, composable commerce, and single page apps.
They're really common. So nearly every site I look at your single page app,
you're struggling with performance, maybe not because of your own fault but because
you weren't aware that co ed vitals doesn't play very nicely with single page apps
at present at least. So I've got loads of clients at the moment who
their sites are pretty fast from a cold start, but the fact they an
SKA means a lot that data gets lost, so they appear a lot slower
than they are. One thing I keep coming across is and two projects in
a row now is composable commerce. And it's like, right, we've got
to make API calls to X different third parties. That's all latency. That
all just goes into time first bite. Paralyze as much of it as you
can, but it's still kind of for the most part, only as fast
as the slowest response. Then you move to like your server, your client
rendered so rehydrates, and you move into the client rendered version, the rehydrated
version. All those API calls now happen on the client side. And I've
seen this in two projects in a row. Everyone loves to have API dot
company dot com on a different domain, which means immediately across origin request,
which means immediately you've got pre flight requests. There are two projects in a
row. Never really noticed it before. But full round trips of latency in
band on every request to the API end point because they weren't cashing their pre
flight requests. These are rare things I see that do They don't amuse me,
but I feel like you designed this problem for yourselves. If you've just
had Company dot com slash API, get rid of all those problems. But
because everyone loves to have a PI dot Company dot com, you now enforced
pre flight requests. Hold on. I want to push back on that.
So can you think of a reason why people are doing that? Because I
know of some reasons why it's beneficial, But like, are you just dismissing
a wholesale or do you think that people don't actually have the problems they what
do you understand what the impetus for the API was other than cuteness, Because
I don't think it's just cuteness, although I'm sure that plays a part.
I don't think it's just cuteness. And I don't have like a list answers
to why. But architectural simplic simplification, Like a lot of companies just hang
things off domain so they can share them internally a lot easier. They can
deploy as their own sort of architecture on its own kind of its own standalone
product. But yeah, I just feel like a lot of problems like that
would be the performance problems it brings. I'd like if we could just stick
this on Slash API slash and using resources like preconnect or something like that doesn't
mostly solve that problem. I mean, you're going to be waiting for the
JavaScript to download in most cases anyway before making those API calls, so you
could at least use that JavaScript download time to pre connect to that API endpoint.
So pre connect wouldn't work because pre connect will open a CAUSE. You
can open a CAUSE enabled connection, but you don't explain why you need it.
So what a pre flight does is it says, oh, you've got
a request headed that we don't We don't like that, you can't you can't
hit us with that request. Did you actually get cores on subdomains? I
forget you do, yes, cross origin and a subdomain is a new origin.
So I've got a client at the moment, and if they just move
from company dot com slash dot, if I move from api dot to slash
API, they would remove all the CAUSE issues because cross origin a subdomain and
a different subdomain, a different port would put you in that cross origin category.
Oh so it's also a different port. No, it's either either.
It's either. Okay, yeah, that you come in issues with local hosts
on that all the time, which is one of the reasons that tell people
to like use domain or whatever. But so for that, I think that
in the modern era, I think that the reasons that we did API dot
whatever don't hold as much water as they used to. One of the reasons
had to do with cookie policies and all browsers that are out there today other
than your Xbox and your Wii have browsers and those you don't really you're not
as worried about, like clickjacking and cross origin forgery of a bank website on
those you know, legacy systems that people still use all the time but are
never going to get updated. But all of the browsers that you have on
phones and on desktops where you're likely to do work work, the cookie settings
are now such that you can you can set a few flags like HTTPS only,
server side only, strict origin policy, you know, a few things
like that, and you can get all the benefits that you would have gotten
by having your APIs go through a separate domain where you you didn't necessarily want
to mix up the chance that your authentication middleware would be allowing cross site requests
via via API and accidentally get authenticated with a cookie when they shouldn't have been
a j You're absolutely right. I'm not really thought about it like you've made
me realized. The whole point of using API dot is you're opting in to
cause enabled requests. You're opting into cause you want cause to stop things leaking.
But now we've got other ways around that. I guess we don't need.
So I guess the whole punk people did use a got was like,
no, no causes a benefit for us, it's a feature. We want
to strict credentials. We want to make sure we don't need anything. So
that's why if we put it on API dot we get all that for free.
Yeah, it's a performance hit, but so you're absolutely right. I
guess the simplest answer is causes a feature, not a bug. Yeah so,
but but I agree. I believe that you can get all of the
same security features today and and be reasonably assured that if somebody hasn't updated their
browser for the last year or two, which is most people that that they
still have that in their browser, Like it's been part of browsers long enough
that I think, I'm pretty sure that it's safe to do. But I
mean, my advice would be, if you're going to tell somebody switch over
from API to slash API slash, that's great as long as the security concerns
follow. Oh yeah, absolute in a replace. Yeah, you just said
something that really amused me. AJ about the note updating your browser, because
whenever I go on my wife's computer for some reason and I open up the
browser and I see that red button saying you must update now, I'm like,
how did you not update? My My wife probably updates her browser about
as frequently as she updates her operating system, which is, when I sit
down at it, I can tell that there's nothing that she's immediately using for
something that can't be restarted from and I restart the computer. So about twice
a year when she asked me to do something on her computer, her browser
gets updated. And that's because she has a techy husband. Yeah, yeah,
I really don't think. I don't think I'm I think it right.
I think it's really easy for people like us, who are very tech fluent
and who surrounded by every day it's second nature to us. But people aren't
in tech. Why don't need to update it? It works? It works,
so title call back in iOS seventeen, I don't care. So basically,
you're saying that the fact that Windows ninety five, I think, like
couldn't run for more than thirty nine days straight without the restart was the feature
rather than a bug that I mean, you know, we give Microsoft a
lot of crap for the you know, your computer is restarting and in you
know, sixty seconds, But they're not. I mean, they are servicing
people who are non professionals and who are you know, they're servicing the lay
people, you know, like the average person you know. So so the
average Mac user is someone who is it like, they're in a different tier
of work or a different tier of economics than the average Windows user, although
you'll be surprised, like I know, like I don't want to, you
know, say anything bad about you know, designers, but I have seen
some that like we're kind of unaware about tech. But tell me, like
Harry, don't you like you know, come into a project feeling all good
about telling them how they should optimize this or optimize that, and then run
into like a twelve megabyte gift that they're downloading, you know, in their
homepage or something like that. Yeah, luckily that's less frequent, and that's
almost always a CMSA too, like a CMSUS uploaded that. So yeah,
I like when I find really impactful, interesting or exciting things to tell people.
But part of my standard process is, let's look for anything silly.
Let's I take waterfall shots and I organize them by largest and smallest resource.
And I once found a one point two megabyte fab icon, and that's because
of the designer who was asked to export the fabicon took the entire spritesheet.
It was back when people you sketch, and it was the entire icon sept
for the entire website, and they couldn't be bothered exporting the fabicon, so
they just set the bounding box to cover the falyc on the neededs and that
the the fabic on the ico ended up being this enormous bank of data every
icon for the site, and it's had a bounding rectangle around there. When
they needed they exported that, it contangled the data for all the others.
Is that right, you've got one point two megabyte faicon after Jesus it was
unwieldy, Well there's your problem, Like just that's really low hanging through.
Yeah. By the way, one thing that I've also encountered in many cases,
like you know, when websites, especially created by designers, is that
they construct the images so like you have something which is an image which should
have been let's say, well i'll call it a JPEG, but you know,
a lossy compressed image. But they've actually because they use some sort of
of the software for actually doing it, and they worked in layers. They
actually create multiple layers, and then they and and they need their transparency because
they're now layering them one on top of the other. So they're all PNGs.
So what could have been one jpeg ends up being comprised of like five
PNGs. Yeah. I mean I've seen back when I used to do a
lot of very front end work, kind of slicing other people's photoshop files.
My biggest gripe when people make flat looking at UIs when I say flatly,
I don't mean the design style. I mean something looks like it could be
a flattened signal image, just a raster image exported as a JPEG, not
even with any transparency by the way. They made the images by layering things
up in Photoshop with loads different blends modes. But I'll have to like isolate
it, flatten it myself, make it transparent, put a background on it,
and then it was all just nightmarish. So like that. Designers then,
and I say designers front and developer as people our colleagues might use sort
of blend modes in the browser to kind of achieve the effect, but then
that just has runtime overhead that can get really sluggish on very heavy pages when
you've got images and elements interacting with each other and the kind of intersection of
their blend modes. So yeah, that's not the stuff I'd tend to run
into very often because I don't get to work on very I love my clients
so much, I love you all very much, but I don't get to
work on very creative projects. Normally it's just a case of here's our asset
library of every product wesell and that's it. I guess if you look at
WIS, you'll see things that are much more creative. Well, one of
the more creative pages that I saw at Wix. It was actually an internal,
an internal website built so WIGS does a whole bun a lot of dog
footing. All the wigs stuff is actually built on wis or as much as
possible, and certainly all the marketing pages that Wix users are built on WIGS.
And I was asked to look at one of those marketing pages back in
the day and they you know, talked about waterfalls. In this case,
it was literally an image of a waterfall. So they created a beautiful page
that had this waterfall running down the entire page, and it was built as
one image that was ten screens long. So so I basically told them,
let's split this image up and lazy load the rest. Something along these lines,
so don't have a really creative thing. I saw somebody gaining LCP that
that wasn't intended to game. That that really destroyed LCP because of the huge
image that, Oh, I know, you reminded me of a funny story
about you broke an image into smaller pieces. So I had a client and
if everyone's watching just looks at like my little rectangle I'm in here, that's
your LC. Let's say that's your LCP image on your on your homepage.
This client was struggling to get it fast enough because the image it was quite
detailed. They were struggling to optimize it enough that it looked nice but was
still fast even if they're preloading whatever. It's all they did because they sliced
it into four images and then put them right next to each other, and
the image loaded like in a random order, but it was about four times
faster because the image each file was about a quarter of the size. So
whichever one of those four images arrived first was the LCP, then the subsequent
three were ignored. It was a horrible loading experience. You'd see this image
go h and it would a bit random, so sometimes the second image will
be first, or the third will be first. Yeah, it is worth
It is worth noting, by the way that in the discussions of the W
three see Web Performance Working Group, one of the items that keeps coming up
is how to deal with images that get progressively rendered, like when should you
measure when? When is the NCP? When should the NCP be measured for
progressively enhanced images? Uh? And you know it's it's one of those cases.
It's kind of hard to say, well, that's a pretty big topic.
AJ was going to say something before we move on. Yeah, do
you know why that happens? That's splitting it up into four made it load
faster. Prioritize one of them a babula, So prioritize it seems it can
give high protis one of them. The compression algorithm is based on pixel with,
so if you depending on how you vary the pixel with when it analyzes
the image, it compresses differently. So sometimes just randomly resizing an image,
you'll get better compression because you happen to hit one of the default boundaries that
will try. There is a tool that you can use. Have you heard
of image optum? Yeah? Yeah, yeah, So image optum will basically
brute force every possible dictionary size in the compression algorithm and find which dictionary size
happens to be the best one. And on an im too mac max it
will take a couple of minutes for a relatively small image file, so it
it really does brute force every combination that it can, but it will reduce
the file size is much much smaller than probably any other program. That's the
other I did not know that I thought you were talking about I thought you
was talking from a browser's perspective, how I think size that is on the
algorithm for me, by the way, in that context, i'd highly recommend
watching that talk from the Performance Now conference. Who was it that gave it?
I need to find it about about how HDP two downloads multiple resources in
parallel, the prioritization. That talk about prioritization. You know which talk I'm
talking about? Was it from three? Yes, it was Robin Marx.
He was talking about, Yes, exact loading up the cutting edge. It
was incredible, it was It was the exact kind of content I lived for.
It was really really good Robin Mark's resource loading at the cutting edge.
Yeah, it's an incredible talk because he talks exactly about that kind of a
scenario where you're using the HDP too to download to you know, to download
these four images effectively in parallel, and it depending on the browser and on
the CDN on the server, it might download faster or it might download slower,
and you know, it really kind of depends. Thest is, if
you download all four images in parallel, you just slow all four of them
down. But if your braws AER and server talking the same kind of paroraitization
language. It'll do image one, two, three, and then four in
order. And that's how you can gain lcp is because you can be fairly
certain that instead of all four images are arriving at the same time, you
get one then two than to read them for and it's we must say that
please don't gain the metrics because you're doing more harm. You're doing more harm
than good. At the end of the day, the metrics. You know,
Google might care a bit, a little bit about the metrics, but
the ones who really care a lot are your visitors. And they don't care
about because the score. They care because of their experience, and if their
experience is shitty, then they will leave and then you'll write it right now.
I had this discussion today and it made me realize something really interesting about
LCP as and Max. I've been saying this for quite a long time,
and I know my friend Andy Davis has been saying this for a long long
time. Largest isn't always the most important bit of content. If you go
to the left hands a website, or you go to the British Airways website,
the biggest bit of content is a picture of an airplane. Most important
bit of content is the form inside of it, so we need starios like
that. I tell clients you need custom metrics as well. Use the element
timing API. We don't care how soon a user could see that picture of
an airplane. We care how quickly they could see the form for booking a
flight. So I've got a client at the moment they have a really they're
LCP sitewide is I think it was two point six seconds. As far as
colle vitals is concerned, we only need to find one hundred milliseconds. But
they read a study somewhere that said somebody else improved LCP by one second and
made ten percent more money, So they want to get their LCP down to
one point six seconds. It's going to be really difficult for this website because
they hit a lot of third party domains to build the page. A lot
of the plages are still client rendered, so it's going to be really difficult
for them to hit one point six seconds. So I said to them,
kind of as a joke, was I know what we could do. Why
don't we redesign. It's an e commerce website. We redesign all the product
pages. So the heading is the biggest bit of content and the image is
really small, then you'll have a really good LCP because text is fast and
images are slow. No, no, we can't do that because weally people
see the image. I was like, so, do you care about the
metric or do you care about the customer experience? What we need to measure
is how should And then I said to them, you don't care about the
largest bit of content. Your image just happens to be the largest. What
we need to measure is how soon someone could see the image. If you
just want to get a one point six LCP, just just to say you've
got a one point six LGP, we'll just make sure your LCP is an
eight to one and not an image nice And we can't do that. We
can't do that. So funnily enough, I was working on a page where
the hero image was only really slightly larger then the title text. So I
said, you know, if if we make the text just a little bit
bigger, my name is just smaller. Yeah. Well, it's interesting because
the LCP. I've read the LCP spec inside out, So I wrote an
article about how to because it comes back. Actually, this brings us nicely
down back to progressive images. But the LGP algorithm also uses intersectional observer to
see how much of the element is in view. So I've got certain clients
where if the if the mobile phone screen is short enough, the hero image
is majority off screen, there is the h one. But someone on a
higher resolution or slightly longer like if someone on an iPhone Mex, then the
image well not on an iPhone obviously, if we don't cat dry estate.
If someone's on a big phone, the image is far enough in viewport that
it becomes LCP. So the exact same page on different mobile devices is really
difficult. So that's why when you look at pay Speed Insights or Crooks and
it just says desktop and mobile, it's really important to remember that inside of
desktop and mobile there are also a lot of varieties. What I'll find is
I don't like Lighthouse as a tool for me professionally, it's too simple,
it's too basic, But clients love it. Web page tests their mobile devo
vice screen sizes are smaller than Lighthouse. Yes, I'll run a Lighthouse test.
Yeah, I'll have like to run a Lighthouse test and it'll come up
with a different LTP to the webpage test that I'm running, so there's loads
of disparity there. But yeah, I read the spec inside out, and
the first thing it does, or one of the first things it does,
is it calculates how much is even on screen, because if the image is
bigger than the h one, but the image is majority of screen, like
you say, then we just don't count what we can't see. And that
brings on to the progressive images thing, which I think it's been a frustration
for years. There is no there is no even though customer experience is better,
there is no benefit to performance scoring using a progressive japeg, which I
just think is unfair, or any progressive format. Yeah, I agree.
Why would you want to use a progressive j peg because you get content,
You get meaningful potentially meaningful content on the screen faster, do you really?
Because I remember progressing JPEGs and they just kind of sucked, So you'd have
to you probably want to do You're probably want to build them yourself. So
they contain scams and you can pass in a scan file to your batch process
your images, or do it all in bulk whatever. But what can end
up happening is the image. The progressive jpeg in beds like eight versions of
itself, and the first ones will look really disgusting, and that's not a
good customer experience. You're probable to build a scan file that says, just
build me three scans like medium high, very high quality, and do it
that way so you avoid the really really low quality end of progressive JPEGs and
just opt into like medium high and super high res. That's what I tend
to do. I think I could buy into that if there was a way
for the high DPI displays to know to pick the like for it to just
not bother loading the super high res one unless it's high DPI. Well,
you can with the image tag, with the picture tag or the image tag
even these days, with you can specify images to be associated with it with
the device's DPI. The browser is smart enough. So then why wouldn't I
just use the picture tag and use multiple JPEGs rather than a progressive each each
one of those complicated Yeah, each one of those multiple JPEGs would have multiple
JPEGs inside it, so for every use case you could potentially for every one
of them have a slightly faster LTP. Progressive is I think sort of a
real benefit. I'll give another scenario. I'll give another scenario another thing that
I encountered with so lot are people building their website. Let's say with white
background, a dark background image and white text, and then what would happen
is that until the dark image would actually load, the text would be white
on white. So the text would be there, you just couldn't see it.
So even have so at a certain point in time, we actually would
have like image placeholders, kind of like what you get in like in YouTube
style thing. But or I think Medium kind of introduced was with the first
Yeah, to introduce that just so that you could get you would get the
feeling that the page how the page should look like, and see that text
faster than otherwise. But but I do have a question before we were running
a long and I do and there are a few questions that I did want
to get to talk about because I assume that with at least some of your
customers, you're running into scenarios where let's say you've got poor ironp but looking
at the site, it's because they have a lot of let's say third party
scripts or pixels, and then you say, well, you know, you
want to improve INP get rid of your pixels or get rid of half your
pixels and say we can't we need them for our marketing campaigns, or alternatively,
their score is poor because they're using like some sort of heavy framework,
client side rendered whatnot. Like, what are you going to tell them rebuild,
re architect your entire solution? Like what do you do in those scenarios?
It's yeah, it's difficult. It's really difficult to advise because the answers
are very complex. And one thing I find really interesting is if you read
anything on web dot dev, this is always the same break up your long
tasks. It's like, well, how step by step, how does one
break up a long task? Be goes? If I've got a function and
JavaScript runs like run to completion, so function can't be interrupted or paused halfway
through. It has to finish. So if you've got a click handler that
has to do x amount of work, telling someone to break that up is
really difficult because well when do I do it? So what I try and
tell clients is it's just gonna be really difficult, It's gonna be hard to
do. But the biggest I was with a client last week. The biggest
culprit of theirs was they did loads of synchronous Google tag Manager stuff. On
every click, they track everything. Someone clicks the menu open, it gets
tracked. They close it again, it gets tracked. They click in the
soot field, it gets tracked. They don't type anything that gets trapped,
and all of that is like that measures like okay, ten cent of people
who enter, who clicked in the search box never typed anything, so why
why didn't they type? So it's valuable business data, but it all happens
synchronously. So for them when the biggest things, and like you say,
it's a third party tag manager, is just fulfill the user need immediately and
then sling all of that tracking work into like a set time out or request
idle callback or you know soon not these schedular got yield. So to look
for the obvious things. First look for the obvious things like okay, tracking,
move that into the next task. When you still end up with a
task that's really large and you can't break it down any further, it's really
hard to work out what if you've got a function it needs to necessarily do
quite a lot of heavy lifting. That's when you start to get into trouble.
And I'm not. I'm not. I will admit i've been a first
person's admit on a JavaScript podcast. I'm not a very proficient hardcore JavaScript developer.
I never have been. When it comes to breaking up long tasks.
All I can really tell clients is I can show you the tooling, we
can look at what it's doing, but you need to decide, like which
of this thing needs to happen immediately, which of this needs to happen for
the user? And what can you do safely elsewhere right party If you've got
really agreed times, that's actually what's That's actually what we ended up doing at
Next Insurance for our currently work. So we had like treat not terrible but
kind of mediocre I n P. But we were really anxious about having good
coed vitals across the board even when I and P lands. So we introduced
party town and the improvement was dramatic. So now we really have excellent I
n P. But aside from maybe third party scripts, like, I'm really
surprised when people have really long tasks. I mean unless you're building a really
sophisticated web application that does something you know, like super heavy, in which
case you know that kind of brings us back to the web applications where you
where these issues are kind of different. Then I'm really surprised at having really
long tasks like what are you doing like computing pie to the millions digit what?
Like? What's what's all this computation about? Do you know what?
I've got anyone listening? I am for hire and ironp ticks in on the
twelfth of March, so get in touch. But I've got a full section
of my workshop that starts out with we always blame JavaScript, and you know,
like JavaScript is yellow Indeed tools, it's a big yellow slide. We
always blame JavaScript, and the next side is purple for layer and recout style.
But it's usually going to be a CSS with IP. What you'll find
happening all the time is got to be some synchronous layout threshing. So the
JavaScript cope head might be quite minimal, but you know someone's getting I had
a client where they had a list of two hundred and fifty product images and
they want to line the image wits up with the image with an element outside
of that instead of getting the wits of the element outside and then applying that
with to the two hundred and fifty images. They got a NOE list of
the images. Then for each one, have e's image, make it that
big, have eximage, and they did that all synchronously. Took five seconds.
Layout thrashing, severe layout threshing. So oftentimes what I find and what
I try and tell clients and developers that in training, everyone's clicked to blame
JavaScript. But seriously, go and look for your purple and then purple is
going to be either recalut style or it's going to be layout im in the
right order as you're looking at them. Recoup style layout. If you've got
long recount styles and short layout, that is because you've got complex CSS selectors,
or you've got a lot of CSS, or you've got a lot of
HTM out. If you've got a long layout task that's going to be structurally
the page is quite complex to layout. You might have a lot of overlapping
things. You might have a lot of grid or FlexBooks that relies on each
other, so very heavy as to describe it. Pages that look like tables
of data but aren't that are built using things like flexbox. Generally, you
want a simple by the layer of the page. There make sure you don't
add things to the DOM, but the dom wider. So a lot of
the time long tasks are going to be CSSE recock style and layer I recock
styles. Your cost going look at the cost of your CSS selectors, the
amount of CSS or the size of the CSS object model, and the dome.
Yeah, two points I'd like to mention. So in the context of
we talked about layout thrashing, one of the things to take into account is
force three flows. It's like you you kind of mentioned it. It's,
you know, a quick explanation. When when you modify the DOM inside JavaScript,
then in most cases the browser will try to not relay out the page
until it absolutely has to, So basically it will try to run all the
JavaScript and only then when the JavaScript is done, actually apply the layout changes
that result from the DOM changes you've made. But if you if you kind
of ask the browser the dome about let's say, the size or position of
an element, you're kind of forcing it. You're forcing its hand, You're
telling it you must apply all all the changes that you've done in order to
be able to answer that question. That's called a force reflow, and layout
thrashing is when you set something ask something, set something as something, and
you're forcing the browser to reflow like on every iteration of the loop, as
it were. So in that case, it's it's beneficial to break it into
even two loops, like do all the sets and then do all the gets
or or something or or do all the gets and then do all the sets
whatever, but don't interleave the gets and the sets together. And I had
a similar situation, but you know, we don't have time to go into
the details you kind of described it. The other thing I'd like to mention
is the CSS content visibility at a setting, which you can if you have
a super complex page, you can at least say, well, all these
areas that are below the fold, you know, you know, don't try
to lay them out now because nobody sees them. And if you know that
they can't impact what the user is actually saying, then that can really speed
up that sort of thing. Yeah. Yeah, I've got a really it's
a nasty CSS selector, but I used it on my I profiled it and
it turns out even the nasty CSS selector is faster than the cost of laying
out long blog posts. I've got certain articles on my site there tens of
thousands of words, really really long. Most users aren't going to scroll all
the way to the bottom, so most people aren't going to see everything.
So I've got a selector which is main content space H two till the H
two. So any H two you anywhere after the second AGE two, or
you could do H two ent of type two. Everything after the second H
two content visibility auto. So everything after the second H two. So you've
got an H one, an H two here, maybe an H two here,
that's going to be pretty far down the article already by the time you're
at the second H two, you're quite far down. That's what I do
is I say put content visibility also on everything after that, so the majority
of the article never gets rendered until something starts scrolling towards it, and that
more than halved layout costs for me on my particularly long blog pages. The
only downside is, unless you're careful, you can get weird effects with the
scroll bars. The scroll bar like rows and strains. You've got visible scroll
bars. Yeah. The best way to check if that's working is go to
the layer's panel and if the document layer is rendered really short or not really
short. With the document layer is rendered, say maybe fifteen thousand pickles tall.
Then you scroll all the way down to the bottom of the page,
then go back to the layer's panel and it says, oh, it's actually
seventeen. That's how you know it worked because the layers pannel is what the
brows actually rendered. So try this hack. Go to the layers pannel,
see how big the document layer is. Then go back to your browser,
roll all the way to the bottom of the page, go back to the
layers pannel, and if that figure has changed from fifteen thousand to anything else,
it means the trip worked. But you're absolutely right. If that number
is very different. Let's say let's say rendered runded fifteen thousand, but then
it ended up being forty five thousand, that scroll bar is going to get
a lot shorter. So so two things. So first of all, there's
also the content what's it called intrinsic layout height or something, which you can
kind of use to contrinsic layout. Yeah. And the other yeah, and
the other thing you can do is that when the user scrolls, you can
remove the auto or something along these lines and they change it to visible,
so there'll be like a jump when they start scrolling, but at least that
will only or at least you can know something a on these lines, So
you're you're kind of it's it's all built on intersection observer anyway, so you
could hook into that and say, as we get closer, turn it from
also sensible or but that happens automatically. But you're absolutely right. If you're
going to do this, you need contain intrinsic size. To say, every
paragraph is roughly three hundred pixels tall, so every element you put contrain containing
intrinsic size one pixel by three fifty or whatever, and that that should minimize
the jumping that you're describing. Yeah, I think I think we need We
are nearing the end of our show and we need to move into picks.
So is there anything else you really would like to mention? Honestly from me,
not much at all. Just i NP is the next thing to worry
about for most sites that are benchmarking core went vitals. So if you haven't
been taking it seriously already twelfth of March, if you haven't seen the announcement
yet, if you don't know where to look for your I m P scores,
ask your marketing team or your SEO team or whoever's in charge to give
you access to search console and go look for coll ed vitals in there,
and I'll tell you how to start looking. And you need any help with
it, you can always get in touch with me. You can tweet at
me. I've got some resources around IMP. That's the only real pressing thing
that's on my mind at the moment. Do you know, as long as
Google invent a new metric every two years, I've got a job for life.
Well, the next one, I think that's the next big change that's
probably going to land is when they start they make soft navigations official, so
even like in multipage application single page applications, they'll start measuring the navigations between
pages that happen on client side rendered apps. But I don't know what the
impact will be. Will it make scores worse or better? It'll be interesting
to see. Yeah, I think better. I think sites will get it'll
be easy to optimize them and the scores will get better as well. I
think that's my prediction. Time will tell. All right, I've got a
hard stop that was thirty seconds ago, So let's go ahead and wrap up.
First of all, Harry If people want to find you, where should
they find you at? Regressively, CSS wizardry everywhere, so mastered on or
X, or my website or email Gmail. If anyone needs anything, we've
got any questions or wants any of the resources that I've spoken about, you
can find me at CSS wizardy everywhere. All right, Thanks. Now with
that, we'll go ahead and wrap up get to picks. Picks are where
we just talk about something that was interesting or that we liked or that's on
our mind that could be dech related or not. I will actually go first
this time. So we talked about image optim so I will drop a link
to image optim It is, like I said, the best tool as far
as I'm aware, for being able to resize images so that they're sid Well.
Yeah, it's brute force effective. So yeah, yeah, yeah it
does. It does way better than it. It just takes a long time,
you know, you just sit there and you wait. Okay, So
there's that, and then of other things. I've been playing around more with
Home Assistant. I now have it to the point where there's a sensor downstairs
and I've almost I have the path to get it so that the temperature is
changing based on the downstairs temperature. The thermostat is turning on or off based
on the downstairs temperature rather than the temperature that's in the thermostat itself. I
just I don't have it quite working yet because I basically have to set four
different events of like if the temperature goes here, if the temperature goes there,
turn on turn off. If it goes here, if it goes there,
turn on turn off. But I got one of the events set up,
so I know I can set up the other ones. And then I
just ordered. Ikea has Zigbee stuff, and so I just ordered some of
that and I'll I don't know if i'll get it this week or next or
whatever, but they've got some switches and whatnot. The thermostat is z Wave,
the temperature sensor is ZIGB. I'm using the Home Assistant made sky Connect
for the Zigbi devices and some I can't remember what it is that they recommend,
but it's on their website. Is the one they recommend for the zwave
devices. And so well, we'll see where all this goes. It is
a pain in the butt to set up, but if you are looking for
an alternative to a smart home, without all of that data being constantly monitored
and stored by Google and Amazon. There's a path. It's it doesn't seem
like it's a pretty one. It seems like it might be a really good
market opportunity because I just don't Ikea actually has a smart app. I haven't
tried it out because I don't really want all my data going to Ikea either,
because I'm sure that they don't. They're not even really a tech company
per se. So whereas I at least trust that Google spying on me privately,
you know, Ikia will just get hacked it. All the data will
be out there unless they're maybe they're keeping it in some Ikeia cupboard. Yeah,
so so anyway, and then I don't I don't recall if I've been
talking much about the aquarium stuff that I'm doing, but it's just so fun.
It's such a good hobby. So I've got two aquariums set up,
and I'm I'm going to set up a few more and try some different things,
different plants, different fish. I kind of found the fish that I
like. H One is just referred as autos, and they are bottom feeders.
They they must have algae in order to survive. So if you don't
have algae in your tank, it's actually good to have a little algae in
your tank. But if you don't have algae in your tank, you gotta
put in some fresh vegetables and let them let them, or blanched vegetables and
let them eat that. And then then the other ones are the the neon
tetras. They just look so cool you have to buy. They say at
least six of them, but I'm gonna say probably at least ten of them
because the schooling behavior that you want to see. What's cool about them,
other than they look beautiful, is that they swim around together. And if
you only have six of them, they don't they're not gonna do it as
much. So you gotta get you know, probably ten of them. And
they say you need like a you know, ten gallon tank for six or
a twenty gallon tank for more, but you know, if there's room in
the tank, you can put ten in a ten gallon tank. It'll be
fine. And then I've got a mystery snail and a fancy guppy and they
all they all are in our main tank. Well in our main tank.
It's not a fancy guppy it's a beta, but the beta is a mild
tempered beta, so it's not attacking the other fish and the autos or bottom
dwellers and the the neon tetras or mid dwellers, and the beta is a
top dweller. So they they kind of have like it's only a ten gallon
tank, but they have enough space that they don't have to to, you
know, get in fights with each other anything. But it's just it's it's
a really cool hobby. It's it's uh, I'd recommend it, and it's
it's just it's therapeutic to you know, it's art. You know, you
build the tank. You're not just throwing in some gravel from from pet Smarter
Petco and then dropping some fish in. You know, you'd like you gotta
select the aqua soil and you you know, you pattern the sandy way you
want it. You put a hill, you put some stem plants, you
put some other plants. It's just and then and then you actually have less
upkeep than if you were to go the you know, the typical gravel you
know, painted gravel route, because then the right bacteria in there, it
becomes an ecosystem and it all cycle although there is a little bit of prep
work you have to do to let the tank sit and cycle before you put
the fish in so that that the right bacteria are there to help them live.
Because if they're not there, then the fish, the first fish you
put in the tank, if you don't know about that, they'll die.
Uh. But anyway, like there's there's less upkeep once once the ecosystem is
going, you know, very very little feeding that you need to do,
very little cleaning that you need to do, you know small. You don't
change the whole tank. You just do like a ten or twenty percent water
change now and then. But it's it's it's it's very it's it brings joy
to my life. So you can pick the aquarium hobby and with that I'll
pass over to Dan. So I like my dog dogs, fish beat fish
any the other week in my in my book, but that's not my pick.
So my first pick, you know, how can I not pick it?
So? Uh, you know, it's the Apple Vision Pro. I
don't have it, I'm not planning on getting it anytime soon, but from
the videos I saw I've seen, it's simultaneously amazing and ridiculous, So you
know, I got to, you know, to to say that it's it's
a brave product, but I'm just not seeing the killer app for it yet
and I'm not and people, you know, I I've seen people like videos
of people walking with it on the street, like that's like an invitation to
getting beat up. I think, yeah, anyway, So so that would
be my first pick. My my second pick is we're watching uh this show
on uh on Netflix. It's called Griselda. It's not like a great show,
but it's it's nice. We enjoy it, like if you're into the
Narcos kind of thing. Uh, It's it's interesting. It turns out that
she was like a drug kingpin in Miami in the seventies onward, and it's
a TV show with Sofia Viergawa is actually, you know, playing pretty good
in the lead role and it's fun. So that would be my my second
pick. And oh, one more thing that I wanted to pick. So
when we discussed recording this episode, one of the things that I initially hoped
that we'd get a chance to talk about was cashing rules. But since we
haven't gotten around to it before we run out of time, I would like
to recommend Harry's from the Performance Now conference, the twenty twenty three talk about
cashing, rules, everything, and I had questions I wanted to ask,
but I'll guess I will save them for another day. But in the interim
I highly recommend that talk. And finally, I'm like hoping for peace in
the Middle Eastern Ukraine and that would be will be my pick for today.
So over to you, Harry, if you've got anything that you'd like to
shout out about, anything at all? Yeah, so nothing, nothing specific,
nothing as relatable as yours. I'm missing cycling. I had a lot
of cycling, but the weather's just been terrible. So that's me. My
next thing to focus on outside of tech is getting back on the bike.
It's hanging on the wall, just looking very very lonely and unused. I
was obsessed with cashing last year, so sort of summertime onwards. I just
got obsessed with cashing because I had a client with some real cific cash problems.
That was my tech obsession for sort of fall and winter last year.
My new obsession is memory management. I've got a client who's trying to depug
memory leaks. They don't care about col ad vitals. They don't care about
load times diameter. The browser. Memory leaks in the browser keeps crashing their
their android app is a webz and it keeps crashing the android app and customers
are complaining. So I'm now obsessed with the memory panel, which is very
underdocumented, and yeah, let's talk. Let's talk about it because I'm actually
doing similar work. We've got some issues with node based services. Uh and
and ultimately you use the same memory panel, you take a memory dump,
and then you effectively use the same panel. So I it's it's yeah,
it's it's not an easy panel to use, but it's fairly rare that you
run into real memory issues with with browser applications. You know, we should
probably talk about it, you know, schedule some time after this podcast.
I'd really love to hear about some of your insights and maybe I can also
make some suggestions. So maybe we should schedule about it. Yeah. I'm
new to my performance management journey, but I'm writing a talk called memory management
for mere Mortals, where I am the mere mortal and I just talked about
Okay, I had a client who had this. I even told my client,
I don't think I'm the right guy for this job. I do very
web like loading performance. I don't do like No, we're committing the right
person to this job. So I did all the research and I was like,
Okay, we can do it, and found some really interesting insights.
The memory channel hasn't really been changed for nearly ten years, maybe longer,
but that's what I'm obsessed with at the moment, so I might either write
a blog post about that or that. There's definitely a talk upcoming, yeah,
Dan, if you want to talk about it specifically after this, Daniel,
let's that's we can probably a good idea. I'll ping you on on
X all right, Well, all right, well that thanks for coming on.
It's been great to have you, and you know, especially have you
and Dan going back and forth and dropping all those knowledge bombs on us and
we uh hope to see you again. Yeah, it's been great. I
was very privileged to be invited on. I've seen I've seen the podcast for
years now and I've finally got an invite, so I'm really grateful. Yeah,
all right, well we'll cut you later. Audios