SpeedCurve Blog https://www.speedcurve.com/blog/ Speed matters. Get the latest on how the areas of design and performance overlap with a focus on creating great user experiences. 2024 Holiday Readiness Checklist (Page Speed Edition!) https://www.speedcurve.com/blog/2024-holiday-readiness-checklist-page-speed <p><span style="font-size: 22px;">Delivering a great user experience throughout the holiday season is a marathon, not a sprint. Here are ten things you can do to make sure your site is fast and available every day, not just Black Friday.&nbsp;</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/holiday-readiness.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Your design and development teams are working hard to attract users and turn browsers into buyers, with strategies like:</p> <ul> <li>High-resolution images and videos</li> <li>Geo-targeted campaigns and content</li> <li>Third-party tags for audience analytics and retargeting</li> </ul> <p>However, all those strategies can take a toll on the speed and user experience of your pages &ndash; and each introduces the risk of introducing single points of failure (SPoFs).&nbsp;</p> <p><strong>Below we've curated ten steps for making your users happy throughout the holidays (and beyond).</strong> If you're scrambling to optimize your site before Black Friday, you still have time to implement some or all of these best practices. And if you're already close to being ready for your holiday code freeze, you can use this as a checklist to validate that you've ticked all the boxes on your performance to-do list.&nbsp;</p><h1>Optimize your monitoring</h1> <p>By now, you're most likely getting ready to head into a holiday code freeze/thaw/chill &ndash; which means you may not have a lot of opportunities to make big changes or optimizations. Here are a few things you can tackle right now that don't necessarily require higher-level approval or extra costs.</p> <h2><strong>1. Use both synthetic and RUM</strong></h2> <p><strong>Explore free tools.</strong>&nbsp;Hopefully this item is easy to check off. If you don't have a monitoring solution in place for the holidays, there are a lot of free trials out there you can use &ndash; including <a href="https://www.speedcurve.com/signup/">ours</a>! (Not sure if you need synthetic <em>or</em> real user monitoring? <a href="https://www.speedcurve.com/web-performance-guide/synthetic-vs-real-user-monitoring/">You probably need both.</a>)</p> <p><strong>Work around RUM deployment challenges.</strong>&nbsp;Real user monitoring (RUM) can sometimes be harder to implement on short notice compared to synthetic tools. <a href="https://support.speedcurve.com/docs/tag-managers">Use a tag manager</a> (e.g., Google Tag Manager) or A/B testing tool if you need to circumvent code changes.</p> <p><strong>Use CrUX in a pinch.</strong>&nbsp;If you're still out of luck in the RUM department, you can always look at field data from <a href="https://developer.chrome.com/docs/crux">Google CrUX</a> (Chrome User Experience Report). <em>Caveat: CrUX data isn't true RUM. It's collected from Chrome sessions only, and only for certain types of Chrome users.&nbsp;It also filters out origins and pages that don't meet specific eligibility requirements. But CrUX data is better than no RUM data.</em></p> <h2><strong>2. Make sure you&rsquo;re tracking the right metrics</strong></h2> <p><strong>Think beyond Core Web Vitals.</strong>&nbsp;While <a href="https://www.speedcurve.com/web-performance-guide/get-started-with-core-web-vitals/">Core Web Vitals</a> are typically a big focus for retailers because they have a direct impact on search rank, they are not the only indicators of a good user experience. In fact, for a lot of customers, iOS traffic &ndash; which Vitals can't track &ndash; is the most popular and has higher conversion rates. With so much of your revenue at stake, relying only on Core Web Vitals creates a huge blind spot.</p> <p><strong>Consider adding custom metrics.&nbsp;</strong>If you need to track iOS traffic and other clients,&nbsp;<a href="https://support.speedcurve.com/docs/custom-data">custom metrics</a> let you measure what is most important to your business.&nbsp; <br /><br /><strong>Don't forget about backend time.</strong> <a href="https://www.speedcurve.com/web-performance-guide/diagnose-time-to-first-byte/">Time to First Byte (TTFB) can be a page speed killer</a>, especially during peak traffic.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/ttfb.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p><strong>Track your CDN.</strong> If you use a content delivery network (CDN), then you need to know that CDN performance is critical during the holiday season. Did you know that you can <a href="https://www.speedcurve.com/blog/server-timing-time-to-first-byte/">track the health of your CDN</a> in RUM using server-timing headers? Capture cache hits/misses, time spent at the edge, origin, and even round-trip time (RTT) for most major CDN providers.&nbsp;</p> <h2><strong>3. Manage third-party scripts</strong></h2> <p>The average web page has 35+ third-party scripts. The average blocking time for the 10 most popular third parties is 1.4 seconds. Third parties can hurt important metrics, like Core Web Vitals. More important, slow or blocking third parties can hurt how users experience your site, which in turn can hurt your user engagement and business metrics.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/third-parties-no-bckgrnd.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /><strong>Audit the third-party scripts on your pages.</strong> I'm always amazed at how many sites have third-party tags that are no longer needed or in use. Remove unwanted scripts.</p> <p><strong>Defer or load asynchronously.</strong> Avoid single points of failure by deferring non-essential scripts or loading them asynchronously.</p> <p><strong>Set up tracking and performance budgets.</strong> Focus on third parties that are business critical or, more important, critical for the user experience. (More on performance budgets and alerts in section 6, below.)</p> <p><strong>Know your SLAs with third-party vendors.</strong> If possible, ask vendors about their release schedule during the holidays to avoid unpleasant surprises.&nbsp;</p> <p><strong>Put together a playbook for third-party failures.</strong> This is a simple guide that includes a point of contact for each script, kill switches, or procedures to remove scripts using a tag manager.</p> <p>Dig deeper into these tips and more with this <a href="https://www.speedcurve.com/web-performance-guide/third-party-web-performance/">guide to monitoring and optimizing third parties</a>.</p> <h2><strong>4. Make sure you&rsquo;re tracking the right pages</strong></h2> <p>For both RUM and synthetic monitoring, it's important that you are both measuring and classifying pages correctly. This is especially true as you get closer to holidays, when the performance of a product page can make or break a user's purchase decision.</p> <p><strong>Segment your pages in RUM.</strong> <a href="https://support.speedcurve.com/docs/rum-page-labels">Add RUM page labels that segment your pages</a> in a way that makes sense for your business and prevents confusion where you have too many unique values when trying to dissect performance issues.</p> <p><strong>Label your pages in synthetic.</strong> <a href="https://support.speedcurve.com/docs/synthetic-page-labels">Make sure your labels make sense</a>, but more important, ensure that the URLs you are monitoring are still valid. For example, last year's product link may no longer be relevant for a PDP page.</p> <p><strong>Don't forget to test your campaign landing pages... ideally <em>before</em> the promotion begins.</strong>&nbsp;Campaign landing pages are often outsourced to agencies that cannot (or do not) test with performance in mind. As a result, campaign pages can be the slowest pages on your site. Ensure you're monitoring current campaign landing pages early, before the promotion starts, in order to identify any performance gotchas during the main event.</p> <h2><strong>5. Establish a connection between metrics and business outcomes</strong></h2> <p><strong>Set a baseline for understanding the impact of performance on your customers (and your business metrics).</strong> Using the metrics you&rsquo;ve already identified, <a href="https://support.speedcurve.com/docs/create-correlation-charts">create correlation charts</a>&nbsp;(like the one below) that show you the relationship between your performance metrics and business metrics, such as conversion rate. This will help you understand what your performance budgets should be as you move into peak.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/worlds-best-correlation-chart.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p><strong>Benchmark your site against your competitors.</strong> Setting up a <a href="https://support.speedcurve.com/docs/competitive-benchmarking">competitive benchmarking dashboard</a>&nbsp;&ndash; which is easy to do with synthetic monitoring &ndash; is an effective way to see who's delivering a good UX and who isn't.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/benchmarks.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Check out <a href="https://app.speedcurve.com/benchmarks/">these industry benchmarks</a> for a current snapshot of how leading sites perform across a number of industries, including retail, travel, media, and more.</p> <h2><strong>6. Set up reporting early</strong></h2> <p><strong>Set up reports.</strong> Be proactive in reporting to stakeholders. Consider setting up <a href="https://support.speedcurve.com/docs/reports">automated weekly reports</a> for different stakeholder groups.&nbsp;Make sure people have visibility into the metrics&nbsp;<em>they</em>&nbsp;care about.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/report.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p><strong>Set up reporting ahead of time so key stakeholders know what to expect.</strong> Reach out to them proactively to make sure they don't have any questions about the data they are receiving and what the metrics mean. (Need help explaining what the difference page speed metrics mean and why they matter? Check out this <a href="https://www.speedcurve.com/web-performance-guide/glossary-of-web-performance-metrics/">glossary of common web performance metrics</a>.)</p> <h2><strong>7. Create performance budgets and set up just-right alerting</strong></h2> <p><strong>Performance budgets are a crucial tool for fighting regressions as quickly as possible.&nbsp;</strong>A performance budget is a threshold that you apply to the metrics you care about the most. You can then configure your monitoring tools to send you alerts &ndash; or even break the build, if you're testing in your staging environment &ndash; when your budgets are violated.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/budget.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p><a href="https://www.speedcurve.com/web-performance-guide/complete-guide-performance-budgets/">This guide</a> goes into much more detail about how performance budgets work and how to set them up, but here are the key points:</p> <ul> <li>Establish budgets for your key metrics</li> <li>Create budgets for render-blocking third parties and third parties that are known to have Long Tasks</li> <li>Set up alerting, but be wary of creating alert fatigue</li> <li>Again, make sure that alerts go to the right people</li> </ul> <h1>Holiday post-mortem</h1> <p>It's common for people to put more effort into preparation. It's also common for the holiday season to take it's toll. We highly encourage taking some well-deserved time to yourself after the holiday crunch is over &ndash; but before you do, here are a few things that will help you unload after the holidays, and put you in a great position to hit the ground running in the new year.</p> <h2><strong>8. Look at your historical data</strong></h2> <p><strong>Identify each anomaly and drill down into your data to understand why it happened.</strong> Post-mortems shouldn't be about finger pointing. Identifying issues that could have been prevented ensures you are ready next time.</p> <p><strong>Report issues to third-party vendors.</strong> If you experienced issues with any of your third parties, share your data with the provider and work with them to improve.</p> <h2><strong>9. Improve your monitoring and testing</strong></h2> <p><strong>Identify changes in user behavior.</strong> Use your RUM data to identify how user behavior may have changed during the holiday period. Make note of heavily trafficked pages that you were not monitoring synthetically. Your users should help dictate what you are monitoring. Were you prepared for changes to traffic patterns? Can what you observed potentially help with scalability testing?</p> <p><strong>Use the data you're gathered above to refine your synthetic testing.</strong> Update URLs, browsers, devices, geolocations, etc. to align with what you've learned about your users via your RUM data.</p> <h2><strong>10. Celebrate wins!</strong></h2> <p><strong>Acknowledge the great work that got you through the holidays.</strong> The long hours. The attention to detail. The collaborative cross-functional team spirit that all went into creating a great user experience. We see you!</p> <p>Send out a fun post-holiday card across your org, using your data to celebrate wins such as:</p> <ul> <li><strong>Uptime</strong> &ndash; Was your site available 99% of the time or more? That's a win!</li> <li><strong>Key performance metrics</strong> &ndash; Did you stay within your regression thresholds for important metrics like backend time, start render, and Core Web Vitals? That's fantastic and definitely worth sharing.</li> <li><strong>Third parties</strong> &ndash; Were your third-party scripts performant throughout the holidays? Shout it from the rooftops!</li> <li><strong>Business metrics</strong> &ndash; Do your correlation charts show that you delivered a speedy experience to a significant amount of your converted traffic? Huge win!</li> </ul> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/dog-party.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h2><strong>It's not too late!</strong></h2> <p>If you're like me and this season has crept up on you, fear not! There's still a lot you can do to keep your site fast &ndash; and your users happy &ndash; through the holidays and beyond.&nbsp;</p> <p><strong>If you're already a SpeedCurve user</strong> and you have questions about any of these strategies, send us a note at support@speedcurve.com and we'll be happy to help!</p> <p><strong>If you're not using SpeedCurve yet</strong>, <a href="https://www.speedcurve.com/signup/">start your free trial</a> and send us your questions at support@speedcurve.com.</p> <p><a href="https://www.speedcurve.com/signup/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/523/customer-logos-free-trial-banner.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> Wed, 30 Oct 2024 00:00:00 +1300 NEW: Vitals dashboard updates and filter improvements https://www.speedcurve.com/blog/new-core-web-vitals-updates <p><span class="large-para">Our development team recently emerged from an offsite with two wonderful improvements to SpeedCurve. The team tackled a project to unify our filtering, and then they over-delivered with a re-Vital-ized dashboard that I'm finding to be one of the most useful views in the product. </span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/product-vitals-dashboard-oct2024-hero.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Take a look at the recent updates &ndash; and a big thank you to our amazing team for putting so much love into SpeedCurve!</p><h2>Start simple, go deep...</h2> <p>Performance is hard, complex, and riddled with nuance. There is a sea of data collected by SpeedCurve and endless ways to interpret that data.</p> <p>New users of the product crave good design and simplicity in an effort to make sense of this firehose of performance information.</p> <p>Power users desire diagnostic capabilities that require extensive use of the latest and greatest browser APIs.</p> <p>Sometimes it's hard to do both and still provide meaningful information to both audiences. We embrace this challenge and, wherever possible, adopt the principle of starting with a simplistic overview and progressing into meaningful, actionable data.</p> <h2>Vitals dashboard improvements</h2> <p>When we first launched the Vitals dashboard back in December of 2020, we focused on keeping it simple. Core Web Vitals were still a new concept, and educating folks was the primary goal.</p> <p>In the last four years, a lot has changed:</p> <ul> <li>First Input Delay (FID) <a href="https://www.speedcurve.com/blog/interaction-to-next-paint-core-web-vitals/">was given the boot</a> in favor of <a href="https://www.speedcurve.com/blog/check-core-web-vitals-inp/">Interaction to Next Paint (INP)</a>.</li> <li>Chrome exposed browser APIs providing attribution of element selectors and timing subparts for LCP and INP.</li> <li>Finally, we heard from many of you who wanted to expand the scope of the dashboard to include other meaningful metrics that were not technically considered Core Web Vitals.&nbsp;</li> </ul> <h3>More metrics: Backend Time and First Contentful Paint</h3> <p>We've added Backend Time and First Contentful Paint (FCP) to the Vitals dashboard. We also continue to show Total Blocking Time (TBT).</p> <p>Those three metrics tell us a lot about potential causes of a poor user experience:</p> <ul> <li><strong>Backend Time</strong> <a href="https://www.speedcurve.com/web-performance-guide/diagnose-time-to-first-byte/">isn't always a black box</a>. RUM can tell you where that time is being spent, whether its network related or due to CDN or origin issues.</li> <li><strong>First Contentful Paint</strong> tells us when the page begins to render and effectively&nbsp;become consumable by an end user.</li> <li><strong>Total Blocking Time</strong> gives us clues around CPU-intensive tasks that block rendering and interactivity with the page.</li> </ul> <h3>Vitals Dashboard walkthrough</h3> <p><em>The following assumes you are leveraging both Synthetic and RUM. If you aren't using our RUM, you'll still get a look at your synthetic data. (If you'd like to add RUM to your monitoring, contact us at support@speedcurve.com and we'll set you up with a free trial!)</em></p> <p>Focusing on Largest Contentful Paint (LCP), let's walk through an example of how to leverage your Vitals dashboard to find and fix issues with your Vitals.</p> <p><strong>1. Review the color-coded tabs to see which metric needs attention</strong></p> <p>Beginning with the overview at the top of the dashboard, you can look at the tab for each metric to see what needs attention. Each tab is color-coded so you can see if it's Good (green), Needs Improvement (orange), or Poor (red). These thresholds are aligned with Google's recommended <a href="https://web.dev/articles/vitals">thresholds</a>.&nbsp;</p> <p><strong>2. Select a tab to drill down into a metric</strong></p> <p>Selecting the LCP tab lets us know just where we sit for the population we are investigating. We've also included badges to make it clear which browsers support each metric. (That's right &ndash; Safari doesn't support LCP, so you can't track performance for your iPhone users.)</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/vitals-tab-overview.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Vitals overview with summary number" /></p> <p><strong>3. View historical performance</strong></p> <p>Further down the dashboard, a time series chart provides a historical look at the metric, with added context around volume (for RUM customers only). If your LCP is poor in the middle of the night, should you care? Maybe!</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/vitals-time-series.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="LCP time series showing poor performance during off peak times" /></p> <p><strong>4. Get a high-level view of historical performance for Good, Needs Improvement, and Poor cohorts</strong></p> <p>For added context, the distribution charts show a historical view of the experience of a population &ndash; and, of course, a histogram representing the entire population of experiences for LCP.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/vitals-distributions.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="distribution charts showing a time series distribution and histogram" /></p> <p>Clearly there's room to improve LCP. Now what?</p> <p><strong>5. Identify problem pages</strong></p> <p>Seeing tabular data for LCP (below) allows us to identity problematic pages that need attention.</p> <p>In this case, Home seems to be the only page getting a 'poor' rating for LCP. It's also the most popular page by volume, as indicated by the % of page views.<br /><br /><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/vitals-by-page-home.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Table showing LCP and subparts by page" /></p> <p><strong>6. Identify the most problematic elements on the page</strong></p> <p>After re-filtering the dashboard to the home page, the updated heat map (below) shows the most problematic LCP elements on the page. Surprise, there are many!</p> <p>The LCP element is not necessarily going to be consistent across experiences, even for the same page. As shown, the text element for the cookie consent dialog is the biggest offender, but this might not always be the case (when users are already opted-in, for example).</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/vitals-by-selector.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Table showing LCP and subparts by element selector" /></p> <p><strong>7. View data for subparts</strong></p> <p>The subparts data isn't necessarily relevant for the text element identified above, but for other elements, such as images, we can see how each subpart is trending over time to identify any regressions that may have been introduced by a recent change.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/vitals-subparts.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="LCP subparts over time" /></p> <p><strong>8. See visualizations of problem areas on the page</strong></p> <p>Our synthetic data gives us even more diagnostic detail, including visual identification of the LCP element, framed in red below.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/vitals-element-render.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Screenshots before and after LCP element is painted" /></p> <p><strong>9. Get detailed diagnostics, so you know HOW to fix issues</strong></p> <p>Finally, the improvements specific to LCP for this page are shown. Maybe there is some low-hanging fruit here. (I'm looking at you, lazy-loaded LCP image!) This list of optimization suggestions &ndash; each of which can be expanded to get more information &ndash; is a good jumping-off point for making improvements.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/vitals-recommendations.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Recommendations for improving LCP from Lighthouse" /></p> <h2>Unified filtering</h2> <p><em>&ldquo;Consistency is one of the most powerful usability principles: when things always behave the same, users don&rsquo;t have to worry about what will happen.&rdquo; - Jakob Nielson</em></p> <p>SpeedCurve is now eleven years old. One of the things we love so much about our product is how it's evolved over time. However, in some cases, parts of the UI didn't come along for the ride. This was the case with our dashboard filters. This has been a nagging 'to-do' that we've finally checked off our list, courtesy of our awesome dev team.&nbsp;</p> <p>You'll find that our filters now work the same way across ALL of your dashboards.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/filters.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Main filter with dropdown of available options" /></p> <p>As a VERY big bonus, you'll find more options available on most dashboards, including Favorites.</p> <p>There have been many user requests for filter option updates to specific dashboards. We <em>think</em> we've hit them all, but if we missed anything, <a href="mailto:support@speedcurve.com">let us know!</a></p> <p>We hope you enjoy the latest updates. Keep the feedback coming &ndash; and go hug a developer today!</p> <p><a href="https://www.speedcurve.com/signup/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/522/customer-logos-free-trial-banner.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> Tue, 15 Oct 2024 00:00:00 +1300 Performance Hero: Sia Karamalegos https://www.speedcurve.com/blog/performance-hero-sia-karamalegos <p><span class="large-para">Sia Karamalegos is a web performance diva we've come to know through her many articles, workshops, conference talks, and her stint as an MC at performance.now() last year &ndash; not to mention her role in speeding up a pretty big slice of the internet!&nbsp;</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/520/sia.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Sia is kind, funny, smart as heck, and always down to talk web performance (especially if you have a Shopify site). For those reasons and many more, we are excited to share that Sia is this month's Performance Hero!</p><p>Sia currently works as a freelance web performance engineer. She was previously at Shopify, helping their merchants make their sites faster. She is a Google Developer Expert in web technologies, an active member of the W3C Web Performance Working Group, co-organizer of the Eleventy Meetup and... well, you can <a href="https://sia.codes/about/">read the rest here</a>.</p> <h2>Recent performance win at Shopify</h2> <p>While Sia's impressive bio speaks for itself, her commitment to improving performance cannot be overstated. She shared a recent performance win with us from her time at Shopify, which I'll paraphrase here (and look forward to learning more about in a future post or conference talk).</p> <p>Sia and her team at Shopify noticed a troubling pattern where a large number of merchant sites were lazy loading LCP elements. She mined the <a href="https://httparchive.org/">HTTPArchive</a> and discovered that close to 70% of Shopify sites were guilty of using this antipattern.</p> <p>After finding the issue and failing to convince engineering of its importance, Sia developed a new Liquid feature on her own (Liquid is Shopify's templating language) that made it possible to fine tune lazy loading while not losing the benefit of default lazy loading of images below the fold. The results were pretty staggering!</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/520/shopify_lcp.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="LCP distribution improving over time for Shopify themes" /></p> <p style="text-align: center;"><em>Green = good!</em></p> <p>While the uptake isn't immediate for the fix (due to the need for a Shopify theme developer to implement the new features), it's anticipated that adoption will continue to grow over time. You can read more about this on the&nbsp;<a href="https://performance.shopify.com/blogs/blog/announcing-new-liquid-features-for-better-web-performance">Shopify performance blog</a>.&nbsp;</p> <h2>Free new resource: Shopify Theme Vitals!</h2> <p>The timing of this post couldn't be better. Sia very recently launched a new free resource, <a href="https://themevitals.com">Shopify Theme Vitals</a>.&nbsp;</p> <p>Shopify Theme Vitals leverages the <a href="https://httparchive.org/">HTTPArchive</a> and <a href="https://developer.chrome.com/docs/crux">Chrome User Experience report (CrUX)</a> to provide Shopify devs and merchants with an aggregated data set of Core Web Vitals (CWV)&nbsp;performance by theme.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/520/shopifythemes.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Shopify Theme Performance showing themes by CWV performance." /></p> <h2>Where you can find Sia...</h2> <p>You can follow and learn more about &ndash; and hire! &ndash; Sia here:</p> <ul> <li><a href="https://sia.codes/">sia.codes</a></li> <li><a href="https://front-end.social/@sia">Mastodon</a></li> <li><a href="https://www.linkedin.com/in/karamalegos/">LinkedIn</a></li> </ul> <p>We are thrilled to add Sia to <a href="https://www.speedcurve.com/blog/tag/performance-hero/">our growing list</a> of performance heroes! Past heroes include: <a href="https://www.speedcurve.com/blog/performance-hero-michelle-vu/">Michelle Vu</a>, <a href="https://www.speedcurve.com/blog/web-performance-hero-estela-franco/">Estela Franco</a>, and <a href="https://www.speedcurve.com/blog/tag/performance-hero/">Paul Calvano</a>.<br /><br /><em>Do you have someone you'd like to recognize as a Performance Hero? <a href="mailto:support@speedcurve.com">Let us know!</a></em></p> <p><a href="https://www.speedcurve.com/signup/"><em><img class="blog-img" src="https://blog-img.speedcurve.com/img/520/customer-logos-free-trial-banner.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></em></a></p> Tue, 01 Oct 2024 00:00:00 +1300 How to provide better attribution for your RUM metrics https://www.speedcurve.com/blog/providing-better-attribution <p><span class="large-para">Here's a detailed walkthrough showing how to make more meaningful and intuitive attributions for your RUM metrics &ndash; which makes it much easier for you to zero in on your performance issues.</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/better-attributions.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p><a href="https://www.speedcurve.com/web-performance-guide/synthetic-vs-real-user-monitoring/">Real user monitoring</a> (RUM) has always been incredibly important for any organization focused on performance. RUM &ndash; also known as field testing &ndash; captures performance metrics as real users browse your website and helps you understand how actual users experience your site. But it&rsquo;s only in the last few years that RUM data has started to become more actionable, allowing you to diagnose what is making your pages slower or less usable for your visitors.</p> <p>Making newer RUM metrics &ndash; such as&nbsp;<a href="https://www.speedcurve.com/web-performance-guide/get-started-with-core-web-vitals/">Core Web Vitals</a>&nbsp;&ndash; more actionable has been a significant priority for standards bodies. A big part of this shift has been better attribution, so we can tell what's actually going on when RUM metrics change.</p> <p>Core Web Vitals metrics &ndash; like Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) &ndash; all have some level of attribution associated with them, which helps you identify what exactly is triggering the metric. The&nbsp;<a href="https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Long_animation_frame_timing">LoAF API</a>&nbsp;is all about attribution, helping you zero in on which scripts are causing issues.</p> <p>Having this attribution available, particularly when paired with meaningful subparts, can help us to quickly identify which specific components we should prioritize in our optimization work.</p> <p>We can help make this attribution even more valuable by ensuring that key components in our page have meaningful, semantic attributes attached to them.</p><h2>How the browser handles attribution</h2> <p>When a metric that has some level of attribution associated with it &ndash; like LCP or INP &ndash; is triggered, the browser provides us with the element that triggered the measurement.</p> <p>For the Largest Contentful Paint (LCP) metric, for example, attribution is provided in the <code>element</code> property.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/screenshot_2024-08-21_at_8.55.39_am.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="A screenshot showing properties for the LCP metric" /></p> <p>For Interaction to Next Paint (INP), attribution comes in the form of the <code>target</code> property:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/screenshot_2024-08-21_at_8.56.11_am.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="A screenshot showing properties for the INP metric" /></p> <p>In either case, the browser will provide us with a selector for that specific element containing any class or ID attributes that may be applied.</p> <p>Consider the following three links:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/carbon-(5).png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>If the first link is clicked and triggers an INP, we will get a <code>target</code> of <code>a.btn-primary</code>. For the second link, the browser will return <code>a#myLink</code>. For the third, since there are no classes or IDs to provide, the browser will simply provide us with a <code>target</code> of <code>a</code> .</p> <p>Already, there&rsquo;s a meaningful difference in what we see for attribution. Since IDs are required to be unique on a page, we can quickly grab the <code>#myLink</code> attribute and figure out which element is responsible.</p> <p>The other two targets are not as clear. There could be any number of links on our page triggering the <code>a</code> target, and classes are not required to be unique, so we could be staring at a bunch of <code>a.btn-primary</code>'s in our page as well.</p> <p>At this point, many RUM providers (like SpeedCurve) will try to help you out by walking back up the elements in your page to provide you with a more complete and specific path to the target element.</p> <p>To do this, they will start by fetching the parent element of the target element, and record both the type of element and any classes or IDs associated with it.</p> <p>For example, consider the following markup:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/carbon-(4).png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>The browser will provide us with a target of <code>a.classButton</code>, but many RUM providers (ourselves included), will walk up the DOM and provide you with an element selector of:</p> <p style="padding-left: 30px;"><code>div.main&gt;div.large&gt;p.center&gt;a.classButton</code></p> <p>The goal is to provide you with as unique a path as possible to help you pinpoint exactly which element on your page is involved.</p> <p>In SpeedCurve, that attribution is provided for both LCP and INP so you can quickly identify exactly what components are impacting your performance. Here&rsquo;s an example heatmap from SpeedCurve showing this selector in action:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/screenshot_2024-08-21_at_8.29.41_am.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="A screenshot of SpeedCurve's heatmap for INP" /></p> <p>Some of these selectors (<code>#playBtnStartIcon</code>, <code>#cmpWrapper</code> , etc) are fairly intuitive. But notice the complex path to some of the other INP triggers.</p> <p>For example, we could probably figure this out, but it&rsquo;s going to take us hopping into the source of the page to drill into what element exactly is triggering this one:</p> <p style="padding-left: 30px;"><code>article.article-body.prose.max-w-none.pb-7.pt-5.prose-figure:max-w-full.prose-ol:pl-10&gt;p&gt;a</code></p> <p>In this case, the browser wasn&rsquo;t even able to find a class name so we just get a series of div selectors that is going to be tricky to hunt down:</p> <p style="padding-left: 30px;"><code>div&gt;div&gt;div&gt;div&gt;div&gt;div&gt;div&gt;div&gt;div</code></p> <p>Contrast that with the attribution for the play button (<code>#playBtnStartIcon</code>). This selector is immediately intuitive (and short!) because we had a meaningful ID on the element itself, so there was no need to walk up the DOM and get a long list of selectors.</p> <h2>Making attribution meaningful</h2> <p>We can make it much easier for ourselves to quickly identify what elements are involved by ensuring that key components on our page have meaningful flags for attribution.</p> <p>With SpeedCurve, there are two ways of accomplishing this:</p> <ul> <li>providing a relevant `id` attribute</li> <li>using the `data-sctrack` attribute</li> </ul> <h3>Using a relevant `id` attribute</h3> <p>One option we have is to provide an <code>id</code> attribute on our key components. While SpeedCurve is working to provide you with a meaningful selector, as soon as an element with an <code>id</code> is discovered, we will stop walking up the DOM. The <code>id</code> attributed is required to be unique, so we&rsquo;re able to provide just that.</p> <p>You&rsquo;ve already seen an example of this where the target element itself had an ID directly applied to it, but this also works for shortening the selector in general.</p> <p>Let&rsquo;s revisit our markup from earlier, but this time we&rsquo;ll add an ID to our entry paragraph:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/carbon-(6).png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>The browser will still provide a <code>target</code> of <code>a.classButton</code>, but now SpeedCurve will walk up the DOM, see the unique ID and provide a much more intuitive element selector of <code>#heroParagraph&gt;a.classButton</code> .</p> <h3>Using the `data-sctrack` attribute</h3> <p>In SpeedCurve, we provide you with an alternative approach to attribution, in case you would rather not sprinkle a bunch of ID&rsquo;s throughout your markup.</p> <p>Our RUM script&nbsp;<a href="https://support.speedcurve.com/docs/rum-js-api#data-sctrack">will also look for the <code>data-sctrack</code> attribute</a> while trying to generate our element selector.</p> <p>There&rsquo;s one important difference here between how <code>data-sctrack</code> and <code>id</code> are used. In the case of <code>id</code>, we treat that attribute as part of a selector path. If we find a <code>data-sctrack</code> attribute, however, we will simply provide the value of that attribute&mdash;not a full selector path.</p> <p>For example, in the previous markup, the element selector provided was <code>#heroParagraph&gt;a.classButton</code>. If, however, we adjusted our markup to use a <code>data-sctrack</code> attribute like so:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/carbon-(7).png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>The element selector we would provide would be <code>heroParagraph</code> , not the full path to the link itself.</p> <p>Neither approach is necessarily inherently better than the other. It comes down to your specific approach to markup, and the components you&rsquo;re using.</p> <p><!-- notionvc: 8b68f536-2e5b-4bf9-ae91-254369c75415 --></p> <p>In either case, however, providing unique <code>id</code> &rsquo;s or <code>data-sctrack</code> attributes on your page will result in much more meaningful and intuitive attribution, making it much easier for you to zero in on your performance issues.</p> <p><a href="https://www.speedcurve.com/signup/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/517/customer-logos-free-trial-banner.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> Tue, 03 Sep 2024 00:00:00 +1200 NEW: Paper cuts update! https://www.speedcurve.com/blog/paper-cuts <p><span class="large-para">Paper cut: (literal) A wound caused by a piece of paper or any thin, sharp material that can slice through skin. (figurative) A trivial-seeming problem that causes a surprising amount of pain.</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/516/bandage-thumbs-up.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>We all love big showy features, and this year we've released our share of those. But sometimes it's the small stuff that can make a big difference. We recently took a look at our backlog of smaller requests from our customers &ndash; which we labelled "paper cuts" &ndash; and decided to dedicate time to tackle them.</p> <p>Are they <em>all</em> glamorous changes? Maybe not, though some are pretty exciting.</p> <p>Are they worthy of a press release? Ha! We don't even know <em>how</em> to issue a press release.</p> <p>Will they make your day better and put a smile on your face? We sure hope so.</p> <p>In total, our wonderful development team tackled more than 30 paper cuts! These include:</p> <ul> <li>Exciting new chart types for Core Web Vitals and User Happiness</li> <li>Filter RUM data by region</li> <li><span style="color: #1f1f1f;">Create a set of tests for one or multiple sites or custom URLs</span></li> <li><span style="color: #1f1f1f;">Test directly from your site settings when saving changes</span></li> <li>Usability improvements</li> <li>Better messaging for test failures</li> <li>And more!</li> </ul> <p>Keep scrolling for an overview of some of the highlights.&nbsp;</p><h2>On-demand testing updates</h2> <p>This has been an area we've focused on a lot this year. We made a lot of <a href="https://www.speedcurve.com/blog/on-demand-web-performance-testing/">updates to the Test Now functionality</a>&nbsp;back in February of this year. One of the biggest requests from our users was the ability to test a single url within a site. Using the 'Test Now' modal, you can now select anywhere from one to many URLs to test on demand.<br /><br /><img class="blog-img" src="https://blog-img.speedcurve.com/img/516/url_test.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="On-demand testing modal showing the ability to test individual urls" /></p> <p>In addition, we've given you the ability to test directly from your site settings when saving changes.</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/516/testnowsettings.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Save and Test button in site settings" /></p> <p>If you are a user of our API, make sure you check out the <a href="https://support.speedcurve.com/reference/create-a-snapshot">new snapshots endpoint</a> in our v2 API (currently in beta). This endpoint provides the ability to create a set of tests for one or multiple sites or custom URLs.</p> <h2>UI updates</h2> <p>Okay, so maybe this one is a little more flashy than we let on. We've updated our User Happiness and Core Web Vitals RUM time series charts to 100% stacked column charts in our Performance and Users dashboards. This gives you the ability to see the distribution of users in each bucket of User Happiness, as well as thresholds for Core Web Vitals.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/516/stacked-happiness.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="100% stacked bar chart for user happiness metric" /></p> <p>In addition, we've added page views time series data to our Core Web Vitals time series charts. This is incredibly helpful and adds a layer of context to the data. A common pattern is seeing metrics degrade during low traffic times due to the size of the sample, caching inefficiency (for example, cold CDN cache), and routine maintenance.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/516/stackecwv.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="100% stacked chart and time series for core web vitals" /></p> <h2>Regional performance</h2> <p>We've had the ability to segment data by country since the inception of RUM. We are now exposing the second-level geography (region) in our tables in the Performance dashboard. For customers looking to move more to the edge and get the most from their investment in distributed computing and content delivery networks, having an understanding of how pages perform within the borders of a country is extremely useful.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/516/regions.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="Regional performance for the US." /></p> <h2>A whole lot more...</h2> <p>There were more than 30 paper cuts tackled by our wonderful development team. These included usability improvements, better messaging for test failures additional filtering options and more. We hope you enjoy these updates. We really enjoyed tackling them.&nbsp;</p> <p>Have a paper cut you'd like us to tackle? <a href="mailto:support@speedcurve.com">Let us know!</a></p> <p><a href="https://www.speedcurve.com/signup/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/516/customer-logos-free-trial-banner.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> Mon, 19 Aug 2024 00:00:00 +1200 NEW: Improving how we collect RUM data https://www.speedcurve.com/blog/improving-how-we-collect-rum-data <p><span class="large-para">We've made improvements to how we collect RUM data. Most SpeedCurve users won't see significant changes to Core Web Vitals or other metrics, but for a small number of users some metrics may increase.</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/515/rum-changes.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>This post covers:</p> <ul> <li>What the changes are</li> <li>How the changes can affect Core Web Vitals and other metrics</li> <li>Why we are making the changes now</li> </ul><h2>What's changing?</h2> <p>By default, SpeedCurve RUM used to send its main beacon shortly after the load event fires, another soon after the visitor first interacts with the page, and then further beacons as User Timing marks and measures (AKA custom metrics) are added.</p> <p>This approach was sound when our main focus was measuring how quickly pages loaded or routes changed. But newer metrics &ndash; such as Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP) &ndash; don't stop at page load or first interaction. As a result, they need to be measured throughout the entire lifecycle of the page.</p> <p>To work around some of the limitations of the current approach, we've&nbsp;<a href="https://support.speedcurve.com/docs/rum-js-api#luxminmeasuretime">added options that allow sites to delay when they send the beacon,</a>&nbsp;but these must be implemented on a site-by-site basis &ndash; which isn't ideal.</p> <p>Starting August 7, 2024, we've improved our defaults. <strong>Now performance metrics will be captured for longer and beacons will be sent at the earliest of 60 seconds after page load starts, or when the visitor leaves the page if that happens sooner.</strong></p> <p>Sites such as SPAs, which use&nbsp;&nbsp;<code>LUX.auto = false</code>&nbsp;to control when they send the beacons themselves, are opted out of our default behaviour and won't see any changes.</p> <p>To understand which metrics are affected and how much they change, we've run the old and new measurement pipelines in side-by-side and compared the data each produces.</p> <h2>How your Core Web Vitals may change</h2> <p>Most customers won't see significant changes to Core Web Vitals or other metrics, but for a small number of customers some metrics will increase.</p> <p>Some metrics are fixed at the point they're measured, while others can change with time or as a result of user interaction.</p> <p>First Contentful Paint is an example of a metric that's fixed in time. It's the timestamp of when the browser first displayed content. Because there is only ever one first paint, it can't change after that point.</p> <p>Other metrics can change. A page can display a larger image, content can move around, and visitors can trigger slower interactions.</p> <p>Sending the beacon later means we have a longer window to watch for changes to these metrics, and in some cases we can capture changes that we could not detect previously.</p> <p>The metrics that we've seen increase for some customers are:</p> <ul> <li>Largest Contentful Paint (LCP)</li> <li>Cumulative Layout Shift (CLS</li> <li>Interaction to Next Paint (INP)</li> </ul> <p>Here are some examples of things we've come across that can lead to metrics increasing as a result of sending the beacon later:</p> <h3>Largest Contentful Paint (LCP)</h3> <p>LCP stops being measured when there's an <strong>Input Event</strong> (click, tap or keypress) or the visitor scrolls the page.</p> <p><strong>Hover Events</strong> aren't classed as Input Events. If a Hover event triggers a larger image to be loaded or a larger text paint, that can cause LCP to increase.<br /><br />Two examples where we've seen LCP increase due to visitor interaction:</p> <ul> <li>Product pages that show zoomed product images on hover</li> <li>Desktop 'mega-menus' where the images embedded in it are larger than the main images on the page</li> </ul> <p>Here's an example from a retailer's category page. The promotional banner at the bottom of the menu is larger than the product cards. As a result, the banner will become the LCP element when the menu is shown.</p> <p style="text-align: center;"><img class="blog-img" src="https://blog-img.speedcurve.com/img/515/menu-banner-casues-new-lcp.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Promotional Banner in menu becomes LCP when it's shown on hover" /><em>Promotional banner becomes LCP element when a visitor hovers on the menu</em></p> <p>The hover behaviour is a known 'gotcha' for LCP. If you're interested in following how it might change in the future, there's <a href="https://github.com/w3c/largest-contentful-paint/issues/108">an issue against the specification that discusses it further</a>.</p> <p>The other common case where we've seen LCP increase is when a script triggers a late large paint, for example by displaying a dialog for a consent manager or an email subscription popup.</p> <p><strong>These examples highlight that LCP doesn't always measure the most important content.</strong> This is why I encourage sites to <a href="https://www.speedcurve.com/blog/element-timing-one-true-metric/">use Element Timing to measure the visual elements that really matter to their user experience</a>.</p> <h3>Cumulative Layout Shift (CLS)</h3> <p>Layout shifts that are triggered within 500ms of a user's interaction are ignored for CLS; however, scrolling is not considered an interaction for CLS purposes, so content that moves around or changes size as someone scrolls will create new layout shifts and potentially a higher CLS score.</p> <p>News sites &ndash; where advertisements are lazy-loaded or refreshed as the page scrolls and the advert creative is larger than the space reserved for it &ndash; are an example where CLS scores can get worse due to the longer measurement time.</p> <p>Here's a news article where an ad creative loads on scroll. The publisher has reserved space for the ad unit, but the creative that loads is larger than the space. As a result, there's a layout shift as the content below the ad is pushed down.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/515/lazy-loaded-ad-slot-causes-layout-shift-.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Layout Shift triggered by lazy loaded ad creative" /></p> <p style="text-align: center;"><em>Layout Shift triggered by an lazy loaded advert whose creative is larger than the space reserved for it</em></p> <p>Scripts that are triggered by the load event, or a long timer and insert content into the page, are another example where CLS may increase.</p> <h3>Interaction to Next Paint (INP)</h3> <p>Visitors may interact with a page more than once. A shopper might examine different images of an item before adding it to their basket. Someone might like multiple posts on a social network before responding to one of their friends. There's no guarantee which of these interactions will generate the highest INP time.</p> <p>By extending the wait before we send the RUM beacon, we're more likely to capture the slowest and most annoying interaction on the page.</p> <h2>Why we changed our approach</h2> <p>We identified that we needed to capture data for a longer time a while ago, but constraints in our RUM processing pipeline made it difficult to implement.</p> <p>Our existing pipeline has served us well. Using Fastly's beacon termination service to capture and forward RUM data, and VCL to enrich it, has proved really robust over the last eight years. But as our product has grown and new metrics have been introduced, the pipeline has become more complex. As a result, we've started to run into the pipeline's limitations more frequently.</p> <p>We knew that sooner or later we'd need to re-engineer the pipeline. As part of adding diagnostics for Core Web Vitals, we've re-implemented the pipeline using Fastly's edge compute. (We're saving a deeper overview of our new pipeline for another post.)</p> <p>Sending the beacon later has a number of benefits, now and down the road:&nbsp;</p> <ul> <li>Improves the accuracy of the metrics we're capturing&nbsp;</li> <li>Allows us to simplify our RUM processing pipeline</li> <li>Made it easier to implement attribution for INP and LCP</li> <li>Smooths the way for adding other features we have planned for the future</li> </ul> <p>That sounds like a win for everyone.</p> <p>If you've any questions about the changes, or notice something in your data that you can't explain we'd love to hear from you. Send us a note at&nbsp;support@speedcurve.com.</p> <p><a href="https://www.speedcurve.com/signup/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/515/customer-logos-free-trial-banner.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> Wed, 07 Aug 2024 00:00:00 +1200 15 page speed optimizations that sites ignore (at their own risk) https://www.speedcurve.com/blog/15-neglected-page-speed-optimizations <p><span class="large-para">A recent analysis of twenty leading websites found a surprising number of page speed optimizations that sites are not taking advantage of &ndash; to the detriment of their performance metrics, and more importantly, to the detriment of their users and ultimately their business.</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/483/optimizations-hero.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>I spend a lot of time looking at waterfall charts and web performance audits. I recently investigated the test results for twenty top sites and discovered that many of them are not taking advantage of optimizations &ndash; including some fairly easy low-hanging fruit &ndash; that could make their pages faster, their users happier, and their businesses more successful.</p> <p>More on this below, but first, a few important reminders about the impact of page speed on businesses...</p><h2>Slow pages hurt your business</h2> <p>In user survey after user survey over the past decade or so, site speed has emerged as one of the greatest factors that determine a person's satisfaction with a website (second only to security). Because&nbsp;<a href="https://www.speedcurve.com/web-performance-guide/the-psychology-of-web-performance/">our "need for speed" is deeply rooted in our neural wiring</a>, it's unlikely to change, no matter how much we wish it could.</p> <p>In case you have any doubts,&nbsp;<a href="https://wpostats.com/">countless case studies</a>&nbsp;have proven a consistent and demonstrable correlation between page speed and business and user engagement metrics like conversions, bounce rate, and search rank. Just a few examples:</p> <ul> <li><strong>Walmart</strong>&nbsp;found that every 1 second of improvement equaled a&nbsp;<a href="https://wpostats.com/2015/11/04/walmart-revenue.html">2% increase in conversion rate</a>.</li> <li><strong>Vodafone</strong>&nbsp;improved their Largest Contentful Paint (LCP) time by 31%, resulting in an&nbsp;<a href="https://web.dev/case-studies/vodafone">8% increase in sales, a 15% increase in their lead-to-visit rate, and an 11% increase in their cart-to-visit rate</a>.</li> <li><strong>NDTV</strong>, one of India's leading news stations and websites, improved LCP by 55% and saw a&nbsp;<a href="https://web.dev/case-studies/ndtv">50% reduction in bounce rate</a>.</li> <li><strong>ALDO</strong>&nbsp;found that on their single-page app, mobile users who experienced fast rendering times brought 75% more revenue than average, and&nbsp;<a href="https://simplified.dev/performance/impact-of-web-performance">327% more revenue</a>&nbsp;than those experiencing slow rending times. On desktop, users with fast-rendering times brought in 212% more revenue than average and 572% more than slow.</li> </ul> <h2><span style="font-size: 35px;">How much faster than your competitors do you need to be?</span></h2> <p>It's not enough to be fast. You need to be faster than the competition. If you're not, your customers could be quietly drifting away. In a traditional brick-and-mortar scenario, abandoning one store for another takes effort. On the web, it takes a couple of clicks.&nbsp;</p> <p>The margin for speed is tight. Way back in 2012, Harry Shum (then EVP of Technology and Research at Microsoft) <a href="https://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html">said</a>:</p> <blockquote> <p>"Two hundred fifty milliseconds, either slower or faster, is close to the magic number now for competitive advantage on the Web."</p> </blockquote> <p>With many synthetic monitoring tools, you can&nbsp;<a href="https://support.speedcurve.com/docs/competitive-benchmarking">benchmark your site against your competitors</a>. Competitive benchmarking is a great way to see how you stack up &ndash; and how much you need to improve.</p> <p>This is why it's crucial to take advantage of any optimization technique that could help give you a competitive advantage.</p> <p style="text-align: center;"><a href="https://app.speedcurve.com/benchmarks/usa/retail/fast/start-render/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/483/benchmarks.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p style="text-align: center;"><a href="https://app.speedcurve.com/benchmarks/usa/retail/fast/start-render/"><em>US Retail Benchmarks leaderboard</em></a></p> <h2>Background: Looking at 20 leading sites</h2> <p>For this investigation:</p> <ul> <li>I looked at the synthetic test results for twenty randomly selected industry-leading sites, taken from SpeedCurve's <a href="https://app.speedcurve.com/benchmarks/">Page Speed Benchmarks</a> dashboard.</li> <li>I then tallied the pass/fail status for common performance recommendations (AKA performance audits).</li> </ul> <p><strong><a href="https://app.speedcurve.com/benchmarks/">Page Speed Benchmarks</a> is an interactive set of dashboards that anyone can explore and use for their own research.</strong> Every day we run a synthetic test for the home pages of industry-leading websites and rank them based on how fast their pages appear to load from a user&rsquo;s perspective. You can filter the dashboard to rank sites based on common web performance metrics, such as Start Render, Largest Contentful Paint, Cumulative Layout Shift, Time to Interactive, and more.&nbsp;</p> <p><strong>The Benchmarks dashboard also allows you to drill down and get detailed test results for each page</strong>, including waterfall charts, Lighthouse scores, and recommended optimizations/audits. Looking at these test details lets you see how the fastest and slowest pages in the dashboards are built &ndash; what they're doing right, as well as missed opportunities for optimization.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/483/lighthouse-scores-audits.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p style="text-align: center;"><em>Lighthouse scores and performance audits, taken from <a href="https://app.speedcurve.com/benchmark/media-eu/test/240704_4F_12b674ea9f73a94489c82665d1ae5b52/?share=freljsuj6913s9s5an29pktz92alec">this synthetic test result</a></em></p> <p>For the twenty sites I looked at, below are the most common page speed optimizations those sites were not taking advantage of, ranked from least to most implemented.</p> <h2>Serve static assets with an efficient cache policy</h2> <p><strong>Metric(s) affected:</strong> Rendering metrics for repeat views</p> <p>The first time you visit a site, it's likely that your browser won't have any of the resources it needs to load the page already stored in its cache. This is often referred to as a <strong>cold cache</strong>. This state is very typical for sites that don't get a lot of repeat visitors over a short duration.&nbsp;For many other sites, such as your favourite media or shopping sites, repeat views are very common.</p> <p>For sites that receive a lot of repeat visitors, <a href="https://www.speedcurve.com/web-performance-guide/leveraging-browser-caching-for-faster-load-times/">taking advantage of the browser cache</a> is a big performance win. <strong>Yet only 1 out of the 20 pages I looked at had an efficient cache policy.</strong></p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/1-efficient-cache.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:&nbsp;</strong><a href="https://developer.chrome.com/docs/lighthouse/performance/uses-long-cache-ttl/">Setting appropriate HTTP headers for page resources</a> is the best way to make sure you are optimally caching content for your site.&nbsp;</p> <h2>Reduce unused JavaScript</h2> <p><strong>Metric(s) affected:</strong> Largest Contentful Paint</p> <p>There's a shocking number of zombie scripts out there, slowly killing performance. Unused JS can hurt your site in a number of ways, from render-blocking scripts that prevent your page from loading to competing with essential JS for bandwidth, especially on mobile and low-powered devices. <strong>Only 3 out of 20 sites passed this audit.</strong></p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/2-unused-javascript.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong>&nbsp;<a href="https://developer.chrome.com/docs/lighthouse/performance/unused-javascript/">Reduce unused JavaScript</a> and, when possible, defer scripts until they're required.&nbsp;</p> <h2>Page prevented back-forward cache restoration</h2> <p><strong>Metric(s) affected:</strong> Rendering metrics for repeat views</p> <p>Many navigations are performed by going back to a previous page and forward again. Back/forward cache (or bfcache) stores the entire page so that it's available and renders nigh instantaneously. It doesn't require special HTTP headers and is now supported across all major browsers.</p> <p>For sites that have a lot of back/forward navigations, taking advantage of the bfcache remains one of the biggest opportunities to deliver a page load experience that feels seamless. <strong>Yet&nbsp;16 out of 20 sites did not have bfcache restoration enabled</strong>.</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/3-bfcache.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> <a href="https://www.speedcurve.com/web-performance-guide/leveraging-browser-caching-for-faster-load-times/">Leverage the browser cache</a> to reduce the number of HTTP requests.&nbsp;</p> <h2>Image elements do not have explicit 'width' and 'height'</h2> <p><strong>Metric(s) affected:</strong> Cumulative Layout Shift&nbsp;</p> <p>Without height and width attributes, your images fly around the page trying to figure out how to resolve and settle down in each individual user's browser. This can really hurt your <a href="https://www.speedcurve.com/web-performance-guide/understanding-and-improving-cumulative-layout-shift/">Cumulative Layout (CLS)</a> score. CLS is a Core Web Vital, which means it's an important factor in Google's search algorithm. The worse your CLS score, the greater risk of hurting your SEO rank.</p> <p>More to the point, a poor CLS score tells you that your pages feel super janky and unstable. Page jank is an irritant for everyone, but it's a major accessibility problem for people with disabilities that affect fine motor skills.&nbsp;</p> <p>All this goes to say that it's very surprising to see that <strong>14 out of 20 sites failed this audit</strong>.&nbsp;</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/4-image-height-width.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong>&nbsp;<a href="https://web.dev/articles/optimize-cls#images-without-dimensions">Set an explicit width and height</a> on all image and video elements.&nbsp;Alternatively, reserve the required space with CSS <code>aspect-ratio</code> or similar.</p> <h2>Minimize main-thread work</h2> <p><strong>Metric(s) affected:</strong> Largest Contentful Paint, Total Blocking Time (to name just a couple)</p> <p>Geoff Graham provides a good analogy for the browser main thread <a href="https://www.smashingmagazine.com/2023/10/speedcurve-fight-main-thread/">here</a>:</p> <blockquote> <p>I&rsquo;ve heard the main thread described as a highway that gets cars from Point A to Point B; the more cars that are added to the road, the more crowded it gets and the more time it takes for cars to complete their trip. This particular highway has just one lane, and it only goes in one direction. there&rsquo;s only one way to go, and everything that enters it must go through it... Each resource on a page is a contender vying for a spot on the thread and wants to run first. If one contender takes its sweet time doing its job, then the contenders behind it in line just have to wait.</p> </blockquote> <p>When you understand how hard all a page's resources are fighting for the main thread, it's easy to understand why minimizing main-thread work is a crucial page speed optimization strategy. It's not uncommon to see pages where main-thread work could be reduced by 8-10 seconds or more! <strong>Of the 20 sites I looked at, 13 failed this audit.</strong></p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/5-minimize-main-thread.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> <a href="https://developer.chrome.com/docs/lighthouse/performance/mainthread-work-breakdown/">Reduce the time spent parsing, compiling and executing JS.</a> You may find delivering smaller JS payloads helps with this.&nbsp;</p> <h2>Reduce JavaScript execution time</h2> <p><strong>Metric(s) affected:</strong> Interaction to Next Paint, Total Blocking Time</p> <p>JavaScript is, by default, parser blocking. That means that when the browser finds a JavaScript resource, it needs to stop parsing the HTML until it has downloaded, parsed, compiled, and executed that JavaScript. Only after all of that is done can it continue to look through the rest of the HTML and start to request other resources and get on its way to displaying the page.</p> <p>For the 20 sites I looked at, <strong>there was a 50/50 pass/fail rate for this audit</strong>.</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/6-js-execution.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> <a href="https://www.speedcurve.com/web-performance-guide/best-practices-for-optimizing-javascript/">There are several things you can do</a>, including minification and compression, serving JS asynchronously (or deferring it), avoiding layout thrashing, and yielding to the main thread. The most radical solution: wherever possible, don't use JavaScript!&nbsp;</p> <h2>Avoid enormous network payloads (AKA page size)</h2> <p><strong>Metric(s) affected:</strong> Largest Contentful Paint</p> <p>I've stopped being shocked when I see pages that are upwards of 10, 20, and even 30 MB in size. Large network payloads can cost users real money and are highly correlated to slow load times. The main culprits: huge image and video files, along with unoptimized JavaScript.&nbsp;</p> <p>If a page is greater than 5,000 KB in size, then it fails this audit. <strong>Of the 20 sites I looked at, 9 failed &ndash; meaning they were larger than 5,000 KB.</strong></p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/7-network-payload.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> <a href="https://developer.chrome.com/docs/lighthouse/performance/total-byte-weight/">Reduce payload size.</a> For first views, you can optimize resources like images and videos to be as small as possible. For repeat views, leverage the browser cache as recommended earlier in this post.</p> <h2>Serve images in next-gen formats</h2> <p><strong>Metric(s) affected:</strong>&nbsp;Start Render, Largest Contentful Paint</p> <p>Image formats like WebP and AVIF often provide better compression than PNG or JPEG, which means faster downloads and less data consumption.<strong>&nbsp;11 out of 20 sites passed this audit.</strong></p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/8-images-next-gen.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong>&nbsp;<a href="https://www.speedcurve.com/web-performance-guide/best-practices-for-optimizing-images/">Explore alternative image formats.</a> AVIF is supported in Chrome, Firefox, and Opera and offers smaller file sizes compared to other formats with the same quality settings. WebP is supported in the latest versions of Chrome, Firefox, Safari, Edge, and Opera and provides better lossy and lossless compression for images on the web.&nbsp;</p> <h2>Ensure text remains visible during webfont load</h2> <p><strong>Metric(s) affected:</strong>&nbsp;Start Render, Largest Contentful Paint</p> <p>Some web fonts can be large resources, which means they render slowly. Because fonts are often one of the first resources to be called by the browser, a slow font can relay all your downstream metrics. And depending on the browser, the text might be completely hidden until the font loads. The resulting <strong>flash of invisible text</strong> (FOIT) is a UX annoyance.</p> <p>Despite all those very good reasons to optimize font rendering, <strong>7 out of 20 sites failed this audit</strong>.</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/9-text-fonts.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong>&nbsp;<a href="https://developer.chrome.com/docs/lighthouse/performance/font-display/">Leverage the <code>font-display</code> CSS feature</a> to ensure text is visible to users while web fonts are loading.</p> <h2>Reduce the impact of third-party code</h2> <p><strong>Metric(s) affected:</strong> Total Blocking Time, Largest Contentful Paint, Interaction to Next Paint</p> <p>These days, a typical web page can contain dozens of third-party scripts. All that extra code &ndash; which you don't have much control over &ndash; can significantly affect the speed of your pages. A single non-performant blocking script can completely prevent your page from rendering. The good news is that only <strong>4 out of 20 sites failed this audit</strong> (though that number is still too high).</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/10-third-parties.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> While you can't always do much about your third-party vendors, <a href="https://www.speedcurve.com/web-performance-guide/third-party-web-performance/">you still have a number of options available</a>, including limiting the number of redundant third-party providers and loading third-party code after your page has primarily finished loading.</p> <h2>Reduce unused CSS</h2> <p><strong>Metrics affected:</strong> Start Render, Total Blocking Time, Largest Contentful Paint</p> <p>By default, the browser has to download, parse, and process all stylesheets before it can display any content. Like unused JavaScript, unused CSS clutters your pages, creates extra network trips, unnecessarily adds to your total payload, and ultimately slows down user-perceived performance. Decluttering your pages pays off, yet <strong>4 out of 20 sites failed this audit</strong>.</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/11-reduce-css.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> Reduce unused rules from stylesheets and defer CSS not used for above-the-fold content. <a href="https://www.speedcurve.com/web-performance-guide/using-critical-css-for-faster-rendering/">Use critical CSS for faster rendering.</a>&nbsp;</p> <h2>Avoid 'document.write()'</h2> <p><strong>Metric(s) affected:</strong> Start Render and other downstream metrics</p> <p>For users on slow connections, external scripts dynamically injected via document.write() can delay page load by <em>tens</em> of seconds. That's a lot!</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/12-document-write.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> <a href="https://developer.chrome.com/blog/removing-document-write">Remove all uses of&nbsp;<code>document.write()</code>&nbsp;from your code.</a>&nbsp;If it's being used to inject third-party scripts, use asynchronous loading instead.</p> <h2>Eliminate render-blocking resources</h2> <p><strong>Metric(s) affected:</strong> Start Render, Largest Contentful Paint, and other downstream metrics</p> <p>A blocking resource is any resource that blocks the first paint of your page. Anything that has the potential to block your page completely is concerning, right? <strong>Yet&nbsp;3 out of 20 sites failed this audit</strong>.</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/13-eliminate-render-blocking-resources.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> <a href="https://developer.chrome.com/docs/lighthouse/performance/render-blocking-resources/">Eliminate render-blocking scripts.</a> Assess your blocking resources to make sure they're actually critical and then serve the legitimately critical scripts inline. Serve non-critical code asynchronously or defer it.&nbsp;Remove unused code completely.&nbsp;&nbsp;</p> <h2>Use HTTP/2</h2> <p>HTTP/2 offers many benefits over HTTP/1.1, including binary headers and multiplexing. What this means: your page's resources are leaner and faster.&nbsp;<strong>Most sites I looked at are already leveraging HTTP/2, but there were still a couple of holdouts.</strong></p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/15-http2.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong>&nbsp;<a href="https://dassur.ma/things/h2setup/">Learn how to set up HTTP/2.</a>&nbsp;</p> <h2>Do NOT lazy load the LCP image</h2> <p><strong>Metric(s) affected:</strong> Largest Contentful Paint</p> <p>Yikes! I don't see this issue often, but I'm still surprised every time I do. Images that are lazy loaded render later in the page lifecyle. Lazy loading is a great page speed optimization technique for non-critical images, such as those that are lower down on the page. But it's a huge problem if you're lazy loading your Largest Contentful Paint (LCP) image. This can add many seconds to your LCP time. (I've seen LCP times of up to 20 seconds &ndash; caused by lazy loading!)</p> <p>LCP is a Core Web Vital, which means it's a user experience signal in Google's search algorithm. The worse your LCP time, the greater risk of hurting your SEO rank. Just as important, slow images hurt the user experience, and ultimately conversions and bounce rate for your site. <strong>Seeing that 2 out of 20 sites failed this audit broke me a little.</strong> I hope this post helps you avoid this mistake!</p> <p><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/483/14-lazy-load-lcp.png?auto=format,compress&amp;fit=max&amp;w=2000" /></p> <p><strong>Fix:</strong> The LCP image should&nbsp;<strong>never</strong>&nbsp;be lazy loaded. In fact, the LCP image should be prioritized to render as early in the page lifecycle as possible. If the LCP element is dynamically added to the page, you should preload the image. <a href="https://www.speedcurve.com/web-performance-guide/understanding-and-improving-largest-contentful-paint/">Get more LCP optimization tips.</a></p> <p>You should also <a href="https://www.speedcurve.com/web-performance-guide/complete-guide-performance-budgets/">create a performance budget</a> for LCP, so you get alerted right away if it suddenly degrades.&nbsp;</p> <h2>Why are so many recommendations neglected?</h2> <p>There are a few reasons I can think of off the top of my head:</p> <h3>Some optimizations may not affect the critical rendering path</h3> <p>The critical rendering path is the set of steps a browser takes to convert all a page's resources &ndash; from images and HTML to CSS and JavaScript &ndash; into a complete, functional web page. Optimizing the critical rendering path means taking a good look at the order in which the resources on your pages render, and then making sure that each resource in the rendering path is as performant as possible. It sounds simple &ndash; and conceptually it is &ndash; yet it can be tricky to achieve (as <a href="https://www.speedcurve.com/blog/web-performance-audit-lego/">this performance audit of LEGO.com</a> reveals).</p> <p>Depending on how a page is built, the critical rendering path might be well optimized, even disregarding some of the optimizations listed above. For example, a page might contain render-blocking first- and third-party JavaScript &ndash; such as ads and beacons &ndash; but if these scripts are called later in the pages rendering life cycle, then they probably won't affect the user experience.</p> <h3>Some optimizations may be harder (or impossible) to implement</h3> <p>If your page has a massive payload, there might not be much you can do about it. News sites, for example, typically have huge pages because they're required to contain a ton of ads and widgets in addition to their huge content payload of images and videos.</p> <p>And speaking of images, serving them in next-gen formats (e.g., AVIF instead of JPEG) can be challenging if you have a large number of content creators uploading images to your CMS.</p> <h3>People just don't know</h3> <p>Some practices &ndash; such as leveraging the bfcache &ndash; are so new that they might not be on people's radar. Others &ndash; such as knowing not to lazy load the LCP image &ndash; are probably because people are too broadly applying a generally good best practice like lazy loading.&nbsp;</p> <h2>But still...</h2> <p>Many of the sites I looked at are pretty fast, despite not following web performance optimization best practices religiously. But that doesn't mean ignoring best practices is... well, good practice.&nbsp;</p> <ul> <li><strong>Page size and complexity affects users at the 95th percentile</strong> &ndash; including mobile users and people using slower networks. Ignoring 5% (or more) of your users is a bad idea.</li> <li><strong>Bad practices pile up until there's a tipping point.</strong> After that, all it takes is one unoptimized image or non-performant script to seriously hurt your page.</li> <li><strong>Zombie third parties can introduce security issues.</strong> You should always understand why a third-party script is on your pages and eliminate the ones that don't belong there.</li> <li><strong>Page jank is a thing.</strong> It's not enough to have a fast Start Render or Largest Contentful Paint time. Your critical rendering path might be short and sweet, and your pages might start to render reasonably quickly, but what about the user experience during the entire rendering lifecycle of the page? Everyone hates jank, and too much of it hurts your UX and your business.</li> </ul> <h2>How to prioritize page speed optimizations</h2> <h3>1. Consider how many pages on your site are affected by each optimization recommendation</h3> <p>Run some <a href="https://www.speedcurve.com/web-performance-guide/synthetic-vs-real-user-monitoring/">synthetic</a> tests on your key pages and see which optimizations are recommended. If you're a SpeedCurve user, you can <a href="https://support.speedcurve.com/docs/aggregated-lighthouse-results">use your Improve dashboard to see how many pages on your site are affected by each audit</a>. If a large number of your pages would benefit from an optimization, then you may want to take the approach of tackling improvements one audit at a time.</p> <h3>2. Validate that an optimization will help your page and UX in a measurable way</h3> <p>You don't want to spend a lot of developer time implementing an optimization that won't ultimately benefit your users. Understanding the critical rendering path for your pages is the best way to know if optimizing a resource will make a difference in how the page feels from an end-user perspective.</p> <h3>3. Grab the easy fixes first</h3> <p>Sometimes it's easier to get yourself &ndash; and other folks &ndash; in your organization excited about performance fixes is to score some easy wins early on. Later, you can work your way up to the more time-consuming ones.</p> <p>Some easy(ish) recommendations:&nbsp;</p> <ul> <li>Tweaking your cache policy</li> <li>Enabling bfcache</li> <li>Setting height and width attributes on images</li> <li>Optimizing image and video sizes</li> <li>Serving third parties asynchronously or deferring them</li> </ul> <h2>Start somewhere and keep moving</h2> <p>If you've tested your pages and get a long list of recommended fixes, it can be a bit overwhelming &ndash; and more than a bit demoralizing. Start with the small, easy wins first. Speeding up your pages doesn't (usually) happen overnight. The important thing is to show up, do the work, and always be monitoring. Remember: you can't fix what you don't measure!</p> <p><a href="https://www.speedcurve.com/signup/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/483/customer-logos-free-trial-banner.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> Tue, 09 Jul 2024 00:00:00 +1200 Performance Hero: Michelle Vu https://www.speedcurve.com/blog/performance-hero-michelle-vu <p><span class="large-para">Michelle Vu is one of the most knowledgeable, helpful, kind people you could ever hope to meet. As a founding member of Pinterest's performance team, she has created an incredibly strong culture of performance throughout Pinterest. She's also pioneered important custom metrics and practices, like Pinner Wait Time and performance budgets. We are super excited to share that Michelle is this month's Performance Hero!</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/512/michelle-vu.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <div>Michelle is a web performance industry veteran who has spent the last seven years making Pinterest fast and reliable. She was a founding member of Pinterest's performance team, establishing foundations of their program by setting up its synthetic and real user metrics, proactive alerts, and performance analysis tools, while fostering a culture of performance across teams.</div> <div>&nbsp;</div><div>Michelle and her team at Pinterest pioneered the use of custom metrics when they introduced Pinner Wait Time (PWT). This metric measured the slowest loading time for content they considered critical for the user experience on a page.</div> <div>&nbsp;</div> <div>As the web performance tech lead at Pinterest, Michelle focuses on large optimizations to the Core Web Vital and Pinner Wait Time metrics for key features. She also aids in performance issues from platform migrations and product feature launches. When she's not working on optimizations, Michelle tackles performance regressions and develops tooling to analyze performance and prevent regressions.&nbsp;</div> <div>&nbsp;</div> <div>Michelle is a participant in the <a href="https://www.w3.org/webperf/">W3C Web Performance Working Group</a> as an Invited Expert. She's given talks about performance at Fastly's <a href="https://vimeo.com/267643422">Altitude NYC</a>, <a href="https://www.youtube.com/watch?v=FBeR6QvroEQ">performance.now()</a>, <a href="https://timkadlec.com/remembers/2018-03-27-notes-on-making-pinterest-fast-at-perfmatters/">PerfMatters</a>, and numerous web performance meetups.</div> <div>&nbsp;</div> <div>Most recently, Michelle presented on tooling to catch and prevent regressions due to increases in JavaScript bundle sizes. She's also in the midst of releasing a three-part series of articles &ndash; <a href="https://medium.com/pinterest-engineering/web-performance-regression-detection-part-1-of-3-86dcc6d5fce9">Web Performance Regression Detection</a>&nbsp;&ndash; on the Pinterest&nbsp;Engineering Blog.&nbsp;</div> <div>&nbsp;</div> <div><img class="blog-img" src="https://blog-img.speedcurve.com/img/512/perfmatters.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Michelle speaking at the Perfmatters conference in 2018" /></div> <div>&nbsp;</div> <div style="text-align: center;"><sup><em>Loved seeing Michelle use SpeedCurve visuals on stage to share how they help make Pinterest fast!</em></sup></div> <div>&nbsp;</div> <div><span style="color: #1f1f1f;">Here are a few ways you can find Michelle and learn more about the great work she does in our community:</span></div> <div> <ul> <li><a href="https://medium.com/@Pinterest_Engineering">Pinterest Engineering Blog</a></li> <li><a href="https://www.linkedin.com/in/michellethivu/">LinkedIn</a></li> <li><a href="https://x.com/micvu">Twitter</a></li> </ul> <p>Please join us in celebrating Michelle Vu, a true Performance Hero!</p> <p><em>Do you have someone you'd like to recognize as a Performance Hero?&nbsp;<a href="mailto:support@speedcurve.com">Let us know!</a></em></p> </div> Wed, 26 Jun 2024 00:00:00 +1200 New! Web Performance Guide https://www.speedcurve.com/blog/new-web-performance-guide <p><span style="font-size: 22px;">Our customers often tell us how much they appreciate the user-friendliness of the articles we create for them, so we recently decided to make them available to everyone (not just SpeedCurve users). Introducing the <a href="https://www.speedcurve.com/web-performance-guide/">Web Performance Guide</a>!</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/513/herman-bench-social.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>The <a href="https://www.speedcurve.com/web-performance-guide/" target="_blank" rel="noopener">Web Performance Guide</a> is &ndash; as its name suggests &ndash; a collection of articles we've been writing over the years to answer the most common questions we field about performance topics like site speed, why it matters, how it's measured, website monitoring tools, metrics, analytics,&nbsp;and optimization techniques.&nbsp;</p> <p>You'll find the articles grouped into these topics...</p><p><span style="font-size: 35px; color: #000000;">Business success</span></p> <p>Making your pages faster isn't just for the web performance geeks in your organization. Site speed affects every business metric you care about &ndash; from bounce rate to <a href="https://www.speedcurve.com/web-performance-guide/web-performance-for-retailers/">conversions</a> to <a href="https://www.speedcurve.com/web-performance-guide/seo-web-performance/">search rank</a>. This section gives you the data, tools, and tips to make everyone in your company care about&nbsp;<a href="/web-performance-guide/the-psychology-of-web-performance/">how page speed affects your users</a>&nbsp;and&nbsp;<a href="/web-performance-guide/performance-culture-best-practices/">build a healthy culture of web performance.</a></p> <h2>Core Web Vitals</h2> <p>There are a lot of metrics you need to track, and&nbsp;<a href="/web-performance-guide/get-started-with-core-web-vitals/">Core Web Vitals</a>&nbsp;are among them. These three metrics &ndash;&nbsp;<a href="/web-performance-guide/understanding-and-improving-largest-contentful-paint/">Largest Contentful Paint,</a>&nbsp;<a href="/web-performance-guide/understanding-and-improving-cumulative-layout-shift/">Cumulative Layout Shift,</a>&nbsp;and&nbsp;<a href="/web-performance-guide/understanding-and-improving-interaction-to-next-paint/">Interaction to Next Paint</a>&nbsp;&ndash; are important ingredients in Google's search ranking algorithm. We cover what they measure, how to track them over time (and get alerts when they degrade), and how to optimize your pages to improve them.</p> <h2>Optimization techniques</h2> <p><img class="blog-img-sm" style="float: right; margin: 20px;" src="https://blog-img.speedcurve.com/img/510/sad-mobile.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Website speed testing is just the first step toward optimizing your pages to make them faster &ndash; and make your users happier. This section covers best practices for creating&nbsp;<a href="/web-performance-guide/complete-guide-performance-budgets/">performance budgets</a>&nbsp;to fight regressions, as well as techniques for optimizing&nbsp;<a href="/web-performance-guide/best-practices-for-optimizing-images/">images,</a>&nbsp;<a href="/web-performance-guide/best-practices-for-optimizing-javascript/">JavaScript,</a>&nbsp;<a href="/web-performance-guide/using-critical-css-for-faster-rendering/">CSS,</a>&nbsp;<a href="/web-performance-guide/optimizing-single-page-applications-spas/">SPAs,</a>&nbsp;<a href="/web-performance-guide/third-party-web-performance/">third-party scripts</a>, and more!</p> <h2>Metrics and charts</h2> <p>There's a lot of terminology and TLAs (three-letter acronyms) in the web performance space. No fear! We're here to explain everything in&nbsp;<a href="/web-performance-guide/how-to-trust-your-metrics/">plain language</a>&nbsp;so you can understand what you're seeing in your site speed testing tools. We'll help you understand the difference between <a href="https://www.speedcurve.com/web-performance-guide/synthetic-vs-real-user-monitoring/">synthetic and real user monitoring</a> tools. We also cover topics like <a href="https://www.speedcurve.com/web-performance-guide/averages-medians-percentiles/">understanding averages, medians and percentiles</a> and how to interpret charts like <a href="https://www.speedcurve.com/web-performance-guide/how-to-read-a-rum-histogram/">histograms</a> and waterfalls.</p> <h2>Everything in the Web Performance Guide was written by actual humans!</h2> <p>Meet our&nbsp;<a href="https://www.speedcurve.com/about/">amazing team</a>&nbsp;of web performance experts and authors:</p> <ul> <li>Cliff Crocker</li> <li>Andy Davies</li> <li>Tammy Everts</li> <li>Tim Kadlec</li> <li>Steve Souders</li> <li>Joseph Wynn</li> <li>Mark Zeman</li> </ul> <p>Not only do they deliver&nbsp;<a href="https://www.speedcurve.com/features/consulting/">world-class consulting</a>&nbsp;and hands-on care to our&nbsp;<a href="https://www.speedcurve.com/customers/">wonderful customers</a>, they're pretty great writers, too!</p> <h2>Questions? Suggestions?</h2> <p>We'd love to hear from you! Drop us a note at support@speedcurve.com.</p> <p><a href="https://www.speedcurve.com/signup/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/513/customer-logos-free-trial-banner.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> Tue, 25 Jun 2024 00:00:00 +1200 Performance Hero: Estela Franco https://www.speedcurve.com/blog/web-performance-hero-estela-franco <p><span class="large-para">Continuing our series of Performance Heroes, this month we celebrate&nbsp;Estela Franco! Estela is a passionate web performance and technical SEO specialist with more than ten years of contributing to our community. She loves to talk and share about web performance optimization, technical SEO, JavaScript, and Jamstack whenever she can.</span></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/486/perf-hero-estela-franco-main1.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p><p>By day, you can find Estela working as a web performance specialist for Schneider Electric in Barcelona, Spain. Outside of work, her contributions as a Google Developer Expert in Web Technologies, a Storyblok Ambassador, co-organizer of the <a href="https://www.meetup.com/barcelona-web-performance/">Barcelona Web Performance Meetup</a>, and co-founder of the <a href="https://www.mujeresenseo.es/">Mujeres en SEO</a> community have made a huge impact on developers and web performance aficionados around the globe.</p> <p>Estela has the winning combination of a web development background coupled with a background in business administration. She started on the marketing side, discovering the fundamentals of SEO and digging deeper into the code to learn how websites work and how to optimize for both robots and humans. This led her to specialize in technical SEO. With the announcement of the Core Web Vitals back in 2020, Estela made the decision to focus on web performance.</p> <p>In&nbsp;<a href="https://youtu.be/ZYX6jXGdlyg">her talk at Performance.now</a>&nbsp;in November 2023, Estela helped demystify optimizing for Largest Contentful Paint (LCP) with a focus on LCP subparts. Her data-backed approach was refreshing, practical, and very useful. (We certainly took note!)</p> <p>Here are a few ways you can find Estela and learn more about the great work she does in our community:</p> <ul> <li><a href="https://estelafranco.com">estelafranco.com</a></li> <li><a href="https://www.linkedin.com/in/estelafranco/">LinkedIn</a></li> <li><a href="https://toot.cafe/@guaca">Mastodon</a></li> <li><a href="https://twitter.com/guaca">Twitter</a></li> </ul> <p><span style="color: #1f1f1f;">Please join us in celebrating Estela Franco, a true Performance Hero!</span></p> <p><em>Do you have someone you'd like to recognize as a Performance Hero?&nbsp;<a href="mailto:support@speedcurve.com">Let us know!</a></em></p> Tue, 21 May 2024 00:00:00 +1200