The Ultimate Guide To Framer Speed Optimisation
Introduction
Nobody likes a slow website. Slow load times lead to reduced engagement, higher bounce rates, and lower search engine rankings. In essence, a slow website means less business.
And that’s the reason I put together this guide. By following all the tips and actionable advice I outlined in this guide, you’ll be able to improve your Framer website’s load times, reduce bounce rates, and improve the overall user experience.
In other words, your website will make you more money from the same amount of traffic!
So, whether you’re a website owner or a Framer developer, this is a must-read for taking your site performance to the next level.
More specifically, I’ll go over:
How to measure your website performance
Understanding Core Web Vitals (made simple)
Framer’s built-in optimisation features
7 (native) ways to speed up your Framer website
FAQs
Ready to improve your site’s performance? Let’s get started!
How to measure your website performance
The internet is full of website performance testing tools you can use. However, nothing is more accurate than what real people are experiencing on your website.
How do you get those data? Simple, by looking at your web core vitals.
If you’re unfamiliar with the term, your core web vitals are a set of metrics that measure real-world user experience for loading speed, interactivity, and visual stability of the page.
Google also uses core web vitals as a ranking factor as they are tightly correlated with the overall user experience of your website.
There are two main ways you can use to view your core web vitals:
Using Google Search Console
→ If you’re the website owner, you can use GSC to look directly at your core web vitals (alongside other important metrics).
Using PageSpeed Insights
→ Even if you’re not the owner, you can check core web vitals by running a simple PageSpeed Insights analysis.
For instance, here’s a screenshot of my core web vitals measured using PageSpeed Insights:
Understanding Core Web Vitals (Made Simple)
As you can see from the image above, there are six metrics that currently make up the web vitals report. Let’s quickly go over each one of them:
Largest Contentful Paint (LCP)
→ LCP measures the time it takes for a page’s main content to load. Ideally, this metric should be below 2.5 seconds.
First Input Delay (FID)
→ The time it takes for a page to become interactive. An ideal measurement is less than or equal to 100 ms. (Google has announced that INP will replace this metric in March 2024).
Cumulative Layout Shift (CLS)
→ This metric measures visual stability. Ideally, it should be less than 0.1s
Interaction to Next Paint (INP)
→ Measures a page’s overall responsiveness to user interaction (the time it takes for the page to respond to a user clicking something). An INP below 0.2 seconds is considered very good.
First Contentful Paint (FCP)
→ FCP measures the time it takes for a user to see any visible content on a web page after they navigate to it. Ideally, FCP shouldn’t take longer than 1.8 seconds.
Time to First Byte (TTFB)
→ TTFB measures the time it takes for a browser to receive the first byte of content from a server after making a request. A good TTFB should be under 0.8 seconds.
Of the six web vitals I’ve listed above, only the first four are part of the “core web vitals”. However, all of them are important for a good user experience and are also tightly interrelated.
For example, the Largest Contentful Paint is highly dependent on First Contentful Paint (FCP) and Time to First Byte (TTFB).
That’s why monitoring and improving all of these metrics is critical to providing the best user experience possible.
A Couple Of Notes About Core Web Vitals
Before we start, there are two important things you need to know about core web vitals:
Core Web Vitals are different from mobile to desktop.
Core Web Vitals are measured in groups of URLs.
Let’s start with the first one: Just because you pass the core web vitals for desktop devices doesn’t necessarily mean you’ll pass those for mobile devices. Always make sure your website loads fast regardless of the device it’s viewed on.
The second point is a bit more technical, but I’ll try to make it as easy as possible. Your core web vitals are measured for groups of URLs, not single ones.
These groups are created when URLs within your domain have similar core web vitals.
For example, my “normal” pages are measured in a different group than my blog pages because they tend to be faster. Why? Because they have much less content and fewer images to load.
Despite how URLs are organised, it’s essential to make sure that every group performs well.
Now that we understand the basics, let’s look at what Framer does for us.
Framer’s Built-in Optimisation Features
Framer was built using different technologies than most other website builders. Framer sites are single-page React apps, meaning the navigation is handled client-side.
In other words, when you navigate through a website, the browser only requests the server for static assets (think of images, videos, SVGs…), while the main HTML is hydrated using JavaScript.
What does this mean for load performances? It implies that Framer websites tend to be slower when they first load (LCP & FCP), but then they’re lightning-fast when it comes to interactivity and visual stability.
In general, most Framer websites should focus more on loading speed metrics (LCP, FCP, and TTFB) rather than the metrics that measure interactivity (FID and INP) and visual stability (CLS)
Enough theory. Let’s now look at what you can do right now to make your website faster.
7 (Native) Ways To Speed Up Your Framer Website
Tip 1: Compress, Convert, And Resize Your Images
Impact: High 🚀🚀🚀
Effort: Low 🙂 🙂🙂
Framer offers built-in optimisation features for your images. However, from my personal experience, I can GUARANTEE you that optimising your images before uploading them is still a fantastic idea.
Here’s a real-world example to prove my point:
In my free blog template, I didn’t spend too much time optimising the images because they just function as placeholders.
Still, they have been optimised and converted to WebP by Framer to make the website faster.
However, here’s a report for that page generated by TinyPNG (I’m not an affiliate):
→ Original image size = 247.3 KB
→ Optimised image size = 106.0 KB
As you can see, I can save 57% of the bandwidth by compressing and converting the images before uploading them to Framer.
Another trick you can implement to save bandwidth is to resize your images so they are not larger than needed.
For example, all the images used throughout this article (and every other article on my blog, for that matter) have a width of 2500px.
However, there’s no need to serve images that are that big on a mobile device. In fact, I always resize my mobile images to 810px using Photoshop.
Here’s how much bandwidth I manage to save using this technique (using this article as an example):
Compressed Images For Desktop → 1.4MB (total)
Compressed Images For Mobile → 250KB (total)
That’s an 82% save in bandwidth!
Actionable step:
So, here’s a step-by-step process you can use on all your images to save 80%+ of your bandwidth.
Determine display size:
→ First, figure out the average size at which the image will be displayed. You can do this directly in Framer by temporarily setting the width and height to be “fixed”.
Resize:
→ Once you know the display size, use a photo-editing software to resize the image to match the width/height discovered in the previous step.
Compression & convert:
→ Take the resized image and use an online tool like TinyPNG to compress and convert it to WebP format.
Upload to Framer
→ Upload the compressed image to Framer. Repeat this process for all the other images.
Pro Tip: If there’s a significant difference in image size between desktop and mobile breakpoints (as in my blog example), consider using two versions of the same image, sized differently for each breakpoint.
Tip 2: Embed Videos Instead Of Uploading Them
Impact: High 🚀🚀🚀
Effort: Medium 🙂 🙂
Videos are intrinsically WAY heavier than images. And unfortunately, they don’t get optimised in any way by Framer (except for some lazy loading).
There are two main solutions for this:
Embed the video using YouTube or Vimeo (best)
Compress the video yourself
Both YouTube and Vimeo have sophisticated infrastructures that allow them to serve videos in the most efficient way possible.
Alternatively, you can optimise your videos with a free tool like veed.io.
Actionable step
To save bandwidth for your videos, just upload them to YouTube or Vimeo. Then, use Framer’s built-in components to easily embed these videos on your pages.
Tip 3: Reduce The DOM Size
Impact: Medium 🚀🚀
Effort: High 🙂
DOM, or Document Object Model, essentially refers to the number of HTML tags on your page.
If you see an “Avoid an excessive DOM size” warning in Lighthouse, it might be worth considering doing some work on your site’s structure.
Lighthouse throws this warning in three cases:
Your page has a total of more than 1,500 nodes.
Your page has a maximum node depth greater than 32 nodes.
A parent node has more than 60 child nodes.
A large DOM tree can significantly slow down your website, so it’s important that you tackle this issue as soon as possible.
While I could write an entire article on this, here’s some simple guidelines you can follow:
Actionable step:
The steps you need to take depend on what’s the cause of the problem:
Too Many Nodes (Problem 1):
→ If your page has too many nodes (problem 1), split it up into multiple pages. For instance, if your “about us” page is too long, consider dividing it into the following pages:
About the company
Our team
Our vision
Bad Implementation (Problems 2 and 3):
→ The other two problems are likely caused by a bad website implementation. You should be able to spot them by looking at the left sidebar in your Framer project and searching for:
A series of elements that go too deep (a frame inside a frame inside a frame inside a frame…)
An element with too many sons (maybe a table with 60+ children)
Tip 4: Beware Of Carousels, Slideshows, and Tickers
Impact: High 🚀🚀🚀
Effort: Low 🙂 🙂🙂
Carousels, slideshows, and tickers are all elements that can have a HUGE impact on your site speed.
Think about it. You’re loading a bunch of images that don’t even get displayed! They’re hidden in the background, waiting for the user to decide to view them.
If you want one, you can manage to fit a carousel into your page if it doesn’t have too many elements and if the images are properly optimised.
However, if your primary goal is performance, I’d seriously consider removing them entirely.
Actionable step:
To solve the carousels/slideshows/tickers problem, consider:
Deleting them altogether.
Reducing the number of images displayed (obviously, ensure you follow the best practices outlined above for the images).
Similarly to the first tip, consider using distinct carousels/slideshows/tickers and different images based on the breakpoint.
Tip 5: Reduce Third-Party Scripts
Impact: Medium 🚀🚀
Effort: Medium 🙂🙂
I don’t want to scare you. If you have one or two third-party scripts running on your website (e.g., Google Analytics and Meta Pixel), that’s probably not where you should focus your efforts.
However, if you have a ton of third-party scripts or they’re particularly heavy, that can significantly impact performances.
While the best-case scenario would be to remove them, I understand they might be necessary for you. So here are a couple of more advanced techniques you can try:
Technique 1: Not all scripts need to run on all pages
If you’re only using a script on one page, there’s no need to make it load on the others.
Besides analytics and a couple of other exceptions, make sure you add the script only where it’s actually used.
Technique 2: Use Async or Defer Attributes
Use the async and defer attributes to control the loading order of third-party scripts.
Async tells the browser to load the script as soon as possible but allows other scripts and content to continue loading before it executes.
Defer, on the other hand, tells the browser to load the script in the background until all other scripts have finished loading, ensuring that the main content is rendered first.
Technique 3: Consider embedding the script
If you’re working with a smaller piece of code to improve your site’s functionality, it’s better to use the embed component available in Framer.
While it might seem like the same thing, it’s not. If you embed the script, the browser doesn’t have to:
Establish the connection with the third party.
Download the script.
Drop the connection.
Tip 6: Beware of complex animations
Impact: High 🚀🚀🚀
Effort: Low 🙂
Everybody loves fancy animations on a website - everybody except the browser.
This is because animations require the browser to recalculate the positions and visual styles of elements on the page multiple times per second.
The more animations you have (and the more complex they are), the harder the browser will have to work to make them function.
Actionable step:
Consider reducing (and/or simplifying) the number of animations on your website.
The fewer animations you have, and the easier they are to render, the faster your website will load.
Tip 7: Opt For A Google Font
Impact: Low 🚀
Effort: Low 🙂
As with many other things on this list, Framer already does the heavy lifting by optimising your fonts.
But, If you want a little (and I underline “a little”) more speed, you might want to opt for a Google font rather than a custom font.
However, the rewards are minor, so it might not be worth the swap.
Actionable step:
If you already have a custom font in mind that you want to use, try searching the Google Fonts library for a similar one.
If that’s the case, consider switching the custom font for the Google one.
Test, test, and test
The most important advice I can give you is always to test whether your actions are making any difference.
If you think one of the steps outlined above will help you speed up your website, implement it and test it.
Do you suspect a part of your website is causing issues with your speed performance? Remove it and test it.
Always test before and after making any changes. This will ensure you’re not shooting in the dark. And do more than one test! Especially if you rely on a tool rather than real-world data.
While the best possible data you could ever get are core web vitals, I understand you might want a faster way to measure your results. If that’s the case, try one of the following tools:
(The good ol’) PageSpeed Insights
FAQs
Q1 - Do PageSpeed Insights Affect SEO?
No, PageSpeed Insights don’t affect your SEO. Your Core Web Vitals do.
Q2 - Why Are My Core Web Vitals Not Available?
Core web vitals are only available after Google has gathered a good amount of data. If your website is new or doesn’t have enough traffic, your core web vitals report will not be available.
Q3 - Are Framer Websites Fast?
Yes, Framer websites can be fast. By combining Framer’s built-in optimisations with the techniques provided in this guide, you’ll have no problem making your site load quickly.
Conclusion
A slow website can be caused by a myriad of things. However, the problems outlined above are the most common and have the biggest impact on performance.
That being said, I want to thank you for taking the time to read the whole guide. I hope you’ve found it helpful.
If you want a done-for-you optimisation service for your Framer website, do not hesitate to reach out.
If you’ve found the article helpful, I kindly invite you to share it with a friend. Thanks in advance ;)
