Optimizing your CMS Hub site for performance
- Professional or Enterprise
- Professional or Enterprise
Great user experience is a factor of content quality, speed, security and accessibility. Optimizing for these generally also improves Search Engine Optimization (SEO).
Better performance is all about providing a better experience for end users. Achieving better performance is all about solving for your individual site's bottlenecks.
It's easier to build from a great foundation that was built with performance in mind, than trying to fix performance issues later. A metaphor, building a fast car from the ground up, is easier than buying a slow car and trying to make it fast.
When building from the boilerplate you know that without any code you've added, it achieves those scores. That means you can focus your attention on the code you added on top of the boilerplate.
Most web performance optimization techniques and best practices are not HubSpot specific. This is because most website performance bottlenecks are not HubSpot specific.
Most performance issues fall into a couple of categories, rendering and loading.
- Loading performance is the efficiency of transferring all of the files needed for your web page to the user's browser.
- Rendering performance is the efficiency for the browser to take everything it downloaded and display the end result to the user.
Images are prevalent on almost every page on the web. Images are usually the largest files on a page. The more images, and the larger the images, the longer your page will take to load. Animated images such as gifs and animated webp, also take up more space than non animated images of the same size. Some image formats also are more performant than others, and better for certain scenarios.
- The most important thing you can do is optimize your images for the web. Image optimization is very much a shared responsibility among both content creators and developers.
- Use fewer images per page.
- Use the right image format for the use-case.
- Use Scalable Vector Graphics (SVGs) where possible. SVGs can scale in size infinitely without losing quality. Inlining your SVGs makes sense when you are making animations. In static graphics creating an SVG sprite sheet or simply treating it as a normal img element, or background image is typically better for performance.
- Intelligently lazy load images.
- Make sure
imgelements contain height and width HTML attributes. This makes it easier on browsers during render time and also makes it so HubSpot can intelligently add a
srcsetfor you. Not only does HubSpot help optimize, but web browsers can intelligently optimize for cumulative layout shift when you provide width and height.
- Use the CSS aspect-ratio property to reserve space when img dimensions may change.
resize_image_urlto force images to be resized to a certain resolution.
- For background images, use media queries in combination with
resize_image_urlto deliver images at sizes that make sense for the device.
- For large hero images - you can preload them by using
<link rel="preload" as="image" href="http://example.com/img_url.jpg">within a
require_headtag. Use this technique sparingly, overusing it can actually hurt performance.
Video backgrounds and auto-playing videos can certainly set a website apart. Unfortunately they come at a cost. Video backgrounds are often used for website headers. When a video auto-plays, it means the browser needs to start loading the video right away. This can be especially problematic for users on slower connections or using cellphone data.
When including CSS in a custom module, HubSpot intelligently loads module.css only when a module is used on a page, and only loads it once regardless of how many instances of the module are on the page. By default, module.css does not load asynchronously, but you can change this by including css_render_options in the module’s meta.json file.
There are lots of tools out there that can be used to both improve performance and test it. It's helpful to both understand these tools and use them. This list is not exhaustive by any means, and is sourced from our community of developers.
Testing performance and optimizing for it should be apart of any website build out. There are a plethora of tools available for testing a website's speed. It's important to understand these tools and how they work, so you can make educated decisions around performance improvements.
Some tools strictly measure, some tools grade. It's important to understand how this actually works.
Tools that measure, will usually test the loading time, script execution time, time until first contentful paint, network times for assets downloading, etc. These tools will generally provide results that state specific times for each of these metrics. If you retest, generally the measurements will shift slightly because not every page load is exactly the same.
Tools that grade, do more than just measure speeds, they tell you if your doing good or bad often using a percent or letter grade. These grades are intended to be used as a tool to motivate developers and marketers to improve. There are so many different metrics and aspects to performance that need to be taken into account. You can't just base your overall performance off of one metric, on top of that some metrics have different levels of affect on perceived performance. So these tools weight the metrics differently to calculate the overall performance. There is no industry wide standard for how to weight the metrics. Over time this weighting can change, as has occurred with Google Page Speed. There is also no industry wide accepted for what is considered the minimum or maximum "good" value for individual metrics. Some tools base this off of a percentile of websites that have been tested. Meaning your scores are being compared to other sites that were tested. Resulting in the "good/excellent" speed range becoming harder and harder to attain over time. Some tools instead use user experience, visitor retention, and ROI based research to determine what the threshold for a good score should be. Also take into account that not all tools take into account subsequent page load performance. For example the HubSpot module system separates css and JS for individual modules, and only loads those assets when the module is actually placed on the page. This can result in several smaller css files, which could get flagged by Google Page Speed Insights. The reality though is your next page load, you won't need to download any of the css or js for any modules that repeat on the next page - they will be cached. Instead, you will only need to download the files for modules you haven't seen before, and that would be kilobytes, instead of a monolithic file.
When it comes to graded tools you should use multiple tools and strive for the best score you can in each. Understand though they will weight things differently. Efforts that may improve a score in one tool may not improve it in others.
Popular performance testing tools:
- Website Grader
- Google Page Speed Insightsand other Google performance tools.
Thank you for your feedback, it means a lot to us.