Polish and Perf

Welcome to Syntax.

On this Monday, hasty treat, we're gonna be talking about polish and perf.

We wrote the thing. We pushed the thing out. It exists.

Now let's go ahead and make this thing nice and shiny. My name is Scott Talinski. I'm a developer from Denver. With me, as always, is Wes Bos. Hey, everybody.

Excited to talk about polish and perf.

Yes. Polish and perf. Polish and perf. You know, polish and perf is something that we all have to do as developers. We have to get things out into the world. We have to have them working, but the most important part after you have that is to have it be a nice fast smooth experience for your users.

And this is more than just bug finding and error finding. This is oftentimes really getting down to the heart of what's causing performance issues.

Now there's a whole ton of different things that could be causing performance issues. But at the end of the day, the big thing is we wanna make sure that our pages are snappy, responsive. They load in a reasonable amount of time, preferably as fast as possible, and we want them to, you know, give our users the experience where they're not just clicking and waiting for a couple seconds. Right? The the world of spas gave us a lot of, like, really great, immediate functionality in many ways, but it they've also given us a lot of loading spinners. So what can we do to reduce the amount of loading spinners we're looking at and reduce that network, network issues that you might be having. So, you know, we got this thing released. I I've Speaking from experience here, we pushed our our site out. And, when we pushed out, it didn't have great page speed scores. They were fine, but they were they weren't great. Right? End.

It was important for us that those were good, but it wasn't important for us that they were perfect. Too oftentimes, you see people with, like, a a fully white website that does nothing, has no images or resources, doesn't have a database, and they're like, I got a I got a 100,000 on light speed. It's like, who cares? Like, that that's fine. You know that? Yeah. This web should should have a 100,000,000,000 on light speed. It should Because you're not doing anything. But when we get into, like, really complex stuff, there are sometimes, things you have to be cognizant of. So If if we're wanting to reduce page page speed times or if we're wanting to increase page speed times, reduce that amount of latency between when you hit a a link or when you refresh your page.

Where do we start first? And what kind of tools or what kind of things do we have, to to use at our advantage.

So me, personally, I I'm spending a lot of time in the network tab because the network tab reveals a whole lot about your application besides how much JavaScript or HTML or any of that stuff you're loading.

It's also revealing how long things are taking. How long is that server trip taking? Is the server the problem? Right? Are you doing something and you're having a huge amount of time before the server finishes responding? Well, then you know it's your server and your API that you need to dive in more. Or is this asset taking a long time? Is it massive? Are you shipping a massive amount of JavaScript? Some of those things can be removed. Some of those things can be tweaked to load less JavaScript. Are you shipping big images when you don't have to be shipping big images? Maybe you're on mobile and you're shipping a giant image to somebody like a, you know, a 1000 by a 1000 pixel image when you just straight up don't need to be doing that. Personally, myself, I've been going,

there's a PR right now for all my sites, and I'm stripping all of the Twitter and Facebook JavaScript from the thing and just replacing them with anchor links that open in a new tab because Yes. Honestly, I had it in there because, like, the idea early on is you can run Facebook ads and retarget people. And the reality of that is, a, Almost everybody who visits my website is blocking all these things already, so they don't work at all, and, b, I'm not using them at all.

It's kind of annoying to have, like, broken embeds and buttons and stuff like that. So just one of those things. You can make a tiny little thing and it will speed eat up the page significantly, especially when you're looking at all the vitals that you pay attention to. Yeah. Totally. And, you know,

This is definitely like a in general, just a a process that you kind of like you look at what are these things that are the heaviest, the most obnoxious, and what can I I take 1 by 1? I found to me in the same regard to what you're talking about, the Discord embed is killing me. It's it's like every single, like, downtick I have on page speed right now is because the Discord Iframe is doing bad bad things, and it's loading a ton of JavaScript. It's taking a long time to load.

It's it's loading up extra fonts. It's doing this or that. So I'm the next step for me is killing the Discord iframe completely and just doing it as an image like we had before. Because it was like, oh, this would be nice. You could see how many users are there, how many people are aligned, those types of things.

Yeah. But it comes at such a cost that, I I mean, I don't I just don't need. My users don't need that, and it's it's causing extra load for no reason. And you could put it you could lazy load it or do anything like that, but it's not necessary.

You know what I ended up doing with my Instagram feed on my website? It was not being loaded by almost anyone because everybody was blocking,

Instagram. Facebook ads.

And also Like, I also don't want even a simple image source embedded from Facebook onto my own website, I don't feel good about that because I know that Facebook is using like, that's a that's a tracking vector. Right? So what I did is I just wrote, like, a little proxy that will Intercept that request and then serve it up on something that I know that has no, no tracking in there. And it also cached the image as well, which is really nice. So what you could do is you could just run a serverless function, take a snapshot of the discord embed, and then serve it up as a, a a JPEG and then embed that. And then that way, you could you could like, maybe once a minute or once every 10 minutes, you could you could clear the cache and rerun it, and then it's just an image on your end.

Yeah.

Yeah. There's a there's a lot here. And okay. So other tools we might have before we get into maybe fixing some things. Lighthouse Lighthouse exists inside of your, Chrome browser. If you use Chrome, you inspect element. 1 of the tabs is lighthouse.

If you're not seeing it, there's some 3 dots in the far right. You can click that and then look for more tools, and then it should be there if you're not seeing it there. And it's listed I I thought this used to be listed as audit, but now it's just listed as Lighthouse. So, Lighthouse will run page speed stuff that won't be able to tell you exactly without running page speed. You can use page speed.web.dev.

Put your your URL in there and crank it out And see exactly what is there to be fixed. Oftentimes, it's going to tell you in plain English, hey. Your images here are too big. You're serving up a 1,000 pixel image when it's only, like, actually being rendered at the width of 300 pixels or this or that. It's going to tell you so many things. And at the end of the day, What we're looking for in performance is we're looking for visibility, and we're looking for big things. So we we get visibility via the network tab, via Lighthouse, the page speed insights.

I also use this browser called Polypane, which we've talked about on the show before, Where it will give me accessibility issues. It will tell me tab order and do those types of things as well and and on the the polished side of things rather than the perf side of things. But what you're looking for is you're looking for big things. Right? We're talking megabytes here. When you get into things that have MB next to them, whether in your network tab or whatever, that's gonna be a huge source of you to fix things. Because what's the point in shaving off a 100 kilobytes of JavaScript if you have, you know, a 2 a 2 megabyte, that could be shaved off of an image just by running some basic image compression.

There's a lot of image metadata removal and compression tools out there that you can work into your build tool. We use something like Cloudinary ourselves to do that. And the coolest thing about Cloudinary because, you know, I I don't always recommend hopping on services for everything. But whenever I had a single issue with an image being too large or anything, I moved that image to Cloudinary. I told Cloudinary to serve the auto width of that image, and I told it to serve the auto format of that image. And guess what? Our images just got, like, decimated, like, 10% of the, original size of those images. And therefore, Those are gonna be some of the biggest things when your users are trying to load your site in a slower environment because that's media. Media takes up a ton. I mean, we're a video streaming service, so our our needs are maybe a little bit different. We kind of assume that you're working with a little bit more Internet if you're doing streaming video, but we don't wanna Be serving people unnecessarily sized things if they just straight up don't need it. So look for the things that are big and make them smaller It's a good strategy.

Next one we have here is identify route caching and configure HTTP caching.

This is is pretty key is just by setting the correct headers on specific requests or specific types of requests like images and whatnot.

You will both cache them to you your user's browser. But also if you have a CDN sitting in front of your website, then your CDN will We'll cache those and spread them out throughout the world. So, for example, if you are caching, an image That is probably never going to change on your website like your logo. You can probably cache that for 30, 60, a 100 days, And, that will be populated throughout the entire world, and that just will download so much faster on your user's a website. It's a it's a shockingly low hanging fruit that people ignore.

Caching is one of those things you spend time into. You understand caching, and you will really see a big benefit from it. I think people were, often kind of shocked sometimes at how the how fast the 2nd or third load of some sites it's gonna be. And, you know, why why not cache everything as much as you possibly can if it if it's able to be. Right? You're saving all that bandwidth.

Also caching on the data side of things. We use a data on a server side cache. We use a Reddit store To cache really heavily used queries, queries that aren't changing that often and, you know, perhaps, like, a user a session or something like that, the type of data or user information we're caching. We're updating that cache when the database updates. We're we're keeping those things in in connection. If you're working with tools like GraphQL or anything like that, it can be made really easy using data loader patterns with caching via Reddit store. We used Mercurius, which is a GraphQL API to do that for us, but I'm sure Apollo can do it just fine as well. Any of those types of things can be made super easy. So that way, again, if you're not having to run off, do an operation on your your database, You can just check to see if it's in the RAM cache. Anyways, if it is, then just load that up. Right? Sometimes that can be really, really freeing, but you have to know that that's the problem first. So When we talked about checking out the network tab, if that request is taking a long time on the server side of things, then you need to start hunting in what's taking a long time on the server. Is it something that I can cache and make faster, or is it something that I'm doing that's dumb? Yeah.

I think probably the first thing you can do on your website is just go to your website, Open up dev tools, and then hold down shift and click the refresh button.

And in your network tab, it will stream All of the resources that are being downloaded. Then you can sort that by transferred. The they'll tell you both your size and the transferred. You're more concerned about the transferred size Because, the actual size of the file might be significantly larger than the actual transfer size, and that's because of things like, what is a broachlee? What is the other one that everyone uses? Gzip.

Gzip. Yeah. Yeah. And basically, you're They will transfer smaller over the wire, and then they will unpack it once they get to the browser. Kinda like a zip file. Right? And, basically, if you just if you just sort those by largest ever. Like, I'm I'm going on on westboss.com, and I am sorting by largest to smallest.

And I see that my by far, my largest file on the page is the Syntax logo, Which is it's 500 k. That's way too big. That's way too big. Yeah. It doesn't need to be. I could that could probably be, like, 30 k. You know? So, like, I oh, I didn't didn't catch that. You know? I just let me just go quickly fix that, and it will be Probably much faster to load my website. Yeah. And stuff like that might even make a big like, sometimes I'll tell Courtney. I'll be like, I saved I shave the whole stack of

the majority of my page loads. And she'll just be like, yeah. But didn't you do that before? I'm like, well, I'm I'm trying to make it faster all the time. Like, that's, like, the whole thing. And you might not even notice this, but you chip away, you chip the way you chip away, and then at some point, you're saying, alright. This is probably good enough. Right? This is probably, the point where you could say that this this thing is fast enough for most users. But you are trying to save people bandwidth. You're trying to save people time. You're trying to make people's experience on the site better at the end of the day. People have a more favorable experience. You know, there's some websites that you use that are just half they don't have to be slow, but they they can be slow because you gotta use them anyways. Like, my bank's website. They don't care if it's fast because I have to use it anyways.

So they're not they probably aren't hunting down this kind of stuff. Right? But if you're trying to run a business, it's important to have the thing be fast.

Another interesting thing is this whole Partytown business. Have We've talked a bit about party tone so far. This is not something that I've implemented yet, but, you know, it's something that I've thought about a lot. Party tone is a tool That will allow you to, like, offset your external dependencies into a worker kind of utilizing multithreading, like, essentially multithreading in a web application. Right? And the the number one thing they say to do this on is Google Analytics. So, this is something that seems like a free win to me, so I'm going to I'm gonna give this a try. There is some SvelteKit documentation on how to do this. It seems really straightforward, But you're basically just taking some of these third party dependencies and nonessential things like analytics, and you're moving them into a, a a worker here so you don't have to a service worker so you don't have to, like, actually load that up and have it be working on the main thread of your application. So stuff. Seems like an easy one. Another thing you can do is find unnecessary network calls. This is one I

oddly found or somebody had had found was On Chrome, for some reason, because I was using style components every single time the whatever component that the style was in rerendered, It was redownloading my fonts and not not even no. It was downloading them from cache, which is not a big deal, but it was causing, like, a flicker. And then I was thinking, like, well, what happens if somebody has cache disabled? You know, like, why is it redownload them? And I I traced it back to this very odd issue with just, like, Chrome in general. So I found a workaround, which is fine, but, like, just little things like that. You gotta keep an eye out for it, and it's worth having the network tab open, clear

everything out, and then click around on your website just to see if anything, like, odd pops up. Yeah. At the end of the day here, the tools are gonna be your friend because the last thing you wanna be doing is just sitting and refreshing your page and be like, oh, I feel like it's faster.

That's not going that's not going to help you. So whatever it is with the network tab, using page speed tools, those types of things, Run these things, get yourself some visibility, and just start knocking off the biggest errors. In page speed, a lot of this stuff will tell you how severe these issues are. Knock off the most severe ones, the knock off the biggest things, the biggest network request, the longest things, the things that take a long time in your stack, get that visibility, and get your site Nice and performant.

Are are there specific stats that you are watching or are going to be watching as you as you work on this type of thing, like page speed insights, core web vitals. Is there any any specific number? I know the big one for a while was the the perf number on desktop. Remember, Ryan Dahl tried to call me out on On, mine not being super high No. I don't remember that. But Ryan ran my website through, PageSpeed Insights. He said he got, like, a 42 or something like that. Mhmm. And, I just I just reran it, after I I did all my Gatsby upgrading. I'm at a 90 6 now, which is, I think oh, it's lower on desktop, mobile.

Mine's lower on mobile, but it's some image stuff. And I haven't removed the Discord stuff, so I'm getting, like, hammered. My main number is getting hammered from, like, 8 things that are related to the Discord thing. So, I'll remove that and rerun it before I start worrying about it too much because, again, What I'm worried less about is a number telling me that my thing is okay, and I'm worried more about, like, what those page or what that network, when I'm refreshing my network, cached and uncashed, mostly cached because Yeah. You wanna see what the real production users are actually experiencing.

And I'm just checking out those numbers. I'm running the site. I'm utilizing the site. Like I said, I built some, like, logging into my like a SvelteKit middleware into my request hook into my my request hook overall, and it just outputs a little emoji based on how fast site how how fast most of the requests are.

If you give a look at the logs, you could just see quickly. I'm seeing a lot of turtles. It's it's like the most, like, lo fi way of of seeing it. But, no, There's no one specific number because all the numbers come with a caveat.

The numbers come with the caveat of this thing ruining my life, the Discord ruining my life, or whatever. So I can't necessarily look at that number and say this number is indicative of the speed of my site. I just updated

my the Syntax logo. It's building right now.

So hold on 2 more seconds and we'll see how much did I save.

Knocking it out on air. Build build build build build.

My build times have gotten Significantly faster on the latest Gatsby as well, which is really nice. Oh. I do wish for it to be instant, though, because it still is 3 or 4 minutes. Mhmm. I want it, like, immediate.

You know? Mine are pretty quick. I mean, they're they're fast. I want it as I type. Well, how long does yours take? Like, a minute, maybe. Oh, yeah. That's that's ideal, but it's a big site. My personal website is or sorry. My my course platform is, oh, 3 or 4 minutes as well. Mhmm.

And I really want to get that down. And I think the move for that is moving to serverless functions that have, like, It will just deploy the 1 serverless function.

Not not a big, big deal, but it would be nice to Have it in sync? Because sometimes you fix something in in like, you deploy it and you're waiting around for 5 minutes. Yeah. And then that's no good. I refreshed. I I resized it, and it is no smaller.

I love it. Why? Why

is that? It's not cached.

Oh, it is. It is.

Okay. Okay. There's something there's some weird caching in here. Anyways, I will fix that. Go to westboss.com and See how small I get the syntax logo after this show, but let's let's wrap it up. Yeah. I bet the, scotttellinski.com

bet. I bet this site gets a 1,000 on page speed because I'm dude not doing anything on it. It's just text and a logo. So, okay. Cool. Cool. So that's it for polish and perf. We will catch you on Wednesday, y'all. It's going to be a great show. We're gonna be talking about converting an application from types or from JavaScript to TypeScript and how much fun that is and all of the bumps and bruises, but also a lot of the, pro tips that we have from both 2 folks who did it. And we wanna give you what we we thought about the process. So thanks so much for listening, and we will catch you on Wednesday. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.