JavaScript is the least of the blogs problems. There's a lot you can do. The first would be not using background images and lazy loading. Or, at the very least preload it... Images are also poorly sized / optimized. Main "bulk" of the page.
JavaScript is a problem.... You can strip out jQuery. There's nothing on your blog - or any Hubspot site or any other site - that warrants using an entire library for basic JavaScript ops and most people use JavaScript where the shouldn't anyways.
The forms you're not fixing. The other stuff you can just defer / async or dynamically load.
Your CSS is very spread out. Chaining / clogging waterfall. Split it / chunk it / regroup it. Whatever is relevant. That's a good start. Even then your scores will still be low especially on mobile - that's Hubspots fault not yours 🙂
If you really want you can do critical css, but that's typically an automated process - you can't do in HS - and in Hubspot I don't recommend this because it's more upkeep or little gain per the last paragraph.
@dennisedson I saw that. Really threw me off for a second 😂
I realized the noscript part was vague. If anyone is reading I meant sometimes dependent upon browser needs (old ones your customer base shouldn't use.... but do) you can `data` attribute src -> swap for native -> ISO / other polyfill but ISO usually in '21 -> noscript fallback w/ src (standard not data) + native lazy load if JS is disabled if you really want the full gamut. If you noted the issues with noscript + native lazy load (considering the polyill in the JS case) it's bc that's the best you can do in the "no js" case. No js = no polyfill. If you're on an ancient browser + no JS well... sorry you get the non-optimized way. But, no js + modern browser w/ lazy loading natively? That works.
Beyond that would be splitting by <source> in <picture> and more in depth techniques maybe you add meda queries, schema, etc. Like I said images can get really crazy / complicated.
A: I may have worded it poorly. I didn't mean lazy load te background image itself although you can very easily using Intersection Observer in like <10 lines of code. I meant what you clarified using an `<img ..>` tag using whatever positioning methods you want / lazy loading natively + a ISO polyill if you really need it. You can even <noscript> + JS fallback if you want. Add a `<picture>` element with the whole 9 yards. Completely up to you
B: I don't deal with marketers lol. What I say goes or you hire somebody else is my motto. Although that does tend to be the problem as you note. You can't really do that in HubL which is why I noted ages ago the CloudFlare API isn't really suficient for this. The best you can do with images in `resize_image_url` is ` 1x1` image to get the dominant color as a "solid" placeholder which has no intrinsic value for that type of stuff. If the marketers wants huge images... That's fine just scale them down run them through resizer before popping them in max size is maybe 1920x1080 for a bg image. But, images are the hardest part o web dev imo simply because o aspect ratios, management, sizes, etc.
If you really need @dpi scaling you can auto up and downscale risking degredation... But, for bg images nobody really cares it's supplemental content unless it's an intrinsic part of the design. But, for bg images that fancy they're almost always vectors making the preceeding point moot. If the marketer is doing it... yeah you can't fix that which goes to my many points of "marketers should not edit this stuff".
Re: Forms - I meant that when you use HubSpot's forms HubSpot loads a huge JavaScript file (forms v2 or whatever it's called) that actually renders the form. Because of that there's nothing you can really do about it outside of rolling your own forms / API work.
Re: Images - I meant that whenever you load a background image in CSS via `background-image()` as it's done on your blogs header. In HubSpot you can use an `img` tag and hubspot will automatically generate a srcset for it / serve optimized web formats if it can. That's better than using `background-image` but using background / headers like this is just a large resources on the page that has to be loaded. Whenever you use resources like this above the fold you typically add `<link rel="preload" as="image" ...>` for the asset in mind to start it as early as possible and help minimize LCP (largest contentul paint) web metrics.
The alternative (and better) method imo is to load two images. The first can be a very small / smooth low quality placeholder (called an LQIP / SQIP image) and then lazy load the real image. Effectively this says "let's have a very small render blocking resource that's kinda still the background, but speed up the page load and let the user see a "blur up" effect when the smoothed / low quality one -> turns into the real background image once the lazy loaded image has been loaded" and hopefully the difference isn't too noticeable / too much of a degredated effect. The LQIP / SQIP are significantly smaller in size when done properly and if you optimize your background image (prior to sticking it in the <img> tag) that can be a signiciant gain.
When doing background images you should always ensure there's a background with suficient contrast ratios to the foreground as well in case the image fails to load entirely (which is always a possibility) on poorer connections.
The best method is not using one at all and removing the asset entirely as background headers provide very little relevance to a user especially on a blog where people want to read your content rather than needing to see "flashy" marketing designs.
Bonus: It's also worth noting smaller pages (as in the full file size of the document - all downloaded images etc) tend to rank better as they're deemed better user experiences and that's valuable. Your page might load fast, but at the end o the day it's not a good experience to load 5 MB worth the data for a tiny webpage - and your ranking will reflect that although there's no official statement that Google takes this into account, but their May update and ancedotal data suggests this is true.
Another one: You can use progressive jpegs, but I'm not a fan defeats the point of performance ops we're going after here and they just load weird imo.
,
A: your advice is spot on. It is possible to lazy load bg images with some js, but I have found it easier to position an image and enjoy some native lazy loading love.
B: I do agree with your alternative method (loading two images), but how do you deal with marketers who when looking at the stock photos options say, bigger is better. I know you know exactly what I mean. Would you use resize hubl function here?
Typing from phone so apologies in advance for typos blah blah blah
JavaScript is the least of the blogs problems. There's a lot you can do. The first would be not using background images and lazy loading. Or, at the very least preload it... Images are also poorly sized / optimized. Main "bulk" of the page.
JavaScript is a problem.... You can strip out jQuery. There's nothing on your blog - or any Hubspot site or any other site - that warrants using an entire library for basic JavaScript ops and most people use JavaScript where the shouldn't anyways.
The forms you're not fixing. The other stuff you can just defer / async or dynamically load.
Your CSS is very spread out. Chaining / clogging waterfall. Split it / chunk it / regroup it. Whatever is relevant. That's a good start. Even then your scores will still be low especially on mobile - that's Hubspots fault not yours 🙂
If you really want you can do critical css, but that's typically an automated process - you can't do in HS - and in Hubspot I don't recommend this because it's more upkeep or little gain per the last paragraph.
