HubSpot Community Developer Show | Site Speed and Optimization with John Fuller | S01E04

Okay.

Hey everybody. Welcome to episode number four of the HubSpot Community Developer Show. Today we're going to be talking about site speed and optimization. Got a rowdy panel here I'm ready to introduce. I'll start with Mr. Fuller. John Fuller. Hey, how you doing?

I'm doing swell. How are you?

I am just peaches, all peaches up here. John is what? Director of Web Development at Ascend Inbound. You want to just talk a little more? I think that's a recent acquisition, right? You've recently run to that role like it's been the last year, is that right? Is that correct?

Yeah, that's right. In the last year. From junior to senior to director and the sends growing and a. It's an awesome place to work now. We're. Now that we're expanding, we're remote and so, you know, we're working from home, being with the kids. Yeah, it's been fun times, so.

Indeed it's interesting times at least. We also got someone over here called Michelle Herzog, although we will refer to as zog, as I think everyone in the world does. But I could be wrong. I did complain to her earlier about her misspelled first name. Later on I will be having a conversation with her parents to discuss that. Michelle is developer on the marketing team and she's basically the person you can count on to make HubSpot.com look pretty and zippy. Michelle, how are you doing?

I'm doing great. Yeah, I'm happy to be here.

Cool. Next on my Windows, I see Nori. Nori is the tech lead for the marketing web team at HubSpot. She's been around HubSpot for four years. She does all kinds of things. And you'll notice the the coolest freaking dinosaur on her wall. Nori, how are you doing?

I'm going fantastic. Really excited for this.

All right, last but definitely not least, John McLaren. We might refer to him as J Mac. We might refer to him as McLaren, but he is here. He is senior developer advocate@HubSpot. John, what's going on?

Whole lot, whole lot.

Cool. Just a few things real quickly. If you guys have thoughts, comments or anything like that about the show. You want me to do something else? You want us to talk about something? You hate it? You love it, all the above. Please reach out to me. I have been putting a form in the community post, but I hate that form. I'm gonna stop doing it. You guys know how to get a hold of me on Slack. You guys know where to find me on the community. So, you know, just reach out if you're not on Slack or the community. We'll pause now while you go sign up. Okay, good. Next, I am being told by a lot of people that they would like to see this outside of YouTube. So I am working my butt off right now to distribute that to all those other places where I can say, you can watch us on your podcaster of choice and no longer have to see my ugly mug every single day. Well, I guess you don't like this every day if you do. Thank you. All right, let's just jump right in. We're covering site speed and optimization, and when I wrote this and I wanted to reflect on that, I feel like there's two different levels of site speed and optimization. There is your traditional you're a developer, you build a site, you make it pretty, make it zippy. I also believe that we could probably put accessibility, SEO, all those types of things into the optimization part of it. But we've already had podcasts on that, so there you go. So there's the developer side of things. And then I think we should really talk a lot about how we make that optimized site available or accessible to the marketer who's actually the one who's going to be putting the content on there. So we try not to trip them up whenever they're adding content. I just round the table here. John Fuller, let's just start with you and just any thoughts on that? Just to start off with.

Yeah, really. When I'm looking to make a website fast, it comes down to keeping it simple. As long as you follow the 8020 rule, you're going to be okay. And the 80% of making a website fast, not fat, but fast, is optimizing your images and your JavaScript and choosing a good strategy for JavaScript in that process. If you do that and keep it simple in that way, you're already 80% there, you have the cake, and the rest is just putting the icing and cherry on top. So that's really my two cents.

It was a great two cents. Anytime you reference cake, that's an amazing two cents.

Exactly.

Zog, what do you think? Where's your head go with this?

I think a lot about organizing and planning ahead for this. It's tough to go back into your site and retrofit it to be fast. If you start from the beginning thinking about optimizing these things, thinking about your JavaScript, your images, you're going to have a lot easier time keeping that speed pretty quick.

Yeah, that's Good advice.

Seriously it is. Can you just define more? Like what you believe is the beginning. There's different entry points I imagine for every it goes through. A website goes through many cycles, right? It goes through the inception, it goes through the design, it goes through the marketing, the copy, all that good stuff. Then it gets to the developer. Where's your starting point when you think about that?

My starting point is usually thinking about what assets do I need, what order do I need them in and where do I need them to be. So image optimization comes up almost every time you build out a page or build out a new piece of content. But you know, deferring your JavaScript, making sure you only have your necessary styles, that's something that impacts your whole site. So starting from the beginning with that is kind of what I start to think about.

Cool. Nori. Hi.

Hi.

What are your thoughts on all this good stuff?

Same stuff that John and Zaga talked about a little bit. But I think it would start like my thought starts with like setting up the infrastructure so that any dev, like if it is built the foundation already is handling a lot of stuff, then any dev can jump in and like pick it up and go with it. Image optimizations probably won't be in the infrastructure side, like in the JavaScript and CSS like caching and all that stuff that we need to optimize. But when I see something I'm like, okay, let's fix it on the foundation side so that when we're building on top of it, it's an easier thing for everyone to follow. So it should be a standard when we start a project.

That is an amazing point and something I didn't even think about really. Just actually optimizing for other developers to start working on organizing your code in a useful way. Jmac, talk to me.

Yeah, I think all three of you already gave really amazing answers. What I would kind of add to it is when you're starting a new project, this won't work with old, old projects, but with new projects I usually would even bring in a designer, like involve the designer in the decision making. So there's always going to be trade offs when you're trying to make a fast website. Some things will affect your host HubSpot flywheel. Like some things will reduce friction like having like if you were to add, I don't know, say new lead generation methods and things like that, that might be very beneficial to your flywheel, but it'll hurt your page speed potentially. So you have to kind of make some trade offs and an example might be like, say you had like a website, you're building a website for like a drone manufacturer kind of thing. Well, that drone I'm getting somewhere, trust me. But, but, but, so, so, so say you're, you're gonna build a website for that, that company. Well, what are you going to want to be presenting on that like website? You're probably going to want to have some video backgrounds showcasing like, hey, like, like drones are stinking cool and their footage is really cool. This is how you sell it. But the con here is everybody knows video backgrounds that autoplay when you load the page, they are terrible for performance. So you're always going to have to make these trade offs. And it's also really beneficial to start right at the beginning, like if you have the opportunity to collaborate with the designer to make those choices together of like, okay, these are good for the business, these are good for speed in general. And just work into that architecture that ZOG and Nori brought up.

And yeah, yeah, I would say you probably want to work with that designer quite a bit. Like you don't want to have 37 fonts of 30,000 different weights brought into a page. Correct? I'm assuming that's something you don't want, right?

Absolutely.

There are many weights, many fights that ascend on, on that. Yeah, you gotta, you gotta kill a fawn or two.

Come on.

And I just a direct question to, to your, your video background. I mean, because I mean, you know, the idea is like the Internet's getting faster and faster and faster, so why can't I have this video background? How do you, first of all, how do you, what do you say to the designer? And secondly, how do you balance that? I mean like what's in terms of actually coding? What do you do? Do you start with an image and then you after page load, bring in that background?

Yeah, just shake your head.

Yes.

There's a lot of different techniques you can use. A lot of times when you work with video backgrounds, they're often in an iframe. And so you may not have full control over the whole situation, but you can do things like use a placeholder image. You can make it so that on mobile the video isn't a video. You can in some cases, if the browser supports say animated webp or there's numerous other similar formats that you can use, or even CSS animations, if any of those would pull off the same effect that you're trying to achieve, then that's often better than showing the video background on a Low quality network.

And in the rare cases where the video background's, you know, not at the top hero section of the site, you can lazy load it. You know, there's plenty of things you can do.

It's a standard thing now. Right. Go ahead. Sorry.

There's also like a lot of video compression tools that's out there. You need to make sure that you compress your video so it's, it doesn't affect so much of the page load time.

So this is another interesting question. Who's responsible for that? If you're building something for marketers to be able to work on, how do you convey to them you're an agency, you're working on a site, you build it out for your client and basically you kind of hand it off to them for them to, well, you might actually do more work, but in theory, let's say you're handing it off to them. How do you communicate? What's your process for. For that? Anyone can answer that. Just go for it.

We do a couple of things on the HubSpot side to try and coordinate with our marketers even when we're not physically there when they're building out the page. And the two things we really rely on are help text, obviously go do this before you fill out this field. But we also do a lot of instructions in our default content so that when you drop the module on the page, the content that you see first is what you're supposed to do to use the module.

Nice. Very good. Fuller. You got anything there to add to that?

I mean, ditto. Yeah, Instructional placeholder text and help text and the right mandatory fields and boom, you got a recipe for success.

Yeah.

And then if you've done all that, you can at the end of the day blame them or somebody else.

And I don't know if video team does the same thing, but our designers do like, you know, this is the image sizes that you should use and they, they kind of send that communication out to the marketer so they're aware, like this is the size I should use, like the standard sizes. And I'm pretty sure video does the same thing. It's like, should be like this, this big of a video file and not bigger than this.

Cool. That kind of actually dovetails nicely into the first question that we had on the forums, which is image optimization. Just talking about that generally, what do you guys do to optimize your images for the site? What tools do you guys employ? JMac, let's start with you.

So there's a number of Methods. So some folks prefer to use. Because we have the CLI now, they'll prefer to optimize their images using local build tools and then just upload them either to the file manager or to the design manager. More often though, what I kind of suggest doing is treating it, treating, treating it like you can't trust the marketer in a way. So I've always liked to build modules so that say someone, someone's like, I assume someone is going to upload an image that is way bigger than it is supposed to be and I'll use the image resize URL functions to, to resize that image. The alternative is that you can also make sure to specify a height and width on the image and doing so will enable HubSpot to deliver a source set for that image as well as we will automatically append to the URL for the image, the resize URL. And that helps a bit. You can also use. I don't, I don't want to take up all of the answers here or say them all, but I guess one more thing while I'm on the resize image URL topic is you can use that to create custom source sets. So something that the, the HubSpot mechanism can't do when we're generating source sets is we don't know every context and, and size that you're going to actually need the image in. So we generate a default set. Whereas you, as the developer might know, okay, on mobile, I'm going to make this thing 800 pixels wide on a tablet or I'm going to make it, I'm going to make it only like 300 pixels wide on a desktop because that's just how it's going to flow and you can use what you know to generate those images that make sense.

Cool. And I think I read somewhere a while back, maybe a year ago that width and height attributes, I mean that's something good for the browser too, right? Your browser is going to use that information and it's going to calculate that much better than your CSS coming in.

Yeah. So an awesome. Oh, I'm sorry John, were you about to.

Yeah, I was just going to say it prevents layout shifts.

Yeah, yeah.

There's nothing worse than scrolling on your phone, waiting for stuff to load and then it's shifting up and just ticks you and the user off. So yeah, that's a big thing is specifying width and height. And even in modern browsers they have aspect ratio property in CSS that you can use. It's very Helpful.

Nice. And in terms of like background images, I mean, lazy loading there. How do you guys approach that? So like, I, for a while I was starting to use object fit to try to, you know, like, instead of having it as an actual background image, just make it an image and then, you know, place things on top of it where I needed to go. How do you guys approach something like that? Zog.

Sure, sure.

I.

I tend to think about like, is this a background image that the marketer is going to want to change out or is this a background image that's just for me? Is it like an SVG wave? Is it actually a photograph and kind of take it from there? So I would probably, based on different screen sizes, end up using that resize image URL, because that's when I think about things I can do behind the scenes for the marketer. That's like the main one that comes to mind. If it's a background image that only I'm dealing with, particularly if it's an svg, I would run it through an SVG optimizer or try and take those steps on my end before I put it into my code.

Yeah, Nora, do you have any other ideas on that?

No, Same thing. If it's a static image that doesn't need to be changed, I can optimize it, upload it to File Manager, use that CDN. But still try not to use a lot of URLs in your background images as well, because that's all HTTP requests sent to the server.

Indeed.

Yep.

One of the things that we'll do, I think some people are asking about actual tools. I'm not, if I'm remembering the question correctly, we'll either use a command line tool, which is Image Optim, I think that's a node command line tool. And then another thing we'll do, if it's like a small batch of images or this is a site, or just in other cases we'll use Adobe Bridge and kind of batch resize and optimize all JPEGs and stuff like that. And that all kind of happens on site builds that the dev or that you're launching, not kind of once the site is in the wild for the markers. So one thing that we'll do is we'll use the resize image URL function pretty much everywhere. And with that it kind of gives the marketer easy set of rules to follow. Because one of the things that we find is, you know, sometimes a marketer will upload a 600 pixel wide image for a background and that just doesn't fly on a desktop, you know. So one of the things we tell them is, hey, 3,000 pixels wide or 3,000 pixels tall, just stick to that, you'll be fine. And then we do the rest for them. We had a dev that was that we were onboarding and training in HubSpot and he's like, how do you all handle image optimizations and stuff? And I told him about the resize URL function and he was just like, like what? It's all done in HubSpot. This is crazy. Like, I don't have to, you know, I don't have to do all this stuff. You know, obviously the best, you know, you don't want to be polishing a turd, so to speak. You don't want a huge image that HubSpot's, you know, optimizing and resizing. So you want, you know, quality stuff going in. And HubSpot put even better quality stuff out with that function.

So, yeah, yeah, I'm going to have to remember in the show notes, you, you gave a pretty good talk a few years back. I think image resize URL was in there. In terms of functions you mentioned at our developer day.

Yeah, if you only had one function to learn, I'd say that that would be it in HubSpot for sure. Yeah, memorize that one.

And in terms of formats, like, what do you guys have a preference? Png, jpeg, what do you guys. Is there something you would like, advise for in certain situations? Don't all at the same time.

I also use a lot of PNGs, SVGs. There's WebP, which is a modern format media format. It's compatible with IE and it's like way smaller size than PNGs. But usually we use SVG and PNG.

Yeah. What I would sort of add to that is, so purely because HubSpot will automatically convert resized images to WebP if your browser supports it. If the browser does not support it will just display the image in the format that you provided it in. And so uploading a JPEG or a PNG is useful because then you get a little bit of the best of both worlds. Obviously, if you upload a webp, it might be better quality than what our automatic resizing might do because you're controlling the compression rate and everything, but it at least gives you a little bit of the best of both worlds. There are new image formats also coming out and I don't have enough info to really deep dive into them, but it's exciting and we're definitely going to be paying attention at HubSpot.

Yeah, CSS is exciting right now. Next question is, and I'll just direct this one to John J. Mac, how to deal with initial server response time. This is the most common thing I see in Google page speed for HubSpot sites. Before you even answer the question, maybe you should just define what this person's talking about.

Yeah, so they're talking about what is commonly referred to as time to first byte. So time to first byte is effectively what it says right on its face. But it is the amount of time that it takes for the server to respond back to you with anything, the first literal byte of data. And so there's a lot of factors that play into this. And so if you were to do like a lighthouse test from your computer to a HubSpot site, it doesn't have to be HubSpot, it can be, you can do this with any site. But you run one of these tests, there are a lot of factors that will play into how long that duration takes. So one is your own network that you are actually on the ISP that you use your country's infrastructure and then your proximity to a HubSpot CDN node. And then on top of that, there's also some things that you as a developer can do to somewhat influence the time to first byte as well. And so to kind of get into that, you can't obviously go and upgrade all of your website visitors Internet. Like that's not a realistic thing. If you can do it, it'll make the web a better place. But for most of us that's not practical. But so there's a few things. One, at HubSpot we're always expanding our CDN network and we're currently making some changes to improve that time to first byte that I can't yet go into detail on, but hopefully we'll be announcing in a relative soon fashion. And then on top of that, what you can do is make your web pages cacheable. So we have variables that will actually like Hubble variables that will actually prevent our ability to server side cache the pages. So an example would be if you are printing the, printing the IP address of the website visitor or printing the current time and date, that's going to change for every visitor and every, well, not with the IP address but every page load, the time would have to change and therefore we can't cache that page. So there are a few of those variables and we denote them on our Hubble variables page. So try to avoid using Them. The good part about those is almost all of them you can use JavaScript to just avoid using in general. So do it cacheable.

Okay. John, do you have any other insights into this, how you would handle this?

Yeah, my first thought was wondering if the problem that they're seeing is stemming from Smart Content. Because it's my understanding that smart content can break page caching as well. Somebody back me up that from HubSpot.

I have. I will have to get back to you. There's been conversations regarding it. I believe that the answer is mixed, actually, and it's not a solid yes or no. I believe that in certain circumstances, yes, Smart Content may prevent caching. However, we are trying to move as much client side as we can to avoid that.

Well, this should be fine. So basically if this is wrong, I have to come back here and edit this entire scene.

Oh, absolutely.

Cool.

Thanks, guys.

Cool.

We'll come back to you on that.

Awesome. Okay, I can move on to the next question I got here, which is how do we deal with tracking and analytics codes, which is necessary to put into the header. Nora, you want to take this one?

Yeah. So our tech Infra team did this huge work on like optimizing homepage and they found that the big factor was also on the analytics and tracking code that we were using. They did some tests removing it, and it already saved us like a bunch of seconds on site speed. So basically what we would suggest is evaluate what tracking scripts you. You need only enter those, use async, defer those. If you need to work with the analytics team and basically only put in what needs on that page and that will already help you. And deferring and loading the script tags asynchronously will already help you with the page site speed.

So 300 to 400 scripts at the top of the page in the head is not a good idea.

Absolutely.

Load all of the heat maps. Load all the heat maps and all the video tracking software.

So what we're all saying is blame the marketers on this one.

We're definitely cutting this out.

One of the things that we'll do and that we've had some success in is using Google Tag Manager to manage all the tags up top. And so if it's something that's not as important, but the marketing team wants the analytics. If it's somebody who's staying on a page longer than 3 or 5 seconds, maybe 10 at tops. Like for instance, we'll load a LinkedIn tag delayed with Google Tag Manager. And there's some ways to do that, it gets kind of complicated. And if you're a dev kind of budgeting out that work, you do need to plan accordingly because you can get in the weeds in that you can spend a lot of time testing, but it is worth it if the client pays the money and it will help with page speed.

Yeah, that's a really good tip actually. When I was in the agency life, I didn't have to deal with the Google tag manager at all. That was not my duty. Do you do that, John? Is that you're within your purview or do you have like a team dedicated to that portion of. I guess that's development.

Yeah, yeah. Jack of all trades, you know. Yeah, I'll dive in those waters every now and again.

Cool.

Okay, so defer as much as you possibly can is basically the answer to this, right? Only, and this is probably something you can abstract to everything. Just put what you need. Don't, don't overdo it. You know, the kitchen sink is not.

Going to help you honestly and focus on the. On the what. What will reduce friction for your flywheel. So. So if you think that the marketing analytics for a specific thing is going to help you to optimize the site for leads or something, then it might be worth loading that script if it's not even going to ever even be looked at and someone just wants to load it on the page because then it's probably not worth it.

My rule of thumb is always, if we've lost the login to that tool, we can probably take off the script tag.

That's a great rule of thumb.

Next question.

I like one of the things, I like that John said earlier. I think you were talking about. There's always trade offs and that's like a good principle to live by. Like in pretty much all arenas of life except for marriage, there are no solutions, only trade offs. If you're married though, you know, obviously it's yes, dear, you're the solution indeed, you always were.

That's right.

But in our line of work it's definitely. You hit the nail on the head, it's trade offs and you just have to budget it and you have to weigh it out and communicate with multiple teams because obviously we're going to want a fast page speed and if it were up to the developer, we'd ruin everything for the other flat HTML.

No CSS, no JavaScript, just HTML about.

So there definitely. You got to find the right balance.

Yeah. So do you start from the minimum and then work your way up or do you go the other way around. Like you, you put a little bit more than you think you're going to need in there and you pull back. I, I, I'm going to. And on top of that, I just, I don't think this is like, you get it the first time. Like this is something you figured out over a period of time.

Yeah.

That'S a deep thought.

Yes.

Yes.

I think what's tough about that is you usually don't know, or at least analytics teams don't usually know, what information is going to be the most valuable information. So I think that tends to be how you start with gathering a lot of information and then narrow down to only the stuff that you want to track.

Zog, thank you so much for saving me there. I looked at John thinking he's going to be something really profound.

But yes.

I think she saved me more than you.

I'm here to help.

Yeah. Moving on. Next question. What is best practice for writing CSS and JS inside CSS and JS block of custom module or in common style? In js, writing a custom module causes extra HTTP calls. So I think, Zal, you said you had some thoughts. I know that JMac also wanted to sing about this as well, but we'll start with you, Zog. What do you have to say about this?

Yeah, I think I've seen a lot of, particularly a lot of HubSpot customers. They've got one CSS file and it's huge, and they're loading it everywhere. And that's kind of what I think of as the thing you don't want to be doing. You don't want those extra styles on a page that don't need them. So that's the first thing I think of when somebody says, should I just be using one big common file? Probably not. On the other hand, writing your module CSS and your module JS in those areas for the module itself, that's great, but sometimes it can cause some confusion, depending on the size of your dev team, as to where those styles live. So I really think, particularly for this one, talking about how you're going to work on the site is more important than saying, you know, just making one decision. It's thinking about, how will that work look over time?

Mm, definitely. Okay, I'm gonna add on top of that, if you don't mind. So as someone who, like John Fuller and J. Mac, I know you've both worked for agencies, and I'm assuming you have like a kind of a library of modules that you, you know, would employ on various projects in your module. Do you guys have like, use guys, where am I? Do you guys have like, more like a skeletal CSS framework in the module? And then you would add on the skin in a CSS file or would you actually add onto the module itself the, you know, like a themed version of that module? I will defer to another profound answer by John Fuller.

Yes, One of the things that we'll do, we have a more skeletal approach. And so we'll kind of take a hybrid of having that common file for your main style sheet. And then if it's a very commonly used module, that module CSS is going to, to go in the file. So let's say you have a website theme, and that website theme is using, you know, a hero module, it's using heading modules. And then like your theme's image module, throw in a couple others in there, you know, whatever fits for you will have like a sass file in that module folder and then it'll plop into the theme's main CSS and then any other kind of offshoot modules that, that are not so common and won't be so commonly used throughout the theme, we'll load that in the module CSS file and so that it kind of finds the happy medium and the happy balance.

Nice. All right, yell go. You got a lot to say. I can see it. You're like raring to go.

So John, hit it on the, on the head with most of what I was really going to say. So it used to be the, like the web best practice that everybody used to preach because of the fact that like HTTP, like you wanted to minimize how many requests you were making. So everyone was like, let's load everything into these giant monolithic files and then it'll be great. And there were, there was kind of like an interesting trade off there because you did minimize your HTTP requests. And so at that time you were having a little bit of better performance. But now with HTTP 2, the cool thing is it's kind of like going to a diner and talking to the waiter. And like, so the old way was like you'd go, I want a burger. And then the waiter doesn't let you finish your order and just walks off and goes into the back and goes, make me a burger. The server, the server comes back, gives you the burger and then you're like, I wanted like a fries with that. And then they're like, all right. And then they. So anyways, obviously that's not like how diners work and that's not how he v2 works now. So instead you can be like, here is my full order, here's everything that is that I need and it's all at once. And then the server will give it back to the browser as it readies those things. And so what is amazing about that is you don't have to care as much about how many HTTP requests, but you do have to care to the degree that you're not going to have 90 separate 1 kilobyte CSS files. Like that's obviously not great for performance, but so the HubSpot module system is sort of awesome in this way that it sort of forces you to think this way. But when you group your CSS and your JavaScript and have it in those modules, you're already splitting those files so that they're only going to be loaded on pages that need them. But here's the way that I would take it a step further is basically what John was just describing, where if you have site wide styles like you have template level styles that you need to implement, that's not going to change. Just put those in your main style sheet. And something else that I would advise doing that is similar is so say you have a website with a header and a footer. You know what modules are in that header and footer and they're not going to be changing. So one trick you can do is use either a linked style sheet or use require CSS within your module and load an external CSS. Or you can use this with JavaScript as well if you have shared JavaScript and then load on each of the modules that are in that group. That way if you use that same group of modules for a header anywhere, you're going to load all of that at once. And the side benefit is then when you have subsequent page loads, all of that stuff is already loaded for the browser and the only thing they're doing is finding what's different.

Nice. Just to confirm, let's say I have one module three times on a page. I'm not pulling that into my CSS three different times.

Correct. It's only going to load once. There is one exception to this, and this is just purely if you are doing instance specific CSS and instance specific JavaScript. However JavaScript, there's a way to work around this with CSS you can inside of the Hubble HTML file, have a style tag, wrap it in, require CSS and you can do your instance specific styles so like specific background image and whatnot. With JavaScript you just write your JavaScript in such a way that you can pull variables from, say, a data attribute on the HTML and then just loop through all of the instances of the module on the page. So you have one script that handles all of them.

Nice. I always see things about something called critical css. How do you manage that? How do you handle working with it? What is it to enlighten me? And who wants to take that one? Zog feeling it McLaren.

Sure, I can talk about that a little bit. So your critical CSS is essentially your styles that are needed on the first screen that your website loads on. So it's nothing below the fold. It's just above the fold. And usually from my understanding, when you talk about critical css, you've taken those above the fold styles and you shove them into a style tag in the head. So that way when you load the page, you get the styles that you need right away without waiting for the style sheet to load.

And you've removed those from your CSS file altogether. Right. They're just now in the head or do you keep them in the CSS file?

You keep them in there?

Yeah. Cool. And what do you guys think about, like, let's say I'm using a framework, you know, I'm using, you know, foundation or, you know, bootstrap or something like that. How do you guys. Where do you, you know, what do you do with all. That's a lot of bloat. Right. How do you reduce that payload? If John Fuller. Go for it. Well, yes.

One of the things you can do is not use a framework.

I'm sorry.

No, there's a lot of things that you can do with. I mean, honestly, I've been really, really impressed with Bootstrap 5. I've been kind of playing around in the alpha. It might be in beta now. I'm not sure how. Where it is, but you can do a lot of. You can include a lot of styles and exclude a lot of styles and kind of, you know, pull together a custom build of bootstrap to only using what you need, to only use what you need, you can, you know, defer all of that CSS and use critical css. But building up critical css, if you have any modules that are affecting the way the styles look on the page, and, you know, the marketers and the content editors are changing the way things look. You have to weigh that out. So there is going to possibly be a layout shift, because in a CMS situation, things are just so different, especially if they're using like a drag and drop Editor, you know, things are, it's just not one size fits all.

Yeah.

One of the things that I like to do with css, just kind of take it back to go back to home base. You know, you're wanting to make a website fast. Don't start at CSS per se, Start at your images in JavaScript and then go to CSS because you are going to take care of the most expensive resource, expensive resources with JavaScript and images. But you know, if you're using a framework, I would go away from it. If you have to use a framework, make sure you're just pulling in what you need from it. And then I think it was be. You'll be golden if you do that.

Cool. So my next episode is going to be another one with John Fuller where we can discuss his favorite frameworks. Next question. Unless anybody else have anything to say.

About that, I guess I would just simply add that kind of on the point of what John was saying, like almost don't use a big bulky framework framework. And I don't mean that in the saying that like frameworks are bad. That's not at all the case. All I'm meaning is a lot of the things that we used to use frameworks for are not as like needed anymore. So for example, like layout, like grid layouts in general were always hard and we were, we were in the past, we were relying on goofy float hacks to make them work in general and you don't have to do it anymore. So like that, that took away a lot of what we used frameworks for. You can just use CSS, Grid, Flexbox, etc. And those are well supported. Now in browsers there are fallbacks like special prefixes you need for like ie. But especially if you're not caring about IEE these days than like the world's your oyster or whatever cliche saying you want to use.

Are we caring about IE anymore? What? No.

What is ie?

Yeah, right. Thank you. Thank you. I've been waiting for that statement for a long time.

Y' all want to hear a story about frameworks?

Yeah.

Oh boy.

Please bring it.

We had a client and they are using a third party vendor for, you know, kind of displaying some of their products and the third party vendor has these product widgets and you know, it's not the route we would have taken but we understood why the client made the decision and they were given these instructions and embed codes and we just kind of blindly installed, installed them and we just, you know, because, you know, it's a Third party. It's kind of out of our hands. But then I noticed the website was crawling and there was some funky stuff happening. And then I looked into the code and just to get a modal, this widget was calling the entire Bootstrap 3 library just to get that functionality for a modal. And I just laughed. What can you do? So what did I do? I just went in, copied all of the model class, got rid of that part of the request, and then put in the moto classes and everything went back to normal. It was fine. So that's kind of the moral of the story, is be careful using frameworks, because, I mean, it is a giant payload and it will. This is when CSS does matter and it can really ruin everything. Kind of brush CSS stuff to the side. But this frameworks can really get you in trouble. Be careful with them.

Do a bunch of research before you pick a framework. Like the sizes, how big the size of this package is going to be on your pages and stuff like that.

Yeah, yeah, definitely. Just plugins in general, right? I mean, just anything but something that looks easy, it might not be, you.

Know, and how good is it accessibility wise? I gotta plug that everywhere I can.

Yeah. Is it better to download and add the Google Font files to the file manager on HubSpot and link to them in the CSS, or is it better to use Google Font CDN, I guess. CDN. I didn't talk to that thing. The CDN from Google. What do you guys think? Nora, you want to take that one?

Sure.

Yeah.

I came to a fee.

What?

Oh, I was just saying if you don't feel you want to take that, I can also take it.

J. Max studied the questions.

Yes, I think so too.

Yeah. This is not Jeopardy. This is not Jeopardy.

Darn it. There's no. There's no double jeopardy. No double points.

What you saying?

I think JMAX should start.

All right, fine. Gosh.

I was just. I was just. I was just going to say this one's sort of nuanced in a way. So there's. So first, if you're going to load a font from a cdn, period, you should trust that CDN for security reasons. Like you want to make sure that they're not going to get hacked and. And all of a sudden that code is loading on your page.

What's your due diligence on that? I mean, how do you. What are you looking at?

The. The hard part is, is there isn't a great, like, special way of telling you can look if they have like security certificates and things like that. But one thing that I just generally would advise is if you know the company is known for having good security. So for example, I personally would trust Google. They have a whole team, I'm sure that is dedicated to making sure that that stuff is secure as well as HubSpot does as well. So all of your files were consciously protected. So where things get interesting is so after you care about security, it's all about performance. So if you load from the HubSpot CDN, the one little advantage is that you are not making a new domain request so you're not having to connect to another IP address. So that is one kind of, kind of trivial benefit from loading from our end as well as if you are the one to upload the file and you are Hosting it in HubSpot, you are in control over that file security as well as HubSpot. So I would say it's sort of a toss up in this specific case.

Yeah, I think beyond that, like I think swap the, the font display property. I think that kind of changes everything. Right? Yeah, I mean, and that's relatively new with Google, right? That, I mean in the last year or so I believe is when they let that happen. Nori, do you have anything to really follow up?

Yeah, the, the flash text of unstyled versus styled once and display optional is an option now. Right. So f out the flash of light on style text is always preferred. Even when I went to the Chrome dev summit they prefer that because it's faster and the font will load when it's available on the page so it's not deferring to the page load. So like having those trade offs, making those decisions before is super critical.

I'm also just lazy. Take that back. I didn't say that John, say something much more.

One of the things that you have to weigh out with display swap is layout shift. So if there's not a fallback font that's very close, more oftentimes than not it's going to make the page layout shift. And that's going back to the trade offs argument. I think Oswald is, is a good example. Like we were loading Oswald for a client from Google Fonts and you know, we had display swap on and the closest thing we could really find was impact because they're all kind of, you know, skinny letters but just A, didn't look right and B, it was still causing a layout shift. So what did we do? We just waited for the font that was kind of one, one trade off. We had to make.

Was that your decision or did the client say, I just. We can't do this. This is not acceptable.

That was mine. That was mine.

Yeah, of course it was yours. I think the actual question itself, I don't think there's the. The savings you're getting on this is pretty nominal, right? I think if, according to like, and I agree with John, you know, if your CDN safe, it's secure, I don't, you know, load it from whatever. As I said, I'm lazy.

Everybody's probably going to have that CDN cached as well. So you have to.

It's a very good point.

Most of Google fonts, somebody's encountered it before. It's probably cached on their computer.

Yeah, and I'm trying to say I'm lazy and I like just to copy the snippet that comes out of Google for me here. I can just put it up, take care of it.

There.

Done. Next one CMS boilerplate template consistent consistently scores 90 plus on Google page speed. What's a good way to optimize legacy themes like Vast? Ooh, Vast without having to change out to the boilerplate template? Yeah, I know this is tough. Zog, you've been around for a while, so you laid on us. What's the answer?

Why are you still using Vast?

Right.

First of all.

All right, I think we can end it right there.

I've been at Homeschot for four years and I've seen a lot of people redesign their site since then and Vast has been around that entire time. So I think if you're still on Vast, you might want to consider like, does that still feel fresh? Does that still feel up to date for your styles? If you're really, really attached to it, then you're going to end up in that position I mentioned at the beginning, where now you're retrofitting for optimization. Some of that retrofitting might look like finding not commonly used modules and moving their styles into the module CSS or their JS in the module css. It might be going through all of your loaded scripts and taking that process to see what you need and what you don't need. It's not the most fun position to be in to retrofit.

No, no. I imagine if you're using something like fastest point. Yeah, you got a Frankenstein style at this point, I imagine something that's that old. Right. You've probably been adding things onto it and barnacling, Barnacling and barnacling. So, yeah, I think, I think it's a Legitimate question. To think, should I start over with something, you know, fresh or should I? I have a feeling you're probably gonna be spending more time actually trying to fix something like that than you would just starting fresh. John Fuller, you've done many a site, you've done many a barnacle. What do you think?

Well, if you're gonna find the happy medium and the most efficient way to at least maybe get a quarter of the way or halfway there, let's say you have to stick with fast. Just go in and make most of the images lazy load, kind of change the markup in there and just try that and see how far you get. If you want to try to defer some JavaScript in there as well, try that, see if it works and then come back to us. When you're making a new site.

There'S so much value, particularly for your marketers and content editors in a new site or a new theme, you could have drag and drop. They can change colors on their own. It's tough for me to imagine a world where the trade off of time to change out from vast isn't worth those extra features. I think it's definitely worth it.

Cool. The CMS boilerplate is incredibly helpful. Do you have plans to establish additional best practices that could be used for site optimization? For example, an only load necessary CSS above the fold boilerplate. A SCSS everywhere boilerplate production build boilerplate. A perfect boilerplate that works for everyone might be impossible, but maybe there are ways to extend it with selected options. J Mac, talk to me.

So first off, creating a boilerplate that is going to be perfect for everyone is impossible. But we think that we can continue to try to strive for that balance of showing a lot of best practices in our current boilerplate and improving upon that. But as far as showing and establishing other best practices, we're trying to use our documentation to do a lot of that. And we may also over time have like code examples or repository examples that might show you using different tooling. So for example, like we do have a REACT NAVUE boilerplate and they show one opinionated way of building modules that use VUE or React and those use build tools. So the other side of this too is our boilerplate is fully open source. There are, I think there was over 20 forks of it. You can fork it, you can set up your build tools to work with it, share it for the world. Everyone benefits. Kumbaya. Hopefully that's not an offensive thing to say that I don't know. Anyway, I don't Know, like, if that's appropriation, so apologize, cut that. If I, if I'm being awful, don't mean to. But yeah.

So, yeah, I think this is also one of the things where you should be jumping on to the community. Like, you know, the forms are slack, but definitely slack. And just talk to. There's a ton of developers out there doing really cool things with, you know, their build process and how they're just building sites generally. So get part of that conversation, donate your thoughts to it. Don't depend on HubSpot to make those decisions for you. We'll give you some opinions here and there, but we want you to build the cool things. That's me talking. I'm not sure If I represent HubSpot on that one, but that's how I feel.

No, it's true. If you do create something cool. Just an example, we recently on one of the podcasts when we were talking about email, we did highlight a community member's efforts to create a really cool MJML framework for working with HubSpot. So, but clarifying, they didn't create the framework MJML, they just created the system to make it easy to work with HubSpot. So if you do that, we'd love to see it.

Yeah. And like the SCSS one, like that might not even be a thing, like, you know, at some point in time. CSS is doing so much right now that, like, why, you know, I mean, I. There's still definitely a lot of qualities to scss. I love it, you know, I just am used to it. But CSS is just changing it. It's kind of a crazy pace right now and it's taking over a lot of that stuff.

Yeah. So we. Oh, I'm sorry, you go, Nori.

Okay. So the Cool thing is WebTM has used the CMS boilerplate, created a wrapper, implemented a lot of optimization, like module. You know how we have CSS and js, we have now like scss. So the developers go in, we code all in scss. Webpack is implemented on it. So webpack compiles it and places it on module css. So yes, absolutely, it's possible to do so. And maybe Jmax and us, we need to work closely together so we can push this out to the public for everyone to use. But like even separating out critical CSS versus, okay, this is critical template level and all the module level sits down here and they will still work. So we did a lot of work around it and we were obviously playing around with anything product throws at Us, we were like, oh cool too. We'll try to like, you know, make it work for us. And I think now is a good time that Web teams and JMac your team, we combine together and be like, actually if we do with this with a boilerplate look what we can do. Publish it out to the public.

I got to give a shout out that compiling module SCSS into module CSS was all Nori and it's so great. It saves me so much time.

Again, you got to optimize for developers so we good quality product while we maintain our best coding standards.

Cool.

I did want to chime in a little bit. So on the you were talking about how CSS is rapidly changing and using things like SCSS may like. I have a feeling SCSS because it itself is advancing. There's new features coming out for it every now and again. And so I think that it'll stick around. But a lot of the reasons that we use it now are kind of going away. So there's custom properties which replaces SCSS variables. And then additionally, I learned this recently and don't quote me on exactly how this works because it is. It is still a spec being worked on. But nesting is coming to css.

What. Amazing.

Yeah, it's cool stuff. I have a feeling that John, I got the same source of information on where we saw this. But yeah, I don't want to promote another podcast on our podcast.

It's not going to happen.

It would be a game changer. CSS nesting would be a game changer.

Let's see. Next question I have here is how can we get content editors, marketers to contribute to site optimization? For example, almost nobody on my team knows that the Hover details feature exists when selecting an image, can we warn them that the page will load more slowly if they upload a 10 meg PNG? This probably goes back to our initial question and just how I think ZOG you're talking about, like your default content you're putting up there has you make it as explicit as possible, but if you want. If you want to speak more to it, please go.

Yeah, yeah, absolutely. So we use that in two ways. There's. There's your module help text and then we can be pretty robust with what we put in our default content. If we have an external list of directions for creating product screenshots or what sizes they should be, we can link out to that in our default content. That way we know that every marketer has seen that. But I also notice in that question, it seems like there's a feature in HubSpot that folks aren't aware of. So that seems like an opportunity for HubSpot to make that more apparent. That's feedback we can take on our end work on.

Cool.

Yeah. Little highlight of that feature. There's a few places we actually surface this I think but we do have an SEO recommendations tool if you're not familiar and image sizes are one of the like at least five different performance metrics that we currently will warn you about and we're working on more.

Awesome. Next question I have here is I noticed a new test column was added to the website pages view. How cool would it be if you you could include a load time column that periodically rechecks? Very cool. It would be very cool. I found that I do a marathon optimization sessions and then deprioritize it. Seeing load times as content is added updated would be very helpful. It's a legitimate idea. Yeah.

Cool feature request.

Yeah.

Yeah. I think that's an awesome bit of feedback. I wish that they were on the call so that I could ask them the follow up question of if this appeared on every page, would that potentially be a pain for you when say a marketer is always aware of the page speed and page speeds change. So just what I mean by that is like if you run a lighthouse test and then you run it again in 15 minutes, it's different. You could go up or down by 15 points or so. So it's open question. I don't know. I think having some sort of awareness over page speed is a great idea and I'll relay that internally.

Yeah, I think it's great. I think it'd be cool if the marketer saw that as well. Honestly, I'm okay with having that variation as long as you make them aware that that's going to happen. I think it's useful information, it's important and I think it'll make the marketer better at their job too. Any more thoughts on that? Generally speaking. So we talked. Oh go ahead.

I was just going to say it sounds like an interesting way to have marketers be more aware of PageSpeed surfacing it to them.

Now they know one thing that's been a feature request of mine is when marketers upload an Image, oftentimes the HubSpot Resize Image URL function does not work if it's over 4,000 something pixels. So it'd be nice if HubSpot team could give a message, hey, this is over 4,000 pixels. Make sure you know what you're doing.

You Know, I thought that I made it clear when I was talking to you earlier, John, that this is not a place where you're going to just list off things that you want.

Secret feature request.

Did you bring a whole list while I'm at it?

Yeah, well, yeah, no, that is. That is great feedback though. Yeah, I think we can do a better job of surfacing like that specific scenario. Yes. There is a size at which that we do not resize at if someone uploads. And the reason is quite simply like the way that our image resizing works is once the the image is called, that's when the resizing occurs. And if it's a gigantic image that is just way too big, we're not going to be able to deliver it fast.

That makes a lot of sense.

So do you guys have any recommendations just like what are your build tools? I know. Nori, you mentioned webpack. Gulp's still a thing, right? People are using that out there. Do you guys have recommendations or what are you guys doing? I'll start with you, John. You're on the front lines out there working for us. What are you working with these days?

What's. John.

Oh, John Fuller.

I apologize.

John.

John. So we'll use like node just for SAS, just straight node script. Any piece of JavaScript that's going to be big site wide, please webpack four oftentimes what we find though is because we take such a modular approach, we don't really need many build tools for JavaScript. We're not building single page web apps most of the time on the cms. Now if we're building like a micro site or something that's you know, customer wants to be a single page web app or you know, have that feel as much as possible. You know, we're going to be doing webpack a lot more then you can have your tree shaking all that jazz, just all the webpacky things. Yeah.

Hopefully that answers no. You did a great job. I'm proud of you. I'm very proud of you. Nori. What do you guys. Any advice, any tips, any recommendations and what you're happy with?

Yeah, we basically use webpack. We moved from Gulp to webpack. Basically use the right plugins to do so the compilers, the scripts that you're calling do the basic JavaScript and Metafile scripts, all that stuff. What else?

So you're actually running minify scripts in the. Am I incorrect in thinking that doesn't HubSpot. Once you put it up there, your CSS and your js that's being minified as well. Is that redundant or is it you just like doing it? Why not?

Yeah, we just throw it in there because we usually write a yes that compiles to like so that compatible and all that stuff and we plop it into module JS and then it minifies again. I don't, I don't assume there would be a big difference in the file size at that point, but yeah, if it kind of.

To play off what you said, you know, if a client needs something that is backward compatible, you know, you're gonna obviously need webpack and Babel. Yeah, but I mean, who wants to make something backwards compatible, right?

Right.

I mean, Edge is on chromium now. We're good guys.

We won. We won.

We won.

Jmac. Do you have any recommendations over there?

I would just purely say choose the tools that are right for your team, so.

That is such a cop out answer.

I know, I know. I mean, I would even add, just like John said, right for your team and for the specific project you're doing. Myself, I love scss. I do, but I have pretty much stopped using it for the last year and it's just because I feel like I can do all of the same things that I that were most important to me with normal vanilla css, if that's even a term like it is with vanilla JS. But. And I don't personally write as much JavaScript as Nori and ZOG probably do, but when I do, like, the backward compatibility isn't as critical for me, so. So I often will just straight up write vanilla JavaScript. But if I did care about backward compatibility more. Yes, Babel all the way webpack. Load those node modules. Yeah, cool.

Yeah. And I. We're actually out questions. I just have a couple more of my own just because I. So I'm curious, what are you guys thinking about jQuery these days? I mean like, are you guys. Are we still loading that in places you find it useful still?

Or are you jQuery?

That is the correct answer.

Oh boy.

Gary and I had to write jQuery something like 2 months ago and it took us forever. We like forgot how to do it at this point.

There's a page, I think it's HubSpot. Host it. Right. You might not need jquery.com so it's a mapping of okay, children actually means here. And then what ZOG and I did was like we reverse mapped it. It's like, now we know vanilla js. How did you inform me about this? It's like you forget about it.

Stay away from this.

It's a big, It's a big, big package.

Yeah, indeed.

Vanilla JS all the way.

Cool.

I love it. And last question I have, just generally speaking, what are you guys relying on? I know we said Lighthouse like a thousand times, but is there anything else that we're looking at just to see how we're doing, generally speaking, in terms of our optimization? Fuller, go for it.

My phone on a slow connection, like.

Your phone, your actual phone, right?

Yeah.

Yeah.

There's nothing like testing out in the wild. And if you find yourself just getting ticked off whenever you're waiting for the thing to load, it's a good sign. You need to keep going and make some optimizations. One of the things that I haven't mentioned that I feel is really important is developing mobile first. And I think Google is changing their algorithm to reward sites built mobile first. Not mobile friendly, but mobile first. And so that's a big thing that I've been chewing on lately. As far as, you know, where sin moves forward with, you know, the new websites that we build, you know, obviously like mock ups and stuff look better on a desktop. You can do more and it sells better. You know, when somebody's coming and looking for a website within your framework, you know, you still need to be thinking mobile phone first and progressively enhance all the features that are going to come along the way. So, you know, I'll kind of give everybody an exercise. Go to Google or Amazon, one of the big tech companies and you know, load the website on your desktop or your laptop and then bring up the console, bring up the cell phone emulator, load it again, see what happens. They're loading different scripts for different devices. They're using Modernizr to detect touch and, well, not necessarily touch, but certain pointer events as well as screen size and stuff. And then they're loading scripts that way. So that kind of goes to the JavaScript side side of things. I don't necessarily do, you know, you still use media queries for CSS, but for JavaScript I'm loading a lot of fancy JS if it's not mobile. And that really does save a lot of time. You kind of have to get a little finicky and you know, experiment in HubSpot, but it's definitely well worth your time to play around with. Definitely do that exercise and just, you know, most of you probably already know and party poked around, but definitely experiment with that method.

Right. I think it's actually a pretty good segue. Just real quickly Touch on core web vitals and JMac. If you want to kind of talk about that or anybody else who wants to just touch on that subject, that'd be great.

Yeah. So I've gotten this question recently of like, what is HubSpot doing in regards to core web vitals and is it something I should be freaking out about?

What is it? Would you just define what core web vitals is first?

Yeah, yeah. So core web vitals are effectively Google set out and found a set of measurements, actual measurements that they perceive as being the most valuable in influencing the perception of a website being fast. So for example, CLS is one of those. So CLS is cumulative layout shift. So when the page is loading, all of a sudden the. The viewer is watching the page suddenly start shifting around and text is reflowing and everything like that causes the perception that the page is not done loading. And so we talked about critical CSS. That's one method of tackling it. Height, width, attributes, etc. But there's also, there's a few other measurements that they take into account and each of them have an acronym. And our Page Speed Optimization guide has a link out to Google's definition of the core web vitals. You can dig into each one and basically the idea is that these are actual measurements. These are not what Google PageSpeed is known for are their recommendations. And so your score that you actually get from Google PageSpeed as well as Lighthouse is not at all based on those recommendations. It is quite literally only based on these measurements. So you could pass with flying colors and have a bunch of recommendations listed. The recommendations are there to just give you something more you can do to influence your site's performance. Additionally, each of these metrics, with some exceptions, are based on what are considered the Google's top 10,000 best performing websites. So this is good context to have when you're running this tool is they are judging you against the top 10,000 best performing websites and that will change. That list changes at least year to year. I don't know the exact frequency that they update it, but that means that your score today is probably going to be worse a year from now because everyone's improving and getting better.

Noria, how are you guys? Are you guys thinking about this in your. On your teams?

Yes. So even with Roosevelt, one of the tips that we do is always throttle your connections when you're testing out your page. What was fast 3G is now slow 4G. So go to a slow connection and test your pages out. Also, the newer devices load like say, 100kb of data faster than the older devices. So do device QA throttle your connection, test your page speed? I know Google says the. The recommended time for the page load is 200 milliseconds. So there's a lot that we can do to optimize to not even hit that mark. So, yeah, it's in a lot of our coding standards too, where we kind of like talk among the team to how to optimize and still be better about it every day.

Cool. Zog, you have anything to add to that?

Yeah, I would say if you're looking for a place to start figuring out where you can improve on your website, I'd go to HubSpot's website creator and plug in your URL.

Look at you go. I will make sure to have a link in the show notes to that plug right there. Cool. I think we kind of did it, folks. I mean, we solved it. Good job.

Page performance done shipped.

Guys, watch this video and your site will be faster.

Right? Right. Exactly. And you can send us checks if you actually see any improvements on your site. Yeah, I'll make sure.

Venmo, PayPal, whatever.

We're all there. Yeah, I'll also be in the show.

Notes.

John Fuller, Any closing thoughts?

No.

As profound as he started, he ends. That's exactly what I'd want to hear. Zog, Nori, John. Thank you, guys. John Fuller, it's been amazing talking to you. I miss you. Has been a while. Have a great day. It's Friday right now, so have a great weekend too. Okay, me too.

Thanks for having us.

Thank you all for having me. This was great.