{"id":345169,"date":"2021-07-27T16:18:33","date_gmt":"2021-07-27T23:18:33","guid":{"rendered":"https:\/\/css-tricks.com\/?p=345169"},"modified":"2021-07-27T17:09:14","modified_gmt":"2021-07-28T00:09:14","slug":"learnings-from-a-webpagetest-session-on-css-tricks","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/learnings-from-a-webpagetest-session-on-css-tricks\/","title":{"rendered":"Learnings From a WebPageTest Session on CSS-Tricks"},"content":{"rendered":"\n
I got together with Tim Kadlec<\/a> from over at WebPageTest<\/a> the other day to use do a bit of performance testing on CSS-Tricks. Essentially use the tool, poke around, and identify performance pain points to work on. You can watch the video right here<\/a> on the site, or over on their Twitch channel<\/a>, which is worth a subscribe for more performance investigations like these. <\/p>\n\n\n\n Web performance work is twofold:<\/p>\n\n\n\n Step 1) Measure Things & Explore Problems Tim and I, through the amazing tool that is WebPageTest, did a lot of Step 1. I took notes as we poked around. We found a number of problem areas, some fairly big! Of course, after all that, I couldn’t get them out of my head, so I had to spring into action and do the Step 2 stuff as soon as I could, and I’m happy to report I’ve done most of it and seen improvement. Let’s dig in!<\/p>\n\n\n\n\n\n\n Largest Contentful Paint (LCP)<\/a> is one of the Core Web Vitals<\/a> (CWV), which everyone is carefully watching right now with Google telling us it’s an SEO factor. My LCP was clocking in at 3.993s which isn’t great. <\/p>\n\n\n\n I learned from Tim that it’s ideal if the First Contentful Paint (FCP) contains<\/em> the LCP. We could see that wasn’t happening through WebPageTest.<\/p>\n\n\n\n Things to fix:<\/p>\n\n\n\n Fixing technique and learnings:<\/p>\n\n\n\n Tim saw this right away as a fairly obvious problem. <\/p>\n\n\n\n In the waterfall above (here’s a super detailed article<\/a> on reading waterfalls from Matt Hobbs), you can see the HTML arrives in about 0.5 seconds, but the start of rendering (what people see, big green<\/strong> line), doesn’t start until about 2.9 seconds. That’s too dang long.<\/strong> <\/p>\n\n\n\n The chart also identifies the problem in a yellow line. I was linking out to a third-party CSS file, which then redirects<\/em> to my own CSS files that contain custom fonts. That redirect costs time, and as we dug into, not just first-page-load time, but every single page load, even cached<\/em> page loads. <\/p>\n\n\n\n Things to fix:<\/p>\n\n\n\n Fixing technique and learnings:<\/p>\n\n\n\n After re-testing with the change in place, you can see on a big article page the start render is a full 2 seconds faster on a 4G connection:<\/p>\n\n\n\n Tim had a neat trick up his sleeve for measuring Cumulative Layout Shift (CLS) on pages. You can instruct WebPageTest to scroll down the page for you. This is important for something like CLS, because layout shifting might happen on account of scrolling. <\/p>\n\n\n\n See this article about CLS and WebPageTest.<\/a><\/p>\n\n\n\n The trick is using an advanced setting to inject custom JavaScript into the page during the test:<\/p>\n\n\n\n At this point, we were testing not the homepage, but purposefully a very important page: our Complete Guide to Grid<\/a>. With this in place, you can see the CWV are in much worse shape:<\/p>\n\n\n\n I don’t know what to think exactly about the LCP. That’s being triggered by what happens to be the largest image pretty far down the page. <\/p>\n\n\n\n The CLS is more concerning, to me, because any<\/em> shifting layout is always obnoxious to users. See all these dotted orange lines? That is CLS happening:<\/p>\n\n\n\n Things to fix:<\/p>\n\n\n\n Fixing technique and learnings:<\/p>\n\n\n\n If anyone does know, feel free to hit me up. Such is the nature of performance work, I find. It’s a mixture of easy wins from silly mistakes, little battles you can fight and win, bigger battles that sometimes involves outside influences that are harder to win, and mysterious unknowns that it takes time to heal. Fortunately we have tools like WebPageTest<\/a> to tell us the real stories happening on our site and give us the insight we need to fight these performance battles.<\/p>\n\n\n\n
Step 2) Fix it<\/p>\n\n\n\nIdentified Problem #1) Poor LCP<\/h3>\n\n\n

srcset<\/code>, and is CDN hosted. All those things were failing on that particular image despire working elsewhere. <\/li>loading=\"lazy\"<\/code> on it, which we just learned<\/a> isn’t a good place for that. <\/li><\/ul>\n\n\n\n.gif<\/code> files, which is what that image was the day of the testing. We probably just shouldn’t use .gif<\/code> files for that area anyway.<\/li><?php the_post_thumbnail('', array('loading' => 'eager')); ?><\/code>. If it was an inline image, I’d do <img data-no-lazy=\"1\" ... \/><\/code> which tells WordPress what it needs to know.<\/li><\/ul>\n\n\nIdentified Problem #2) First Byte to Start Render gap<\/h3>\n\n\n
<\/figure>\n\n\n\n@font-face<\/a><\/code> right in my own CSS, with no redirects. Also using font-display: swap;<\/a><\/code>, but gotta work a bit more on that loading technique<\/a>. Can’t wait for size-adjust<\/a><\/code>.<\/li><\/ul>\n\n\n\n

<\/div>Identified Problem #3) CLS on the Grid Guide is Bad<\/h3>\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n

<img loading=\"lazy\" ...><\/code> elements. I get that lazy loading could<\/em> cause CLS, but these images have proper width<\/code> and height<\/code> attributes, which is supposed to reserve the exact space necessary for the image<\/a> (even when fluid, thanks to aspect ratio) even before it loads. So… what gives? Is it because they are SVG? <\/li><\/ul>\n\n\n\n
\n\n\n\n