Webflow page speed optimization: 63 fixes that actually work

Webflow can produce very fast sites - but most slow-down problems are caused by how a project is built, not by Webflow itself. This guide covers 63 proven fixes for images, fonts, scripts, animations, CMS structure, and advanced infrastructure, prioritized by impact.

Why Webflow sites become slow

The short answer: Webflow's CDN and hosting are fast by default. Performance problems almost always come from assets, scripts, and animations added as the project grows - not from the platform itself.

The most common webflow problems, in order of frequency:

• Oversized images exported directly from design tools without resizing or compression
• Autoplay background videos hosted on Webflow's CDN
• Multiple font families and weights loading on every page
• Heavy Lottie animations running on page load
• Too many third-party scripts (analytics, chat, tracking, consent banners)
• Unused CSS classes and interactions accumulating over time
• Large CMS collection lists loading too many items at once

‍

These problems usually build up gradually as new campaigns, pages, and integrations are added. The good news: fixing Webflow page speed rarely requires a redesign. In most cases, a focused cleanup of assets, scripts, and CMS structure delivers the biggest gains in the shortest time.

How to measure Webflow page speed

Never optimize blindly. Run your site through one of these tools before changing anything - they will identify exactly which elements are responsible for the most load time:

‍

Focus on Core Web Vitals (LCP, CLS, INP) and overall page weight. In most Webflow projects, a small number of assets - usually a few large images and 2–3 heavy scripts - account for the majority of performance issues. Identify those first, fix those first.

Quick Win: Run PageSpeed Insights on your homepage and your highest-traffic blog post or landing page. Those two URLs will reveal the most common patterns across the whole site.

How to speed up a Webflow site

The fastest way to improve Webflow performance is to optimize assets and reduce unnecessary scripts. In most cases, a few practical fixes can dramatically improve page load time without redesigning the entire website. The most impactful improvements usually include:

• compressing images and converting them to WebP or AVIF
• hosting videos outside Webflow
• removing unused CSS classes and interactions
• limiting third-party scripts
• lazy loading animations and media
• reducing the number of font variants
  ‍

These changes reduce the amount of data that needs to be downloaded when a page loads. As a result, the website becomes lighter, pages render faster, and Webflow performance scores in Lighthouse improve significantly.

Webflow image optimization

Images are the single largest contributor to page weight on most Webflow sites. These six fixes alone can reduce page weight by 50% or more on image-heavy pages.

1. Resize images to the correct display dimensions

Export images at 2× the size they display on the page (the '2× rule'). If an image renders at 400px wide, upload it at 800px. This keeps it sharp on Retina screens without downloading unnecessary pixels.

→ Most Webflow projects contain images uploaded at 2000–4000px wide that display at 600px. This is often the biggest single source of avoidable weight.

2. Convert to modern formats: WebP or AVIF for photos, SVG for icons

WebP and AVIF provide 30–50% better compression than JPEG/PNG at the same visual quality. SVG is ideal for logos, icons, and any vector element - infinitely scalable with near-zero file size. Use Squoosh (free, browser-based) to convert and compress in one step.

→ Webflow's asset manager accepts WebP and AVIF. AVIF offers the best compression but has slightly lower browser support - WebP is the safe default.

3. Compress images before uploading to Webflow

Even correctly sized images can be heavy if uncompressed. Use Squoosh, TinyPNG, or Vecta (for SVG) to reduce file size without visible quality loss. Aim for images under 200KB for hero images, under 80KB for content images.

→ Squoosh lets you see a side-by-side quality preview before downloading - compress as much as you can without visible degradation.

4. Confirm lazy loading is active on all images

Webflow enables lazy loading by default, but custom code or third-party scripts can override this. Open DevTools, inspect image elements, and confirm the loading='lazy' attribute is present on all images below the fold. Images above the fold (especially the hero) should load eagerly.

→ Check the 'Render-Blocking Resources' section in Lighthouse - images forcing eager loads often appear there.

5. Combine decorative images where possible

Multiple small decorative images (background textures, icon clusters, pattern tiles) each create an HTTP request. Combining them into a single CSS sprite or a single optimized image reduces request count and speeds up rendering.

→ This is especially useful for feature grids and testimonial sections with many small logos or icons.

6. Optimize the Open Graph image

The og:image loads when the page is shared on social media and also counts toward page weight. Keep it under 200KB, use WebP format, and set it to 1200×630px - the standard OG image dimension.

→ Check your og:image URL in the page source. Many Webflow sites use a 2MB+ PNG here without noticing.

Webflow video optimization

Video is the heaviest element on most pages. Two rules cover almost all cases.

7. Never autoplay video from Webflow's CDN

Hosting autoplay background video directly on Webflow counts toward your bandwidth limit and adds significant weight to every page load. Instead, host video files on Cloudflare R2, AWS S3, or a dedicated media server and reference them via URL in Webflow's video embed.

→ Cloudflare R2 has no egress fees, making it the most cost-effective video hosting option for Webflow projects.

8. Lazy-load all videos

Videos should not load during the initial page render. Add loading='lazy' to video elements or use an Intersection Observer to trigger loading only when the video enters the viewport. For YouTube/Vimeo embeds, use a facade (a static thumbnail image that loads the player only on click) - this alone can reduce initial load time by 1–3 seconds on pages with embedded video.

→ The 'Lite YouTube Embed' script is a popular, lightweight facade for YouTube that can be added via Webflow's custom code embed.

Webflow font optimization

Fonts load globally across the entire site. Every variant is a separate HTTP request. Small reductions here compound across every page.

9. Use WOFF2 format for all custom fonts

WOFF2 is the most efficient web font format - 30–50% smaller than TTF or OTF. Upload fonts as WOFF2 files in Webflow's font settings. If you only have TTF/OTF, convert them using FontSquirrel's Webfont Generator or Transfonter.

→ Always upload the WOFF2 version before TTF/OTF. Browsers prefer the first matching format declared.

10. Subset fonts: remove unused glyphs

Font files include characters for dozens of languages you probably do not need. Subsetting removes unused glyphs and can reduce font file size by 60–80%. Use FontForge to remove unused glyphs manually (step-by-step guide linked in internal links section), or use a service like Transfonter with subsetting options.

→ A standard Latin subset (characters A–Z, a–z, 0–9, punctuation) is sufficient for most English-language Webflow sites.

11. Limit font families and weights to what is actually used

Each font weight (400, 500, 600, 700) loads as a separate file. Audit your project: check which weights actually appear on pages. The visual difference between 800 and 900 weight is minimal - remove one. Aim for a maximum of 2 families and 3 weights total across the project.

→ Open the Webflow Designer, go to Style Manager, and search for font classes. Every weight you see listed is loading on every page.

12. Remove connections to external font APIs

Even after removing a font from your designs, the connection to Google Fonts or Adobe Fonts may persist in the project. This adds a DNS lookup, an API request, and potentially a render-blocking CSS file on every page load. To remove completely: delete all instances of the font from elements and classes, upload as a custom file, and rename it slightly (e.g. 'Inter Web') so Webflow does not reconnect to the API.

→ Check your page source for <link> tags pointing to fonts.googleapis.com or use.typekit.net - these confirm the API connection is still active.

13. Consider system fonts for body text

System fonts (Arial, Georgia, -apple-system, system-ui) are already installed on the user's device and require zero download. Using a system font stack for body text eliminates the largest font file on most sites while having near-zero visual impact for long-form content.

→ Test this on a staging environment first. Many brand guidelines require specific fonts for headings but are flexible on body - this is the lowest-effort font optimization available.

Project structure and CSS cleanup

As Webflow projects grow, unused styles, scripts, and nested elements accumulate silently. This section covers structural cleanup that delivers some of the most consistent performance gains.

14. Keep HTML structure flat - avoid deep nesting

Deeply nested div structures increase DOM size, slow rendering, and make CSS harder to manage. Keep sections and components flat and modular rather than stacking multiple nested containers. A simpler DOM tree renders faster and is easier for AI tools and crawlers to parse.

→ A DOM with more than 1,500 nodes is flagged by Lighthouse as a performance risk. Check yours under Lighthouse > 'Avoid an excessive DOM size'.

15. Remove links to external CSS frameworks you do not fully use

External CSS libraries like Bootstrap load entire stylesheets even when only a fraction is used. If the project does not genuinely depend on the framework, remove the link and keep styles inside Webflow. This eliminates additional HTTP requests and often saves 30–80KB of CSS.

→ Use the Coverage tab in Chrome DevTools to see what percentage of an external CSS file is actually used. Anything under 10% is a strong candidate for removal.

16. Delete unused CSS classes regularly

Unused CSS classes accumulate over time and increase the global stylesheet size. In Webflow Designer, open Style Manager and look for classes with zero uses. Removing them regularly keeps the project lighter and prevents the CSS file from growing uncontrollably.

→ Some teams schedule a monthly 'style cleanup' session in Webflow. The Clean CSS tool in Webflow Designer highlights classes unused on any published page.

17. Remove unused interactions and components

Interactions add JavaScript that the browser must download and execute. Unused interactions - animations you built and abandoned, or components that were removed from pages but not deleted - still load globally. Delete them from the Interactions panel and from the Pages/Components list.

→ Deleted components in Webflow may still have their CSS present if the classes were not removed. Always clean classes after deleting a component.

18. Remove draft pages with unused styles

Draft pages are not published, but their classes and interactions remain part of the global project structure and load on every page. If draft pages are no longer needed, delete them and clean up any orphaned classes they introduced.

→ Review draft pages quarterly and delete anything more than 3 months old that has not moved to published.

19. Minify CSS and JavaScript in project settings

Webflow allows CSS and JavaScript minification in Project Settings > Custom Code. Enabling this removes whitespace and comments from code, reducing file size by 10–30%. This is a one-click improvement that should be enabled on every production project.

→ Check Project Settings > SEO > Minify CSS/JS. If they are not checked, check them now - this is the easiest performance improvement in the list.

20. Disable unused Webflow features (e-commerce, memberships, reCAPTCHA)

Webflow modules load additional scripts even if you do not actively use them. E-commerce, Memberships, and reCAPTCHA each add weight to the page. Disable any that the project does not use via Project Settings.

→ reCAPTCHA adds ~30KB of JavaScript. If you use a honeypot field for form spam protection instead, reCAPTCHA can be disabled entirely.

21. Load scripts only on the pages that need them

Avoid adding all custom scripts to the global site header. A pricing calculator, a custom map embed, or a chat widget should only load on the specific page where it appears. Use Webflow's page-level custom code sections for this.

→ Move scripts from Site Settings > Custom Code to individual page settings wherever possible. This is one of the most overlooked optimizations on marketing sites.

Webflow interactions and animations

Every Webflow interaction adds JavaScript that must be downloaded and executed. On complex marketing sites with many animated elements, this is often the second-largest source of performance loss after images.

22. Build reusable interactions triggered by class, not individual elements

Instead of creating unique interactions for every element, trigger animations by class so multiple elements share the same interaction logic. This reduces duplicated interaction code and keeps the project easier to maintain and faster to load.

→ If you have more than 20 interactions in your Interactions panel, audit for duplicates. Most can be consolidated into 3–5 reusable class-based triggers.

23. Use element triggers instead of page-load triggers

Page triggers execute animations for the entire page during load, even if only a small portion of the page is visible. Element triggers ensure animations only run when the specific element enters the viewport. Switch page-load scroll animations to element-based 'scroll into view' triggers.

→ Page triggers are the most common cause of Webflow interaction performance problems. Auditing them is often the fastest single improvement for Time to Interactive.

24. Replace Webflow interactions with CSS transitions where possible

CSS animations are significantly lighter than Webflow's JavaScript interactions. Simple hover states, fade-ins, and transform animations are all achievable in pure CSS. Hover effects especially should be built with CSS :hover rules rather than Webflow interactions.

→ CSS hover states use the GPU and do not block the main JavaScript thread - making them faster and smoother than interaction-based hover effects at almost any scale.

25. Lazy-load GSAP and other animation libraries

Animation libraries such as GSAP should not load on page initialization. Load them only when the animation is required - either on user interaction or when the animated element enters the viewport. Use dynamic import() or a conditional script loader.

→ GSAP's core library is ~70KB minified. Lazy loading it saves that weight from initial page load on every visitor who does not scroll to the animated section.

26. Reduce or replace heavy Lottie animations

Lottie animations can be 200KB–2MB and require the Lottie player library (~60KB) to render. For simple animations, replace Lottie with CSS animations or lightweight SVG animations. For complex animations, lazy-load the Lottie player and use compressed .json files.

→ Use LottieFiles' Optimize tool to compress Lottie JSON files before uploading. Most Lottie files can be reduced by 40–60% without visual loss.

Third-party script optimization 

Third-party scripts are the #1 performance killer on most Webflow marketing sites. Analytics tools, chat widgets, consent platforms, and tracking pixels each add HTTP requests, JavaScript execution time, and external DNS lookups.

27. Audit all third-party scripts and remove unused ones

Use the Network tab in Chrome DevTools to see every external script loading on the page. Remove any that are no longer actively used: old analytics tools, abandoned integrations, unused marketing widgets, and duplicate tracking pixels. This is often the fastest way to reduce page load time.

→ Sort the Network tab by domain. Every unique domain represents a DNS lookup that adds latency - even for small scripts.

28. Replace heavy tools with lighter alternatives

Some platforms are significantly heavier than others. Cookie consent banners, in particular, vary widely - some load 3–5 scripts plus external fonts. Research lighter alternatives and benchmark their load impact before switching.

→ Use WebPageTest's 'Block' feature to test your site with specific scripts blocked. This shows exactly how much each tool costs in load time.

29. Lazy-load all non-critical third-party scripts

Most third-party tools do not need to load during the initial render. Use a script loading manager (or Webflow's custom code with a setTimeout wrapper) to defer loading until after the page becomes interactive. Analytics, chat, and marketing tools can all be loaded 2–3 seconds after page load without affecting user experience.

→ A 2-second delay on loading non-critical scripts often has zero user-visible impact while meaningfully improving Time to Interactive and Lighthouse scores.

30. Use async or defer on all non-critical script tags

Scripts without async or defer block the browser's HTML parser - meaning the page cannot finish loading until the script is downloaded and executed. Add defer to scripts that do not need to run immediately. Add async to scripts that are fully independent.

→ async executes as soon as downloaded (unpredictable order). defer executes after HTML parsing is complete (predictable order). Use defer for most custom scripts.

31. Avoid heavy review and rating widgets

Widgets from Capterra, Clutch, G2, and similar platforms often load multiple external scripts, fonts, and analytics tools. Recreate these components manually in Webflow using static data - a simple star rating SVG, a quote block, and a logo image load 99% lighter than the embedded widget.

→ The visual output of a manually built review component is often cleaner and more on-brand than the embedded widget anyway.

32. Use built-in Webflow components instead of custom equivalents

Webflow's built-in sliders, tabs, lightboxes, and forms are already included in Webflow's core JavaScript - they add near-zero marginal load. Using a custom JavaScript library to replicate these adds an entire new dependency. Prefer native Webflow components wherever they meet the design requirement.

→ Check Webflow's interactions panel before reaching for a third-party library. Many animation patterns teams use GSAP for are achievable with Webflow's built-in interactions.

33. Use server-side integrations instead of client-side scripts where possible

Some tools - certain analytics platforms, translation services like Weglot, and tag management systems - can be configured through DNS or server-side routing rather than loading scripts directly in the browser. This eliminates the client-side JavaScript entirely.

→ Ask your tool vendors whether server-side or tag-less integration is available. It is more common than most teams realise.

Webflow CMS and collection list optimization 

CMS-driven pages become heavy quickly as collection lists grow. These fixes prevent the most common CMS performance problems.

34. Limit collection list items per page

Webflow CMS collection lists can display up to 100 items, but loading 100 items means loading all their images, text, and associated assets at once. Limit lists to 12–24 items and use pagination or 'load more' buttons for the rest.

→ A collection list displaying 60 blog post thumbnails unoptimized can easily add 3–8MB of images to a single page load.

35. Use conditional visibility to hide irrelevant CMS fields

Instead of hiding elements with display:none (they still render in the DOM), use Webflow's conditional visibility settings to prevent elements from rendering at all when a CMS field is empty. This reduces DOM size and avoids loading assets for hidden elements.

→ Always check 'Is set' conditions on image fields in collection lists - empty image slots that still render a broken image URL add unnecessary requests.

36. Pre-calculate and store values in the CMS rather than computing in the browser

If your pages perform calculations (item counts, totals, averages, filter results), store the pre-calculated values directly in a CMS field and display them statically. Avoid JavaScript that loops through collection items to compute values on the client.

→ This is especially important for large CMS collections. A JavaScript loop that counts 500 items on page load can visibly delay Time to Interactive.

37. Use skeleton loading states for heavy CMS pages

On pages with large collection lists, show a lightweight skeleton layout immediately while the CMS content loads. This improves perceived performance significantly - the page feels fast even if the full content takes a moment to appear.

→ Webflow's interactions can trigger skeleton states - show placeholder elements on page load and hide them using a 'page load finish' trigger once CMS content is rendered.

38. Paginate or infinite-scroll instead of loading all CMS items at once

Pagination is the most effective CMS performance fix for content-heavy sites. Load the first page of results immediately and fetch additional pages only when requested. This keeps initial page weight low regardless of how many CMS items exist.

→ Finsweet's CMS Load library is the most widely used solution for Webflow CMS pagination and load-more patterns.

39. Lazy-load CMS images below the fold

Confirm that collection list images have loading='lazy' set. In Webflow, images in collection lists should inherit lazy loading by default, but check this in DevTools - particularly for images in nested collection lists or images set via custom HTML embeds.

→ Any image more than one screen height below the fold should be lazy-loaded. Above-fold CMS images (hero, featured post) should load eagerly.

40. Archive or unpublish old CMS items rather than hiding them

CMS items that are hidden via conditional visibility or filtered out on the frontend can still be included in the CMS query and counted toward collection limits. Archiving or unpublishing old items reduces query overhead and keeps collection lists cleaner.

→ Run a quarterly CMS audit. Unpublish items older than 2 years that are no longer linked to from anywhere in the site.

Advanced page speed optimization 

These techniques require developer support or Cloudflare. They are high-impact but more complex to implement - tackle them after the basics are done.

41. Implement critical CSS for above-the-fold rendering

Critical CSS extracts only the styles needed to render the visible portion of the page (above the fold) and inlines them in the HTML <head>. All other CSS loads asynchronously afterwards. This eliminates render-blocking CSS and speeds up First Contentful Paint significantly.

→ Critical CSS in Webflow is typically implemented via a Cloudflare Worker or a proxy layer. It requires developer setup but delivers consistent 20–30% improvement in FCP.

42. Delay Webflow's global JavaScript file

Webflow loads a global JavaScript file (webflow.js) that powers interactions and CMS components. On pages with minimal interactivity, delaying this file until after initial render allows the page to appear faster. This can be done via a Cloudflare Worker that injects a defer attribute.

→ Only delay webflow.js on pages where you have verified the delay does not break interactions. Test thoroughly on staging first.

43. Move heavy assets to external CDN storage

Large files - downloadable PDFs, case study documents, video files - hosted on Webflow count toward bandwidth and add load to the CDN. Move them to Cloudflare R2 (no egress fees) or AWS S3 and reference via external URL in Webflow.

→ This is also a bandwidth cost fix. See our guide on Webflow bandwidth limits for more on how hosting assets externally reduces both cost and load time.

44. Use server-side tagging via Cloudflare Zaraz

Cloudflare Zaraz moves tag execution (Google Analytics, Meta Pixel, etc.) to the server, removing those scripts from the browser entirely. This can reduce JavaScript execution time by 40–60% on pages with many marketing tags and improves data accuracy by bypassing ad blockers.

→ Zaraz is available on Cloudflare's free plan. Setup requires adding your Webflow site to Cloudflare and configuring tag rules in the Zaraz dashboard.

45. Use Google Tag Manager with async loading

If server-side tagging is not yet feasible, ensure GTM loads asynchronously and defer all tags that do not need to fire on page load. Use GTM's built-in trigger conditions to load tools only when needed (e.g. load chat widget only when a user scrolls 50%).

→ Audit your GTM container regularly. Most accounts accumulate 20–30 tags over time - many for campaigns that ended months ago.

46. Enable HTTP/2 (Cloudflare)

HTTP/2 allows multiple requests to load in parallel over a single connection, reducing the impact of many small assets loading simultaneously. Cloudflare enables HTTP/2 by default, but verify it is active for your domain in the Cloudflare dashboard.

→ HTTP/2 is especially beneficial for Webflow sites with many small JavaScript modules and font files.

47. Enable Argo Smart Routing (Cloudflare)

Argo Smart Routing optimises traffic routing between visitors and Webflow's servers, reducing latency - especially for international visitors. It is a paid Cloudflare feature (~$5/month) but delivers measurable improvements for sites with global audiences.

→ Test your site's load time from different countries using WebPageTest's multi-region feature before investing in Argo - the benefit is highest when baseline international latency is already elevated.

48. Optimise Cloudflare Cache settings

Set aggressive cache TTLs for static assets (images, fonts, CSS, JS) in Cloudflare's Page Rules. Assets that do not change frequently should be cached at the edge for as long as possible to avoid repeated origin requests.

→ Use Cloudflare's 'Cache Everything' page rule for Webflow's static asset URLs. This is particularly effective for font files and images that rarely change.

49. Enable Cloudflare Mirage for mobile image optimisation

Cloudflare Mirage automatically detects slow mobile connections and serves lower-resolution images to those users, improving mobile performance without manual image variants. Available on Cloudflare Pro and above.

→ Mirage is a no-configuration improvement for mobile performance. Enable it in Cloudflare Speed settings.

50. Use Cloudflare Page Rules to enforce minification and HTTPS

Cloudflare Page Rules can automatically enforce minification of HTML, CSS, and JavaScript, force HTTPS redirects, and enable performance features across the site without touching Webflow code.

→ Create a catch-all Page Rule for '*.yourdomain.com/*' with minification and HTTPS enforcement enabled. This ensures all pages benefit regardless of Webflow project settings.

51. Defer non-critical API requests

APIs that fetch dynamic content (pricing, availability, personalisation) should not block initial page render. Move non-essential API calls to fire after the page becomes interactive using DOMContentLoaded or a requestIdleCallback wrapper.

→ requestIdleCallback fires API calls during browser idle time - after the page has rendered and the user can interact, but before the first user action.

52. Reduce render-blocking requests

Any script or stylesheet in the <head> without async or defer blocks the browser from rendering the page. Review your Webflow site header custom code for render-blocking resources. Move scripts to the body where possible, or add defer.

→ Google Lighthouse flags render-blocking resources specifically under 'Eliminate render-blocking resources'. This is one of the most directly actionable Lighthouse warnings.

53. Host critical resources as first-party assets

Resources loaded from external domains (Google Fonts, CDN-hosted libraries, external analytics) require separate DNS lookups and TCP connections. Hosting these files directly in Webflow or on your own CDN reduces round-trip time.

→ Self-hosting fonts is the highest-value application of this fix. Use the Font Face Observer library to load self-hosted fonts with a fallback pattern that prevents invisible text during load.

54. Optimise preconnect and dns-prefetch hints

For unavoidable external resources, add <link rel='preconnect'> and <link rel='dns-prefetch'> in your site head to warm up connections before the browser needs them. This reduces connection overhead for third-party scripts.

→ Only add preconnect for resources that definitely load on every page. Too many preconnect hints can actually reduce performance by wasting connection slots.

55. Use IntersectionObserver for scroll-triggered content

Instead of loading all content immediately or using scroll event listeners (which fire rapidly and cause performance issues), use the IntersectionObserver API to detect when elements enter the viewport. This is the modern, performant way to trigger lazy loading and scroll animations.

→ IntersectionObserver is supported in all modern browsers and is significantly more efficient than scroll event listeners at any scale.

Core Web Vitals - targeted fixes

Core Web Vitals are the metrics Google uses to measure real-world page experience. Each has specific Webflow-relevant fixes.

‍

56. Improve LCP: preload the hero image

The hero image is usually the Largest Contentful Paint element. Add a <link rel='preload'> hint in your page head to tell the browser to fetch it as early as possible, before it is discovered in the HTML.

→ Add: <link rel='preload' as='image' href='/your-hero-image.webp'> in Webflow's page head custom code. This alone can improve LCP by 0.5–1.5 seconds.

57. Fix CLS: always set explicit width and height on images

Layout shift happens when images load without explicit dimensions - the browser cannot reserve space for them, so content jumps when they appear. Set width and height attributes on all images. Webflow sets these automatically for images added through the Designer, but check custom HTML embeds.

→ CLS is almost always caused by images or embeds without explicit dimensions. Check your CLS score in PageSpeed Insights and look at the 'Elements' section to see exactly which elements shift.

58. Fix CLS: avoid inserting content above existing page content

Cookie banners, notification bars, and marketing pop-ups that appear above existing content after page load are the second most common cause of CLS. Use position:fixed for overlays so they do not affect document flow.

→ Position sticky banners at the bottom of the viewport rather than the top - this completely eliminates their contribution to CLS.

59. Improve INP: reduce JavaScript execution time on interaction

INP measures responsiveness after user interaction. High INP is usually caused by long JavaScript tasks blocking the main thread when a user clicks or types. Audit your interaction JavaScript using Chrome DevTools' Performance tab - look for 'Long Tasks' (over 50ms).

→ Move heavy computation off the main thread using Web Workers, or break long tasks into smaller chunks using setTimeout scheduling.

60. Improve INP: remove or defer unused JavaScript

Every byte of JavaScript downloaded must be parsed, compiled, and executed - even if it is never used on the page. Use Chrome DevTools' Coverage tab to identify JavaScript files with high unused byte percentages, then lazy-load or remove them.

→ Third-party scripts are the most common source of unused JavaScript. A chat widget loaded on every page but only needed on the contact page is a common example.

Three more fixes

61. Use semantic HTML elements for structure

Using <header>, <main>, <section>, <article>, and <footer> instead of generic <div> elements improves both accessibility and SEO. Semantic structure also reduces DOM complexity and helps AI tools and search engines understand page layout.

→ Webflow supports semantic HTML tags natively. In the Designer, select any element and change its tag from the element settings panel.

62. Remove display:none elements from rendering entirely

Elements hidden with display:none are still part of the DOM, still trigger asset loads (images inside them still load in most browsers), and still increase DOM size. Use Webflow's conditional visibility to prevent them from rendering at all, or restructure components to exclude them.

→ This is especially impactful for mobile-only or desktop-only elements. An entire desktop navigation hidden on mobile via display:none still loads all its assets on mobile.

63. Use a CDN for all static assets

Webflow includes CDN delivery for hosted assets, but for assets hosted externally (case study PDFs, video files, downloadable resources), use a CDN with global edge nodes. Cloudflare R2 + CDN delivers assets from the closest location to each visitor, reducing load time for international audiences.

→ For most Webflow projects, this means ensuring all uploaded assets go through Webflow's CDN by default - avoid direct server links or external URLs unless the external host has its own CDN.

Webflow page speed checklist - quick reference

Use this as a pre-launch or quarterly performance audit checklist.

Final thoughts

Improving Webflow page speed is rarely about a single change. Most gains come from a combination of small optimizations across images, scripts, fonts, and project structure. By reviewing these areas systematically - using the checklist in Section 10 as a starting point - teams can significantly reduce page load time and keep sites fast as they grow.

The goal is not just a higher Lighthouse score. It is a website that loads quickly, feels responsive, and supports better user experience, SEO performance, and AI discoverability. Faster pages are also more likely to be cited by AI answer engines - page speed is one of the signals AI crawlers use when deciding which sources to surface.

Start with the quick wins (images, fonts, unused scripts), measure the impact, then work down the list. Most Webflow sites can move from a 45–60 Lighthouse score to 80+ in a focused day of optimization work.