Page Speed Optimization: A Field-Tested Checklist

Most B2B sites are slow for reasons that have nothing to do with the front-end framework and everything to do with how the site got built and who has been adding to it since. A demand-gen team bolts on a chat widget, an analytics suite, three pixels, and a font loader, and six months later the homepage takes four seconds to become usable. Page speed optimization is rarely one heroic fix. It is a sequence of unglamorous decisions, made in the right order, with the highest-impact work done first. This checklist is the order we actually use in client engagements, and it is designed so a non-engineer can tell whether the work is paying off.

Start by measuring the right thing

Before you change anything, separate two kinds of data, because teams routinely optimize the wrong one.

Lab data comes from synthetic tools like Lighthouse or WebPageTest. It runs on a controlled machine and is great for diagnosing causes and comparing before-and-after on a single page.

Field data comes from real visitors, typically through the Chrome User Experience Report (CrUX) or your own real-user monitoring. It tells you what people actually experience across devices and networks, which is the only number that matters to the business.

A page can score 95 in Lighthouse and still fail in the field because your real audience is on mid-range Android phones over LTE, not a fiber connection. So:

1. Pull field data for your top five pages by traffic and revenue first.
2. Run lab tests on those same pages to find the causes.
3. Set targets in terms of the Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).
4. Re-measure after each change so you can attribute gains to specific work.

If you can’t point to a field-data number that moved, you optimized for a tool, not for a person.

For the deeper mechanics of moving each vital, our Core Web Vitals optimization playbook goes metric by metric. This checklist stays at the prioritization layer.

Cut the weight before you optimize the rest

The fastest request is the one you never make. Most page speed optimization wins come from deleting and deferring, not from clever tuning. Audit what the page actually ships and rank every third-party and asset by the value it delivers against the milliseconds it costs.

Third-party scripts

These are usually the single biggest tax on a B2B page, and the team that owns them is often marketing, not engineering. Build an inventory of every tag firing through your tag manager and direct embeds, then sort it into three buckets.

• Keep and load eagerly: consent management and anything legally required.
• Keep but defer: chat widgets, session replay, most analytics. Load them after the page is interactive, or on first interaction.
• Remove: duplicate analytics, abandoned A/B testing tools, pixels for campaigns that ended last year.

In our engagements it is common to find two analytics tools doing the same job and a heatmap script no one has looked at in months. Cutting those is free performance.

Images and media

Images are usually the LCP element, so they deserve attention.

• Serve modern formats (AVIF or WebP) with a fallback.
• Size images to their actual rendered dimensions instead of shipping a 3000px hero into a 1200px container.
• Set explicit width and height attributes so the browser reserves space and you avoid layout shift.
• Lazy-load anything below the fold, but never lazy-load the LCP image.

Fonts

Self-host fonts instead of pulling from a third-party CDN, subset them to the characters you use, and apply font-display: swap so text renders immediately. A single eagerly loaded web font can delay your largest text block by hundreds of milliseconds.

Fix the critical rendering path

Once the page is lighter, make sure what remains loads in the right order. The goal is to get the visible, above-the-fold content painted and interactive as fast as possible, and to stop render-blocking resources from holding everything hostage.

• Inline critical CSS for above-the-fold content and load the rest asynchronously so the browser can paint without waiting for a full stylesheet.
• Defer non-critical JavaScript with defer or async, and split large bundles so a visitor downloads only the code the current page needs.
• Preload the LCP resource, whether that is a hero image or a key font, so the browser fetches it early instead of discovering it deep in the document.
• Preconnect to required third-party origins so the DNS, TLS, and TCP handshakes happen before the asset is requested.

This is also where architecture starts to matter. If your homepage ships a 400KB JavaScript bundle to render what is essentially a static marketing page, no amount of preloading will save you. That is a build-time decision, not a tuning problem, which is why we build most B2B sites on Astro: it ships zero JavaScript by default and lets you opt into interactivity only where you need it. The right tool removes whole categories of this work.

Optimize delivery and caching

Now address how bytes travel from server to browser. These changes are infrastructure-level and tend to help every page at once.

Server response time

If your time to first byte is slow, everything downstream is slow. Static or pre-rendered pages served from a CDN edge will almost always beat a server rendering each request on demand. If you must render dynamically, cache aggressively at the edge and reserve true server-side work for genuinely personalized content.

Caching and compression

• Set long cache lifetimes on static assets and use fingerprinted filenames so you can cache forever and still ship updates.
• Enable Brotli compression for text-based assets; it beats gzip on the HTML, CSS, and JS that make up most of your payload.
• Use HTTP/2 or HTTP/3 so multiple resources load over a single connection without the old per-request overhead.

A practical decision rule

When deciding whether a page should be static, edge-rendered, or server-rendered, ask one question: does this content change per visitor at request time? If not, render it ahead of time and serve it from the edge. Most B2B marketing pages, including pricing, product, and the entire content library, are static content dressed up as dynamic. Treating them as static is one of the highest-leverage moves available, and it ties directly to how the site is structured in the first place. Our guide to B2B website architecture that converts covers how to draw those lines deliberately rather than letting a CMS decide for you.

Prevent regressions so the gains stick

The hardest part of page speed optimization is not getting fast once. It is staying fast after the next campaign, the next landing page, and the next well-meaning script someone pastes into the tag manager. Speed decays by default. Defend it with process.

• Set a performance budget in concrete numbers, for example a maximum JavaScript bundle size and a maximum LCP for key templates, and treat exceeding it as a bug.
• Add automated checks in CI that run Lighthouse against critical pages and fail the build when a budget is breached, so regressions get caught before they ship.
• Monitor field data continuously rather than checking once a quarter, and alert when a vital crosses your threshold.
• Give marketing a governed path for adding tags, with a lightweight review so the third-party inventory does not quietly double again.

Performance is a state you maintain, not a project you finish. The teams that stay fast are the ones who made slowness visible and someone’s job to prevent.

A prioritized checklist

If you do nothing else, work this list top to bottom and stop when you hit diminishing returns.

1. Pull field data and lab data for your highest-value pages.
2. Inventory third-party scripts; remove the dead ones and defer the rest.
3. Optimize the LCP image: format, size, dimensions, and preload it.
4. Self-host and subset fonts with font-display: swap.
5. Inline critical CSS and defer non-critical JavaScript.
6. Move static pages to pre-rendered, edge-served delivery.
7. Enable Brotli, long-lived caching, and HTTP/2 or HTTP/3.
8. Set a performance budget and enforce it in CI.
9. Monitor field data and alert on regressions.

Each step is ordered by typical impact-to-effort. Deleting weight beats tuning the rest; delivery beats micro-optimization; and process beats heroics over any horizon longer than a quarter.

Work with Urion Studio

Fast sites are an outcome of how they are built, not a layer applied afterward, which is why most lasting page speed work starts at the architecture and infrastructure level rather than the optimization pass. If your site has accumulated weight faster than you can cut it, or you want a build that is fast by default, that is exactly the kind of marketing infrastructure we build. Get in touch and we will start with your highest-value pages and the numbers that actually move the business.