How to debug your site performance

Causes for Slowness

There are a lot of technical things that Framer does automatically do to make your site as fast as possible so that you don't have to worry about them: local caching, pre-rendering, optimizing your images and much more. So when your site is slower than you'd like it's typically something specific to your site that you can fix.

Always start by figuring out if your site is just slow for you or for everyone. The best way is to check a few different computers (with different browsers and connections) and run a Lighthouse test.

Common Issues

We analyze a lot of websites here at Framer and this is a checklist of the most common things that we see make sites slow. You can use it as a checklist to quickly figure out what might be making your site slow:

1. Third Party Scripts

Things like Google Analytics, Twitter SDK, Facebook SDK, HubSpot, Segment, Amplitude, Intercom etc. are by far the most common causes of slow loading sites. Basically everything that you put in your custom head scripts. Even while it's often a single line of code, each of them can load megabytes of JavaScript that has to be parsed and executed. Use as few as possible.

2. Custom or Google Fonts

Even while Framer optimizes font loading automatically, they can still be hundreds of kilobytes to load. But what makes font loading extra bad is that your site technically cannot display any text until the font is loaded, essentially showing a blank page (in reality it's a bit more complex). It's best to choose a small custom font (in size) or a web default font for speed. If you upload your own font, always make sure to use the optimized .woff2 format.

3. Video

Videos by far need the most bytes so they make everything else load slower, especially if you have multiple videos on a single page. You can postpone the downloading by turning off autoplay (for some videos). Also make sure you compress your video as efficiently as possible, which can be really hard with tons of settings, or let YouTube do that work and host it from there (using the YouTube component).

4. External Embeds and iframes

Anything you embed (via the embed component) like HubSpot forms or Spline 3D illustrations essentially get a free pass to embed an entire website into your website. So now your visitors load two sites when they come by, or as many as you embed. Framer makes sure to lazy load embeds automatically (they only get loaded when they're visible) but many of them or bad behaving ones will definitely slow your site down.

5. Lottie Animations

Lottie animations are great and typically fast, but make sure your source JSON file is small. Once it's more than 100kb you should carefully study if it's doing the right thing or worth the performance hit.

6. Images

Framer is very good at optimizing images. It automatically recompresses them to the right size and in a modern format that the visitors browser supports (.webp or .avif). Even gifs! But if you add enough images to any site it will eventually become slow because of the bytes.

7. Blur, Shadows and Especially Background Blur

Blurs and shadows are expensive operations for computers because to draw a single pixel they suddenly need to average all the pixels around too (depending on your blur radius). To draw 100 pixels with a 10px blur it has to calculate 100 * (10 + 10) * (10 * 10) = 40,000 pixels (instead of 100). If you make the blurs big enough, animations and scrolling will become slow.

8. SVG Images

Even though Framer can optimize SVG, it cannot recompress them like other formats. We sometimes see SVG images that are megabytes in size which is a sure cause for slow loading sites. (A common case when this happens is when you accidentally include a raster image inside an SVG file.)

9. Very Large Pages

It's easy to build big sites in Framer and it's fun. But if you make your pages too large (in height) you'll add a lot of elements and enough can make loading and scrolling slow.

10. Optimization Errors

If you use custom code components, subtle errors can cause optimization errors in the backend because we can't pre-render your site. While your site will still work, it will load slower than ideal. If you see optimization warnings, you should tweak your code components so they can be optimized.

Advanced

To do a deeper inspection, open the web inspector and select the Network tab:

Order the network requests by size and inspect the top ones. Here are tips for different types:

HTML The document is always hosted by Framer. If the document is too small (~10kb) make sure your site is pre rendered correctly. If the document is too big (>100kb) let us know.

Images If the images are hosted from framerusercontent.com check if they are in .webp format and generally not larger than 100kb. If the images are hosted from somewhere else they are likely loaded by a component or external library. Make sure they are optimized by size and format.

Scripts Check for scripts that are big (>100kb) and not hosted from framerusercontent.com. They are typically loaded by an integration, custom code, or component and can really slow your site down. To see how much they affect your site, try running a Lighthouse test with these scripts blocked. Examples are: YouTube, Facebook, Twitter, Intercom, Google Analytics, Amplitude, etc. If they slow down your site (too much), reconsider using them at all.

Fonts Check for unexpected fonts that get loaded. You might have a single text field that needs to load a whole separate font to display. If you see .ttf or .otf fonts, those might be your custom fonts – try uploading a .woff2 file to Framer instead, it’s typically smaller. If a font seems extremely large (>1mb), (like in the screenshot above) let us know.

Videos Videos always somewhat slow down your site because they take a lot of bandwidth. Be careful adding too many, especially if they’re set to autoplay.

Known Issues

We still have a few things to improve for page performance. They’ll be landing soon.

• We can’t always determine the used image pixel size on the page, mainly when images are used in stacks with width or height set to % or fr. In this case we might be serving too large images.

• Combinations of components with variants and breakpoints can generate too much html with pre-rendering.

• We don’t support image cropping yet so if you only use part of an image, we might be sending too many pixels to users.

• Also remember that your custom code can do anything to a page, so it can potentially also slow everything down. The majority of performance issues we see are because of custom code.