Images should be sized appropriately. For example, if an image is displayed at only 600px wide on your site, but you uploaded a 2400px image your serving an image that’s larger than needed and it’s costing you bandwidth usage. You can resize images using tools like Photoshop, Figma, etc. If a customer doesn’t have access to those kinds of tools there are sites like https://bulkresizephotos.com/en
Customers should also be using tools like TinyPNG, ImageMagick, etc to reduce file sizes before they upload them to Webflow. Webflow does compress jpg images on upload, but not pngs. We also create variants for each breakpoint to help with serving images that are the right-size. However, customers shouldn't wholly rely on Webflow's compression and instead compress images before upload.
Additionally, customers can use a more modern image format like webp. The webp format can drastically reduce image sizes. Webflow does have built in tooling to compress images and convert them to webp if the image is added to the asset panel, but there aren’t any built-in tools to convert CMS images. To convert images locally, they can use this as a guide:
https://web.dev/codelab-serve-images-webp/
When using webp customers need to be mindful of a couple of things:
In Webflow, you can minify the CSS and JS code that’s bundled with your Webflow site, you can learn more here:
https://university.webflow.com/lesson/advanced-publishing-options#minify-html-css-js
Additionally, if you’re using custom code and not serving it from a third-party, practice code-splitting. Don’t place the JavaScript or CSS in the global custom code unless it’s truly being used everywhere. Instead, only include it in the page settings/embeds on the page(s) where it’s being used.
Only load the images, videos, and assets that are needed for the initial view of the page. Let everything else load on scroll or on interaction. Webflow supports lazy loading images natively. You can learn more about this here:
https://university.webflow.com/lesson/image#how-to-edit-image-settings
All images above the fold or in the initial view should load eager or auto and everything out of view/below the fold should be lazy loaded.
Webflow doesn’t support lazy loading videos natively and this is something the customer will have to implement using custom code. Using the native video element inside of Webflow will cause bandwidth issues since the video will load when the page loads.
This is the same with background video elements. Oftentimes, customers love to have a background videos or even regular videos above the fold. Customers need to weigh the trade-offs – if they want the design they need to be willing to eat the costs from a bandwidth perspective.
Technical Architects have built some resources and examples that could be helpful here:
We’ll continue to advocate to product for more built-in performance gains around these kinds of elements.
Customers can use facades/lazy-loading in place of third-party tools. Think of other embeds like podcast players, chat bot tools, etc.
For example, if I have a chatbot on page, instead of loading it I can add an image to the page that represents the bot and then init the chat window/bot when a customer clicks the image vs loading on page load.
We would also encourage customers to defer/async third-party scripts or encourage them to not run these on page-load.
Technically, Vimeo and YouTube videos and other third-party tools shouldn’t count against Webflow bandwidth, only the background video element should count against it. But raising the flag on these elements can be helpful in terms of performance and third-party tools can impact CDN usage at times
Customers often end up with sites that have a LOT of elements on the DOM. The bigger the page, the more weight it adds to your CDN usage. Customers should really optimize their page designs and ensure that they aren’t adding a lot of content, elements, visualizations, etc that don’t bring value to the page.
Google has recommendations around DOM size as this is an item in their Lighthouse API. Lighthouse flags pages with DOM trees that:
The more customers can keep this size down and avoid hiding and showing elements across breakpoints (for example, desktop nav and a mobile nav) the better off they’ll be.