Use a pre-publish checklist and real-visitor data to keep your site fast over time.
Performance isn't a one-time fix. A quick pass before each major publish catches the problems that slow sites down most, and real-visitor data tells you whether your changes are working. Use both to keep your site from slowly drifting back down.
Run a pre-publish checklist
This checklist pulls the key points from this category into one list. Use it before every big launch or update.
Images
- Uploaded at display size, about 2x the largest rendered width
- Compressed before upload, or converted to AVIF or WebP in the Assets panel
- Set to load lazily when they're below the fold
- Hero image set to load eagerly, never lazily
Fonts
- Only the families and weights the design uses
- Uploaded custom fonts in WOFF2 format
- System fonts where a brand font isn't needed
Video and media
- Background video short, muted, and compressed
- Long videos embedded from a video platform, ideally behind a click-to-load pattern
- Large downloadable files hosted outside Webflow
Styles and interactions
- Unused classes deleted in the Style selectors panel
- Unused interactions removed
Scripts
-
async on independent scripts and defer on scripts that depend on the page or each other
- Nothing that depends on another script set to
async
- Google Tag Manager container audited, with only the tags that need to fire
- Custom code in the smallest scope that works
Layout
- Fixed sizes or minimum heights set for embeds and sections that load late
- Fallback fonts matched to your brand fonts
- Banners given reserved space or set to overlay content
Publishing settings
- Minify HTML, CSS, and JS turned on
- Per page CSS turned on
- Asynchronously load JavaScript turned on, and custom code tested to make sure it still works
Final check
- Lighthouse run on the published site on mobile in an incognito window, with the median of two to three runs recorded
- Webflow health scan run and any flagged issues reviewed
Learn how to run a health scan.
Monitor real-visitor data
Lab tests tell you what to fix. Real-visitor data tells you how your site actually feels. Once your site is live, keep an eye on both so you can catch regressions early and confirm your fixes made a difference.
Use Google Search Console
Google Search Console comes straight from Google. Its Core Web Vitals report groups similar URLs from your site and shows how each group performs on mobile and desktop.
To view the Core Web Vitals report:
- Verify your site in Google Search Console
- Open your site's property
- Go to Experience > Core Web Vitals
- Click Open report next to the Mobile or Desktop chart
- Click a row in the Why URLs aren't considered good table to see which URLs are affected
Only indexed URLs appear in the report, and a group needs enough data to show up. Learn how to verify your site with Google.
Use PageSpeed Insights
PageSpeed Insights shows real-visitor Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) for a specific URL at the 75th percentile. Go to the Field data section of a PageSpeed Insights report to see them. Open PageSpeed Insights.
Note
Field data only shows up when a page gets enough real visits, and it reflects the previous 28 days of visits, so it can take a few weeks to show the effect of a fix. If a page has no field data yet, use Lighthouse to test your changes.
Know when lab and field data disagree
They often will. Lab data shows what a mid-tier phone on a slow network experiences, while field data reflects your real audience. Trust field data for pass or fail, use lab data to find fixes, and re-test after each meaningful change.
Check after every meaningful release
Performance regressions ship one change at a time. Re-check your metrics after any release that touches your pages, such as a new tag, an installed app, or a redesigned hero section.
Go deeper on each fix