To improve Core Web Vitals on a Webflow site, find the resource, interaction or layout change causing the delay, then adjust the part you control. A smaller hero image will not fix a slow filter button, and enabling asynchronous JavaScript can break a site whose custom code depends on execution order.
These 26 checks cover images, fonts, publishing options, scripts, Collection Lists and visual stability on Webflow-hosted pages. Start with the checks that match your failing metric. You do not need to apply every change, add a performance app or rebuild the site to make useful progress.
The guidance follows Webflow and browser documentation checked on October 23, 2026. It describes changes to investigate and verify, rather than results from a benchmark of customer sites.
Find the failing metric on the published page
Use the actual public URL, not the Designer canvas. Check an important landing page, a CMS detail page and a Collection index separately. Their assets and interactions can differ even when they share navigation.
Google's current Core Web Vitals targets apply at the 75th percentile of visits, with mobile and desktop assessed separately:
| Metric | Good target | Investigate first | Checks |
|---|---|---|---|
| LCP: main content becoming visible | 2.5 seconds or less | Hero delivery, text rendering, blocking resources | 1–15 |
| INP: response to qualifying interactions | 200 milliseconds or less | Scripts, large lists, event handlers, rendering work | 12–22 |
| CLS: unexpected layout movement | 0.1 or less | Media geometry, font swaps, injected content | 9, 20, 23–26 |
All three must meet their targets for a passing assessment. In PageSpeed Insights, record whether field data describes This URL or the whole Origin. Origin data can identify a broader problem but cannot confirm this particular page passes. If field data is unavailable, keep that limitation visible.
Use the lab diagnostics to form a specific hypothesis. For help reading the two datasets, see our PageSpeed Insights guide. Save the report, viewport and date before changing anything.
To inspect a cause in Chrome, open DevTools, select Performance, record a reload, and inspect the LCP and layout-shift events. For an interaction problem, start a recording, perform the slow action, then stop and inspect its event and main-thread work. Use the Network panel for request URLs, sizes and timing. Repeat with a comparable device and connection profile after a change.
1. Match image loading to the first viewport
Inspect the image identified as LCP in your trace. If it is visible immediately, check its Image settings in Webflow and remove lazy loading; use the eager option where appropriate. Keep offscreen images lazy so they do not compete unnecessarily with the first screen.
Webflow's native lazy-loading behavior applies to inline images, not CSS backgrounds. Older images may also need their settings checked individually. Do not assume every asset follows the same default.
Republish and inspect a cold-load waterfall at the affected viewport. The critical image should begin loading without waiting for a scroll or intersection trigger. Scroll down afterwards to confirm deferred images still appear. This check changes when an image loads; the next checks address which file is delivered and how large it is.
2. Verify responsive variants on uploaded images
Inspect the published image's srcset, sizes and selected currentSrc. A narrow layout should not automatically download the largest original. Check the rendered width and device pixel density before deciding a file is oversized.
Webflow's responsive-image documentation contains important exceptions: variants are generated for supported images uploaded directly, while API and CSV imports do not generate them. Backgrounds and images in rich text are also excluded from the documented responsive-image feature.
For an imported image without variants, upload a suitable original directly through Webflow or supply an already optimized file. After layout changes, Webflow documents Control + Shift + I on Windows or Command + Shift + I on Mac to remeasure responsive images across pages.
Republish, then compare the actual selected file at narrow and wide viewports. The presence of srcset alone is not proof that your sizes description matches the layout.
3. Right-size CSS background images
A background used for a small mobile hero can still transfer a large desktop file. Check its Network request instead of assuming Webflow's inline responsive variants cover it.
Export a version suited to the displayed crop and resolution, then update the relevant background style. If the artwork is meaningful page content, consider an image element with appropriate alternative text and an object-fit crop instead. Decorative artwork can remain decorative; changing the element type is not mandatory.
Compare transferred bytes and visual quality on the published page at each relevant breakpoint. Watch for an unintended desktop asset still loading through another class. This is a background delivery check, separate from changing an inline image's loading attribute or converting its format. Preserve the intended contrast and text readability when simplifying artwork.
4. Convert heavy raster assets with originals saved
Use the Assets panel's expanded view to select a heavy JPEG or PNG, choose AVIF or WebP, and click Compress. Webflow also provides Compress assets from the Collections panel menu. Republish after conversion.
The image conversion tool replaces the original asset. Download or otherwise preserve originals first. Keep social-sharing image compatibility in mind, especially when an asset also feeds an Open Graph field; avoid a blind conversion of every file to AVIF.
Start with assets actually transferred by your slow page. Compare the resulting request size, image quality, transparency and crop. A successful conversion is not automatically a useful optimization if the published page still references another large image or a broken URL. Preserve legible text within graphics and inspect the image at its real display size.
5. Replace decorative autoplay video with a still
If the hero's motion is decorative, test a still image that communicates the same message. A video can add network and decoding work before visitors have asked to watch anything, competing with more important resources.
Keep a clearly labeled video link when the full clip is useful. For an essential demonstration, retain playback and investigate its delivery instead of removing the information. This change concerns automatically playing page decoration; optional third-party player embeds are covered separately in check 17.
Compare the first screen and requests on the published mobile page. The decorative video should no longer download simply because the page opened, and the main message should remain understandable. Removing the visible video while leaving its source or a second hidden copy active does not establish that the cost disappeared.
6. Remove delayed hero reveals
An optimized image can finish downloading and still remain invisible while a loading screen, interaction or custom script waits. In the performance recording, compare the resource's completion with the moment the main content appears.
Remove an unnecessary initial hidden state or long entrance delay from the hero. Keep the heading and essential content readable before decorative animation runs. Google's LCP optimization guidance distinguishes this element-render delay from download time: compressing the file again may not address the actual wait.
Reload with a slow connection and check the filmstrip. The hero should appear when its required content and styles are ready, without a timer or unrelated widget deciding its visibility. Then confirm the simplified interaction still leaves navigation usable. Avoid hiding the whole page until every asset has loaded.
7. Remove unused font weights and references
List the font files requested by representative pages. Match each weight and style to a real use: body text, headings, navigation, buttons and emphasized text. Remove unnecessary variants after updating the classes and HTML tags that reference them.
For custom fonts, deleting an upload alone is insufficient if styling still references it. Use Webflow's Style manager to find the family name and update its uses before removing the file. Republish afterwards.
Check the Network font filter again, then inspect bold, italic, menus and form states. The goal is fewer unnecessary requests with the intended typography intact. Do not delete a weight solely because it is absent from the homepage: a shared component, another template or a supported language may need it. This check reduces the font set; the next addresses delivery format.
8. Use licensed WOFF2 files for custom fonts
Check the format and source of the font files you keep. Webflow recommends WOFF2 for custom uploads. In Site settings > Fonts, use a properly licensed webfont file rather than uploading a large desktop-font file simply because it is available.
When replacing a Google Fonts integration with a custom upload, Webflow's custom-font guidance recommends a unique family name to avoid continuing to load the Google-hosted version. Update the relevant styles to use the intended family.
Verify the actual font request URL and file type after publishing. Check accented characters, required language coverage and rendered weight. Local delivery is an option to evaluate, not proof of faster performance on every connection. Compare the result before keeping a change, and retain the original font and settings for rollback.
9. Balance font display with fallback geometry
Check whether the heading is invisible while its custom font downloads. Webflow's custom-font display settings can use swap so text appears with a fallback first. Then inspect what happens when the final font arrives.
As Google's font-loading guidance explains, rendering strategy has tradeoffs. A fallback with different letter widths can turn a two-line heading into three lines, shifting everything below it. Choose a closer fallback and adjust the surrounding layout rather than treating swap as a complete CLS fix.
Record a cold load with font requests slowed. Text should remain readable and the final font should not unexpectedly move the primary button. Repeat at a narrow viewport, where a small width difference can change wrapping. Review navigation and long translated labels too if the site supports them.
10. Enable appropriate code minification
In Site settings > Publishing > Advanced publishing options, review the separate HTML, CSS and JavaScript minification settings. Save and republish after a change. Check the delivered files and page behavior; do not assume a saved setting is already live.
Minification reduces source overhead, but does not remove expensive functionality. A smaller script can still run a long task. Keep an accessible copy of your custom source for maintenance, and verify spacing, menus and forms after publishing.
Use this built-in control before introducing another code-processing layer. Deleting Webflow's generated runtime, blindly purging styles or editing platform assets is a different and potentially breaking change. Also distinguish optimized publishing, which concerns Webflow's publishing pipeline, from making a visitor's page render faster.
11. Evaluate per-page CSS with Library constraints
On a large project, review Per page CSS in Advanced publishing options. It produces shared styles plus a page-specific stylesheet, reducing delivery of unrelated styles.
Webflow warns about custom CSS and shared Libraries, and recommends disabling the option on shared-Library consumer sites. Follow that constraint rather than enabling it everywhere.
For an eligible site, compare stylesheets after publishing. Inspect templates, component states and breakpoints, not just the homepage. Keep the change only when the intended styles remain available and delivery improves. A smaller file does not justify missing styling or a new layout shift.
12. Test Webflow's asynchronous JavaScript option
Webflow documents page-specific JavaScript bundles and optional asynchronous loading. Its documentation still notes a gradual rollout. The asynchronous option requires a paid Site or Workspace plan; check actual availability in your account.
Where available, evaluate Asynchronously load JavaScript under Advanced publishing options. Custom code and Library elements may depend on scripts that have not loaded yet. Republish, then exercise navigation, forms and dependent interactions under slow loading.
If behavior breaks, turn the option off and republish while a developer resolves initialization dependencies. Do not manually strip platform bundles to imitate this feature. Faster initial paint is useful only when the site still works.
13. Scope page-specific custom code to that page
A calculator script needed on one landing page does not necessarily belong in site-wide custom code. Inventory each addition and identify the pages that actually require it.
Webflow supports site-wide and page-level custom code, subject to plan and role access. Move a truly page-specific integration to the appropriate Page settings location, preserving required dependencies.
After publishing, verify that it works on its intended page and is absent from unrelated page requests. Also check whether a tag manager or embedded component loads the same script elsewhere. Moving one copy while leaving another global loader active will not remove the cost. Keep genuinely shared functionality, including required consent behavior, at its appropriate scope.
14. Remove duplicate library imports
Inspect script requests and custom embeds for repeated libraries or competing versions. Two widgets may each bring their own copy, even when the surrounding Webflow page already provides the dependency.
Webflow specifically warns that importing another jQuery version can cause conflicts. Ask the integration owner whether a duplicate can be removed or configured to use a compatible existing dependency. Do not delete the platform-provided copy simply because another URL looks similar.
Retest each dependent component after publishing. Look for duplicate initialization as well as duplicate downloads: a button with two handlers can produce repeated requests or submissions. The useful outcome is one intentional, compatible dependency path and one expected action per interaction. This differs from page scoping: a library can be correctly scoped and still loaded twice on that page.
15. Defer external custom scripts in dependency order
For classic external scripts you control, defer allows downloading without blocking HTML parsing and preserves document order. This illustrative pattern assumes the second file depends on the first; replace both paths with your actual hosted files:
<script defer src="/scripts/calculator-library.js"></script>
<script defer src="/scripts/calculator-init.js"></script>
Script loading attributes have different behavior: async does not preserve this order, and defer does not defer a classic inline script. Neither attribute guarantees readiness of an unrelated asynchronously loaded Webflow dependency.
Have a developer map dependencies before changing an integration's prescribed installation. Publish and test a cold load, including early clicks. Confirm parser blocking decreased without introducing initialization errors or losing business events. This check concerns custom script execution order, separate from Webflow's built-in asynchronous option.
16. Retire third-party tags without a current purpose
For each analytics, advertising, chat or experiment tag, record its owner, purpose and required pages. Identify abandoned experiments, old pixels and integrations the business no longer uses. Remove an obsolete tag from the actual loader, which may be an integration setting, custom code or a tag-manager container.
Keep required consent and measurement behavior intact. Moving everything into a tag manager does not make the resulting browser work disappear, and delaying tags until after an audit is not a user-experience improvement.
Compare startup work and interaction traces before and after removal. Verify the remaining conversion events once, with consent states exercised appropriately. Google's INP optimization guidance explains why downloaded scripts still cost parsing, compilation and execution time. Removing an unnecessary dependency addresses work rather than just its loading label.
17. Replace optional embeds with click-through previews
An optional video, map or social feed may load a substantial application before anyone uses it. For a simple alternative, replace the embed with a lightweight image and a descriptive link to the actual destination. In Webflow, a Link Block containing the preview and visible action text can provide that route without an inline player.
If playback must stay on the page, a developer can implement a facade that loads the embed on interaction. Adding a picture on top of an already-loading iframe does not defer it.
Verify no player requests occur before activation, then test keyboard access and the destination or playback. Keep essential forms and primary information immediately available. The cited Lighthouse facade audit was retired in version 13; use the underlying technique and Network evidence rather than looking for that old audit label.
18. Paginate large Collection Lists
If a listing renders many cards immediately, reduce the amount delivered and rendered on each page. For a dynamic Collection List, select it and open Element settings > Collection list settings > Paginate items, then choose an appropriate number in Items.
Webflow's pagination documentation limits this control to dynamic lists. Keep the Next and Previous links usable, and confirm every item remains reachable. There is no universal card count that makes every design fast.
Compare the rendered card count and interaction performance on the published listing. A custom filter that downloads every item and hides most of them may retain the original cost. Also review discovery: Webflow's own site search indexes only the first pagination page, so ensure important CMS detail pages have suitable other discovery paths. Do not confuse that limitation with Google's indexing behavior.
19. Remove redundant layout wrappers
Inspect repeated components in the Navigator. A card may contain wrappers left over from earlier layout experiments, with several elements providing no current layout, semantic or interaction purpose.
Simplify one component carefully, preserving class behavior, positioning and interaction targets. This reduces structure within each item; pagination reduces the number of items. They solve different sources of rendering work.
Measure the rendered DOM and layout work before and after the change. Do not apply a universal DOM-node target or flatten meaningful structure just to lower a count. The browser still needs a correct, accessible page. Check the component at every affected breakpoint and in empty or long-content states. Deleting an unused asset from the Assets panel is not equivalent to reducing the DOM or requests of a published page.
20. Animate transforms instead of layout properties
Review interactions that repeatedly change width, height, margins, top or left. When the intended effect is simply movement or scaling, evaluate a transform-based alternative and use opacity for fading where appropriate.
Google's layout-shift guidance distinguishes transforms from changes that move surrounding layout. This is not permission to animate everything: an expensive scene can still consume substantial rendering resources.
Record the interaction, inspect layout work and confirm neighboring content remains stable. Check mobile navigation and reduced-motion behavior as well. A scroll animation is not itself an INP interaction, but work running during scrolling can overlap a subsequent tap. Test the actual click or tap while the effect is active rather than calling any dropped animation frame an INP failure.
21. Shorten expensive click and input handlers
Record the specific action that feels slow: opening a menu, choosing a filter or typing into a custom search field. Determine whether the wait happens before the callback, inside it or while the browser renders the result.
If your custom handler performs unrelated work before updating the interface, have a developer move nonessential work out of that immediate path. For example, a filter should provide truthful visible feedback without first finishing an unrelated analytics calculation. Avoid showing a completed result before the operation actually succeeds.
Repeat the action during startup and after the page settles. Verify both responsiveness and the correct result, including errors and rapid repeated inputs. Making an individual callback short is separate from merely deferring its script download; the work still matters once the user invokes it.
22. Batch layout reads before DOM writes
Custom code can repeatedly change styles and immediately ask the browser for geometry. That read/write pattern can force synchronous layout during an interaction. Look for repeated layout events in the trace before rewriting code.
For a developer, this illustrative card-width update takes one measurement and then performs the writes. Replace the selectors with the intended elements; it is not a script to paste into every site:
const container = document.querySelector('.card-container');
if (container) {
const width = container.getBoundingClientRect().width;
document.querySelectorAll('.sized-card').forEach((card) => {
card.style.width = `${width}px`;
});
}
Prefer CSS for sizing when it can express the requirement. If JavaScript is needed, avoid measuring layout again after every write in a loop. Verify equivalent layout and reduced forced-reflow work. This targets a particular rendering pattern, rather than removing useful functionality from the handler.
23. Reserve space for inline images
Reload with image delivery slowed and watch whether text moves as images appear. Inspect the published markup for correct width and height information, or reserve the intended aspect ratio in the layout.
For a responsive image, the layout can remain fluid while preserving its ratio. Avoid forcing a fixed height that crops content unintentionally. Where mobile and desktop use different art direction, reserve geometry appropriate to each layout.
Confirm the image's box exists before the pixels arrive and remains appropriate after loading. Inspect CMS entries with different image shapes, not just one ideal example. A tiny, compressed image can still cause a layout shift if the page initially allocates no room for it. Alternative text serves accessibility and meaning; it does not replace sizing information.
24. Give embeds a stable loading container
A video player, map or booking widget may expand after its script initializes. Reserve the expected space in its surrounding container before the widget arrives. A video can use an appropriate aspect ratio; a form may need a responsive minimum height based on its real states.
Check both the host container and the embed's own resizing behavior. You may need an integration-supported sizing option or a different layout when a third-party frame changes unpredictably.
Slow the embed's requests and compare placeholder, loaded and error states. Keep the region usable without collapsing it unexpectedly. This check stabilizes an embed that remains in the page; check 17 reduces whether an optional embed loads at all. Neither a facade nor a reserved box alone guarantees the other benefit.
25. Stop banners pushing content down after load
Check announcement bars, consent notices and promotional banners that appear above existing content. If their late insertion pushes the heading and primary action down, reserve their space from the initial layout or use a suitable non-flow presentation.
An overlay must not obscure essential content or controls. Preserve the notice's function and required choices; removing consent behavior to improve a score is not an acceptable optimization.
Test first visits, return visits and saved-choice states. Include narrow screens and longer notice text. Watch the heading's position while the notice initializes and closes. The reported shifted heading may be the victim, while the actual cause is the newly inserted banner above it. Fix the insertion or layout contract rather than arbitrarily repositioning the heading.
26. Keep asynchronous content replacements stable
Inspect components that replace existing content after a fetch: a personalized card, stock message, filtered result area or recommendation block. Unlike a new banner, this component already has a slot, but its loading and final states may occupy different space.
Define a layout for loading, success, empty and error states. For example, a recommendation slot should not shrink to zero while waiting and then push the article down when cards return. Use a suitable minimum size, predictable card geometry or a user-triggered update without clipping meaningful content.
Throttle the request and test a slow response, no results and a failure. Keep keyboard focus and useful status messages intact. A click does not excuse any layout movement indefinitely: a delayed response can still create an unexpected shift after the immediate interaction window. Inspect the whole sequence, not just initial loading.
Verify the release and keep a useful baseline
Publish one change at a time where practical, then inspect the actual public page. Repeat comparable lab runs and exercise the affected user flow. Keep a change when the suspected bottleneck improves without breaking content, layout, consent, navigation or conversion behavior.
Use this record for each investigation:
Public URL and template:
Publication date/time:
Viewport, device profile and connection:
Observed metric and bottleneck:
Field-data scope: URL / origin / unavailable
Before report or trace:
One change made:
After report or trace:
Functional and accessibility checks:
Rollback setting or asset:
Field follow-up result and observation date:
For continued checks, Screpy's Core Web Vitals monitoring workflow lets you add important public URLs and review dated lab results within your plan's allowance. Screpy publishes this guide. Its lab measurements help detect changes; they do not establish real-user INP or a field-data pass.
PageSpeed Insights field data aggregates a rolling 28-day period, so a successful lab retest does not immediately replace the historical experience. If field data is missing, record it as unavailable and investigate with repeatable diagnostics or your own real-user measurements.
When a failure appears platform-owned rather than caused by an asset or customization, keep the exact URL, trace and reproducible steps for Webflow support. Avoid speculative hosting changes. Google uses Core Web Vitals in ranking, but good scores do not guarantee a higher position. The practical goal is a page that loads clearly, responds promptly and stays stable while people use it.