How Do You Fix Render-Blocking Scripts on a Webflow Site?

A script in the page head without async or defer stops the browser from painting the page until it has downloaded and run. On Webflow sites these scripts come from Site settings head code, page head code, embeds inside components and third-party widgets. Find them with Lighthouse and view-source, remove anything unused or duplicated, move page-only scripts to that page, add defer or move scripts before the closing body tag, pin library versions, then re-measure under the same conditions. On our own migration page, that took lab LCP from 10.8 s to 4.6-5.4 s.

This guide is for the marketing or web lead who owns a Webflow site's custom code and keeps seeing a poor mobile score. It covers what Webflow controls, what you control, and how to change scripts without breaking the forms and sliders that depend on them.

What makes a script render-blocking on a Webflow site?

Chrome's Lighthouse documentation on render-blocking resources flags a script tag that sits in the head of the document and has neither a defer nor an async attribute. It also flags stylesheets that are not disabled and have no media attribute matching the device. The browser has to fetch and run those files before it can paint anything.

The two attributes do different things. MDN's script element reference explains that a defer script runs after the document has been parsed, in the order the scripts appear, while an async script runs as soon as it arrives, in whatever order the downloads finish. Module scripts are deferred by default. Use defer for anything that needs the page or another library; use async only for independent scripts such as some analytics tags.

In Webflow, custom code lives in four places, all covered in Webflow's custom code article:

Code Embed elements, including embeds inside components, add a fifth place that is easy to forget. Webflow's own advice in the same article is that adding external script tags to the head can slow page loads, and that you should consider async or defer. It also notes that newly published Webflow sites have included jQuery 3.5.1 since August 2020, and that importing other versions may cause conflicts. A second copy of jQuery in your custom code is therefore a red flag twice over.

How do you find the scripts that slow your pages?

Start with evidence, then build an inventory.

1. Run Lighthouse on mobile for your two or three most important pages. In Lighthouse 12 the list appears as "Eliminate render-blocking resources"; Chrome's documentation notes the audit moved into the Render-blocking requests insight in Lighthouse 13. Note each URL it lists.
2. View the page source and read everything between the opening and closing head tags. Every external script without async or defer is a candidate.
3. Open each code location in Webflow (the four boxes above) and list what each script is, which pages use it, and who added it.
4. Search your components for Code Embeds. A script inside a shared component, such as a logo marquee, loads on every page that uses that component.
5. Check the site usage dashboard. Webflow's Bandwidth overview says the assets table flags "Move to page" when a JavaScript or CSS bundle is over 250 KB, with the advice to move page-specific scripts from Site settings to that page's settings.

Scripts accumulate because tools do. In Webflow's survey report with Vanson Bourne, The 2026 State of the Website (survey June to July 2025), the chart headed “Tech stacks continue to grow” shows the share of organisations reporting a growing stack rising from 90% to 95% year over year. Each new tool tends to leave a tag behind.

Paste any head code, footer code or embed into the checker below to get a first pass. It runs in your browser and never executes or fetches the scripts.

Which scripts can you remove, defer or move?

Apply these rules to every row of your inventory, in this order:

1. No matching element on the page: remove it. A slider library on a page with no slider, or a form-validation plugin on a page with no form, costs load time for nothing.
2. The same library twice: keep one. Duplicates often come from a component embed plus a site-wide tag, or from two people adding the same tool.
3. Used on one page: move it to that page's settings. Site-wide code runs everywhere.
4. Needs the page or another library: add defer. Deferred scripts keep their order, so a library and the code that uses it still run in sequence.
5. Independent and order does not matter: async is an option. Check the vendor's installation guide first.
6. Unpinned version: pin it. A CDN path ending in @latest can change under you without warning. Use an exact version.
7. Inline code that calls a deferred library: wrap or move it. MDN notes that defer has no effect on inline scripts, so an inline call can run before the library it needs. Put that call in its own deferred file, or run it on the DOMContentLoaded event.

Lighthouse's own guidance follows the same order: inline what is critical and small, defer what is not, and remove what is unused.

Why do sliders, consent banners, fonts and chat widgets matter most?

A client once asked us exactly this: which scripts are needed in production, and how consent tools, sliders, fonts and widgets affect the first render. Webflow's site speed article lists third-party integrations, embedded content and excessive interactions among the causes of slow pages.

• Sliders. Third-party slider libraries are usually large and are often loaded site-wide for one carousel. Load the library only on the pages that have a slider, defer it, and defer the code that starts it.
• Consent banners. A consent tool may need to run before your analytics tags so it can hold them until the visitor chooses. That is a reason to install it once and keep it lean, not to load it twice or to defer it blindly. Follow the vendor's own guidance on placement.
• Fonts. Preloading tells the browser to fetch a file early. MDN's preload reference notes that font preloads need the crossorigin attribute, and web.dev's font best practices warn that preloading takes browser resources away from other files. Preload only the one or two font files the first screen uses.
• Chat and other widgets. A chat widget rarely needs to exist before the visitor has seen the page. Many vendors offer a delayed or on-click loading option; check their documentation before you write your own loader.

How do you change scripts without breaking forms and sliders?

Change one thing at a time and test the things that depend on it. The usual failure is not the removed script; it is the script that depended on it. A validation rule that runs before its now-deferred plugin arrives, or a slider init that runs on every page while the library now loads on one, will throw errors the moment you publish.

Before you edit, map dependencies: which inline snippets call which library, and on which pages. Save a copy of every code box you will change. Then work through the checklist below, publish to the staging domain first, and test every form and slider page on a phone before publishing to your custom domain.

How do you measure the result honestly?

Separate lab data from field data. web.dev's article on lab and field data explains that field data comes from real visitors, on their real devices and networks, while lab data is a test run under fixed conditions. Lighthouse is a lab tool. Its scores move between runs, so one run proves nothing.

For the lab side:

• Use the same tool, version, device profile and pages before and after.
• Run each page several times and report the range, not the best run.
• Record the date, the tool and the profile next to every number.

For the field side, Google's thresholds in Web Vitals are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, measured at the 75th percentile of page loads. Search Console's Core Web Vitals report shows those field values over the last 28 days, so a change you publish today takes weeks to show fully.

What changed when we fixed our own pages?

On 12 October 2026 we applied this method to activeset.co. The before-and-after figures below are lab measurements on our own site: local Lighthouse 12, mobile profile, several runs, 12 October 2026, for one page, /agency/website-migration. They are not field data and not a client result.

What we changed:

• Removed a slider library that loaded on every page but had no slider on most of them; it now loads only where a slider exists.
• Loaded a form-validation plugin only on pages that have a matching form.
• Replaced an unpinned @latest slider library with a pinned version and removed a duplicate copy of its extension.
• Added preloads for the three font files the first screen uses.

On this page the LCP element was the hero heading, not an image, and almost all of its LCP time was render delay, which is why removing blocking scripts moved it so much. We measured the homepage too, but its lab runs varied too widely between runs to report a fair before-and-after, so it is not quoted here. Field data for both pages is still accumulating in Search Console.

What belongs in a monthly script check?

Five checks keep a clean head clean:

1. Re-read the four custom code boxes and your component embeds for anything new.
2. Check that every library is pinned to an exact version.
3. Run Lighthouse on mobile for your top pages, three runs each, and log the ranges.
4. Look at the Core Web Vitals report in Search Console for pages moving from Good to Needs improvement.
5. Remove tags for tools your team has stopped using.

Our Webflow maintenance checklist puts this alongside the rest of a site's monthly care, and the technical SEO launch checklist covers the speed checks to run before a launch. If you are weighing a move off Webflow for speed reasons, our Astro vs Webflow comparison is worth reading first.

How ActiveSet does it

ActiveSet is a Webflow Premium Partner based in Bengaluru, India. We build on Finsweet Client-First, with the style guide set up first and reusable components, which keeps shared code in a small number of known places. Builds are reviewed on staging with Markup.io before launch. The migration-page fix above is our own site, measured in the lab and labelled as such.

For speed and search work on an existing Webflow site, see Webflow SEO.

Sources

• Chrome for Developers, Eliminate render-blocking resources, checked 14 Oct 2026
• Chrome for Developers, Render-blocking requests, published 8 Oct 2025, checked 14 Oct 2026
• Webflow Help Center, Custom code in head and body tags, updated 2 Sep 2026, checked 14 Oct 2026
• Webflow Help Center, Bandwidth overview, updated 31 Aug 2026, checked 14 Oct 2026
• Webflow Help Center, How do I optimize site speed in Webflow?, updated 31 Oct 2025, checked 14 Oct 2026
• MDN, The script element, checked 14 Oct 2026
• MDN, rel=preload, checked 14 Oct 2026
• web.dev, Best practices for fonts, checked 14 Oct 2026
• web.dev, Web Vitals, checked 14 Oct 2026
• web.dev, Why lab and field data can be different, checked 14 Oct 2026
• Google Search Console Help, Core Web Vitals report, checked 14 Oct 2026
• Webflow (with Vanson Bourne), The 2026 State of the Website, survey June to July 2025
• ActiveSet, lab measurements of /agency/website-migration on activeset.co, local Lighthouse 12, mobile, several runs, 12 Oct 2026