Why your Webflow site is slow

A slow Webflow page does not automatically need a new platform. First, find what the browser is waiting for and what it is busy doing. Images, scripts, animation and fonts are useful places to look, but the diagnosis should come from the page, not a list of usual suspects.

Start with an important page and a repeatable test. Check mobile as well as desktop. Record the URL, test conditions and a baseline before changing anything. A single performance score is a starting point, not an explanation.

Images: inspect what the page actually loads

Find the element responsible for Largest Contentful Paint. It might be a hero image, but it can also be text or another large visible element. The useful question is when that element becomes available and what delays its appearance.

For an image, inspect the requested file, its dimensions and where it appears. A wide background photograph, a logo and a small card thumbnail should not all receive the same treatment. Choose responsive sizes around the rendered size and intended displays rather than enforcing one maximum width across the site.

Keep below-the-fold images out of the critical path, but do not lazy-load the image responsible for LCP. A smaller file will also have limited benefit if the browser cannot discover it until late.

The check: compare the actual image request and LCP timing before and after the change. Do not stop at confirming that a WebP file exists.

Third-party scripts: give every request an owner

A script can load successfully and still make the page expensive to run. Inventory the tools loaded directly, through embeds and through a tag manager. For each, record why it exists, which pages need it and whether its timing matters.

Remove duplicates and unused tools first. Then consider page-specific loading and safe deferral. Avoid treating every third-party script as disposable: analytics, consent tools, experiments and forms may depend on a particular initialization order.

An optimization that loses early page events or prevents a form from submitting is not an improvement to the working site. Retest those outcomes alongside performance.

The check: inspect the network requests and main-thread activity, then confirm that the affected integration still delivers its intended result.

Animation: check the implementation, not just the effect

A simple-looking animation can do unnecessary work. Inspect what changes on each frame, whether multiple handlers repeat the same work, and whether the animation continues when it is not visible.

Transforms and opacity are generally better starting points than repeatedly changing layout-related properties, but the actual element and rendering work still matter.

Keep animation that earns its place. Simplify oversized timelines, duplicated listeners and effects that interfere with scrolling or interaction. Do not remove the site's intended behavior just to improve a lab score.

The check: record the interaction, look for expensive frames, and test the result on a representative mobile device.

Fonts: count downloaded files, not uploaded files

An unused uploaded font weight is not automatically a network request. Font downloads depend on how the font is referenced and used, and on any preloads. Check the browser's requests rather than counting files in the project.

Reduce unnecessary families and weights that are actually being loaded. Check subsets, fallback behavior and whether a preload helps the initial view. A font change can improve loading while introducing visible layout movement, so compare both.

The check: identify which font files are requested, when text becomes visible and whether the layout shifts as the font changes.

Read the measurements before choosing a fix

Loading speed, responsiveness and visual stability describe different parts of the experience. A page can display its main content quickly and still respond poorly when somebody opens a menu. It can respond promptly and still shift while images or fonts load. Treat these as separate observations rather than expecting one score to explain everything.

A controlled lab test helps reproduce a problem and compare a change. Field measurements describe what real visitors experienced over a reporting period. Use them together when both are available. A small site may not have enough field data for every individual URL, so be clear about whether a result describes a page, a group of pages or an origin.

Start with a small set of important templates: the homepage, an article, a campaign landing page and a page containing a conversion form. Test the same routes again after a change. Record the device or simulation, network conditions and relevant consent state so the comparison remains meaningful.

Match the symptom to the investigation

The table is a diagnosis aid, not a promise that the first suspected cause will be correct. Follow the evidence on the page. If the main delay occurs before the image request begins, compressing that image may improve transfer time without solving the largest delay.

Work through one hypothetical landing page

Suppose a campaign page contains a large hero image, an embedded video, a CRM form, a chat widget and several tracking tags. The first task is to understand when each resource is requested and what work follows. Do not remove everything at once; that makes it difficult to know which change helped and which functionality was lost.

Start with duplicates and unused requests. If the same analytics tool is loaded directly and through a tag manager, resolve the ownership and configuration. Then inspect the main visual element. Confirm that the browser discovers it early and receives a suitable image for its rendered size.

Next consider content that is not needed immediately. A video preview may avoid loading a full player until the visitor chooses to play it. A widget needed only on selected pages may not belong on every template. Each change should preserve the intended user journey and be measured under comparable conditions.

Finally, repeat the form and consent checks. A faster campaign page that loses attribution or prevents submissions has traded one problem for another. Record both the performance result and the business checks in the same change note.

Build a script ownership register

For each script, record its owner, purpose, required pages, loading condition and expected output. Include scripts added through tag managers and embeds, not just those visible in site settings.

A useful review question is whether the tool still has an active business owner. If nobody can explain why it exists, investigate before keeping it indefinitely. If it is required, ask whether it can be scoped to the relevant pages or initialized at a more appropriate point.

Avoid blanket deferral rules that ignore dependencies. A consent system, form library and analytics integration may interact. The correct timing depends on the behavior the site is meant to provide. Keep that behavior explicit and test it after changing the loading sequence.

Agree a performance budget the team can maintain

A performance budget is an operational limit chosen for this site, not a universal number copied from another project. It might cover image transfer on a campaign template, the number of third-party tools, or an interaction that must remain responsive on a representative phone.

Choose a few measurements the team can repeat and assign someone to review regressions. Add those checks when a new embed, font family or animation is introduced. This is more sustainable than a one-time cleanup followed by months of unreviewed additions.

Keep a short result record: route, symptom, proposed cause, change made, repeated measurement and functional checks. Over time, those records show whether performance problems are isolated implementation issues or recurring consequences of the architecture.

When does performance justify a migration?

A migration becomes relevant when the current structure repeatedly prevents reasonable improvements, or when rebuilding the public frontend serves other established needs as well. It should not be the automatic response to a low score.

Ask what would remain expensive after the move. Large media, poorly chosen scripts and complex third-party widgets can make an Astro page slow too. The proposal should identify which dependency or rendering decision changes, why that matters, and how the result will be checked.

If the problem can be fixed inside the existing site, use that result. If the architecture remains the obstacle, take the evidence into the platform decision guide and scope the move around the work that actually needs to change.

Diagnose first, then decide whether to migrate

A useful performance report names the page, the observed bottleneck, the proposed change and the result of a repeat test. It also records any behavior that must be protected.

If the fix is image sizing, duplicate tags or an unnecessary animation, address that first. If routine improvements repeatedly require working around the site's architecture, that is a separate reason to assess a migration.

The goal is a faster working site, not a particular framework or an unsupported promise of a perfect score.

Run a free site check for an automated starting point. It does not replace a manual investigation of scripts, integrations and real-user behavior.

Sources

• web.dev: Optimize Largest Contentful Paint. Checked September 18, 2026.
• web.dev: High-performance animations. Checked September 18, 2026.
• web.dev: Font best practices. Checked September 18, 2026.