How to Pass Core Web Vitals & Hit 90+ PageSpeed for Your Pittsburgh SaaS Website

If you run a SaaS company in Pittsburgh — or you’re a GoHighLevel agency building sites for one — Core Web Vitals aren’t a developer vanity metric. They’re the three numbers Google uses to decide whether your marketing site is fast enough to rank, and they map almost one-to-one to whether a paid click turns into a trial or a bounce. The good news: passing them is a solvable engineering problem, not luck. Google’s “good” thresholds are fixed — Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less (web.dev) — and there’s a repeatable path to hit all three and land a 90+ PageSpeed score.

This is the operator’s playbook: what each metric actually measures, the sourced revenue math behind why speed matters, why it bites harder for a Pittsburgh software team specifically, and the seven concrete fixes that get you there — plus the honest build-vs-buy call if you’d rather someone just ship it fast.

Table of contents

• The short answer
• What Core Web Vitals actually measure
• Why page speed is a revenue problem, not a vanity metric
• Why it bites harder for a Pittsburgh SaaS company
• The 7-step playbook to a 90+ PageSpeed score
• DIY vs done-for-you: the honest math
• What “good” looks like after you ship
• Frequently asked questions
• Sources
• About the author

The short answer

To pass Core Web Vitals and hit a 90+ PageSpeed score, you optimize for the three metrics Google actually measures — LCP (loading), INP (responsiveness), and CLS (visual stability) — at the 75th percentile of your real visitors, then remove the things that blow each one out: heavy JavaScript, oversized images, render-blocking resources, and layout that jumps as the page loads.

For most SaaS marketing sites the fastest durable win isn’t a plugin — it’s the architecture. A static-first site served from the edge (the approach the Astro framework is built around) ships mostly HTML and CSS with JavaScript loaded only where it’s genuinely needed, which is why it clears all three vitals with room to spare while a plugin-heavy WordPress, Wix, or page-builder site fights them on every release. You either commit an engineer to profiling and defending those numbers release after release, or you build on an architecture that makes them the default — or you hand the whole thing to a done-for-you Astro build that guarantees 90+ out of the box. What you can’t afford is a slow site that quietly bounces the paid clicks you already spent to earn.

What Core Web Vitals actually measure

Core Web Vitals are three field metrics Google tracks from real Chrome users, each with a fixed “good” threshold measured at the 75th percentile — meaning 75% of your visits have to clear the bar (web.dev). Here’s what each one is, in plain language.

LCP — Largest Contentful Paint (is the main thing visible fast?)

LCP measures how long it takes for the largest piece of content in the viewport — usually your hero heading, hero image, or the value-proposition block — to render. A good LCP is 2.5 seconds or less. This is the “did the page show up before I gave up” metric, and on a SaaS landing page it’s almost always dominated by an unoptimized hero image, a slow server response, or render-blocking scripts and fonts.

INP — Interaction to Next Paint (does it respond when I tap?)

INP measures responsiveness: when a visitor clicks, taps, or types, how long until the page visibly reacts. A good INP is 200 milliseconds or less. INP officially replaced First Input Paint (FID) as a Core Web Vital on March 12, 2024, and it’s stricter — it looks at every interaction, not just the first (web.dev). Heavy JavaScript is the usual culprit: a main thread busy running analytics, chat widgets, and page-builder scripts can’t paint a response to a tap.

CLS — Cumulative Layout Shift (does the page jump around?)

CLS measures visual stability — how much the layout unexpectedly shifts while loading. A good CLS is 0.1 or less. You’ve felt bad CLS: you go to tap a button, an image or ad loads above it, and the whole page lurches. It’s caused by images and embeds without reserved dimensions, late-loading fonts, and content injected after first paint.

Under half of mobile sites on the web currently pass all three Core Web Vitals (HTTP Archive Web Almanac 2024) — which means clearing them is genuinely a competitive edge, not table stakes.

Why page speed is a revenue problem, not a vanity metric

Speed isn’t an engineering nicety; it’s a conversion lever with a dollar figure attached. Google’s own mobile research found that 53% of mobile site visits are abandoned if a page takes longer than three seconds to load (Google, “The need for mobile speed”). And the probability of a bounce climbs steeply with every second of delay.

The conversion side is just as blunt. Portent’s analysis of more than 100 million pageviews found the highest conversion rates land in the 0-to-4-second window, and that a site loading in 1 second converts roughly three times higher than one loading in 5 seconds for B2B (Portent). Even sub-second gains pay: in the Deloitte and Google Milliseconds Make Millions study of 37 brands, a 0.1-second improvement in mobile speed lifted retail conversions by 8.4% and average order value by 9.2%, with travel conversions up 10.1% (Deloitte + Google).

There’s a search dimension too. Core Web Vitals are part of Google’s page-experience signals and are used by its ranking systems — in a limited way, alongside relevance (Google Search Central). So a slow site doesn’t just bounce the visitors you send it; it makes you harder to find in the first place. If organic is a pillar for you, this pairs directly with a SaaS SEO strategy for 2026.

Why it bites harder for a Pittsburgh SaaS company

Pittsburgh is no longer a legacy-industry town with a couple of startups; it’s a genuine software hub, which raises both the opportunity and the competitive bar. The Pittsburgh Technology Council’s State of the Industry report counts roughly 241,804 people employed across 9,059 tech establishments in southwestern Pennsylvania — about 19.6% of the regional workforce (Pittsburgh Technology Council). CBRE’s Scoring Tech Talent analysis has ranked Pittsburgh among the country’s notable tech-talent markets, with a pool of tens of thousands of tech workers and a strong value-for-cost profile (CBRE). Anchored by Carnegie Mellon’s engineering pipeline and homegrown software success stories like Duolingo — a publicly traded company headquartered right on Penn Avenue — the local buyer, hire, and partner pool is dense and unusually technical.

For a SaaS operator that cuts two ways:

1. Your buyers are technical and they notice. A Pittsburgh founder or engineering lead evaluating your product will feel a janky, slow marketing site as a signal about the product itself. In a market this software-literate, a sub-2.5-second, buttery site earns trust; a page that lurches and lags quietly loses it before the demo.
2. The talent to fix it in-house is contested and expensive. The same density that makes Pittsburgh attractive makes a skilled front-end/performance engineer costly to hire and keep. Most software teams here are better served by an architecture that makes speed the default — or by outsourcing the marketing site entirely — than by pulling a scarce engineer off the product roadmap to chase a PageSpeed score every sprint.

The demand is local and it’s discerning. A fast, Core-Web-Vitals-passing site is how you convert that scrutiny into booked demos instead of silent bounces.

The 7-step playbook to a 90+ PageSpeed score

Here’s the repeatable sequence we use to take a SaaS marketing site from failing to a 90+ score that passes all three vitals in the field. Work them in order — each step removes a class of problem the next one builds on.

Step 1 — Measure the right way

Start with PageSpeed Insights and read the field data (CrUX) section first, not just the lab score. Note which vital is failing and on which device class — most SaaS sites pass on desktop and fail on mobile. Establish a baseline for LCP, INP, and CLS at the 75th percentile so you can prove the fixes worked.

Step 2 — Fix LCP: make the main content render first

Ship a static-first page so the HTML arrives ready to paint instead of waiting on JavaScript to build it. Serve a properly sized, modern-format hero image (AVIF or WebP), preload it and your primary font, and eliminate render-blocking CSS/JS above the fold. On most sites this single step moves LCP under 2.5 seconds.

Step 3 — Fix CLS: reserve space so nothing jumps

Set explicit width and height (or an aspect-ratio box) on every image, video, and embed so the browser reserves the space before they load. Preload web fonts and use font-display: swap with a matched fallback to stop the text reflow. Never inject banners or content above existing content after first paint.

Step 4 — Fix INP: cut and defer the JavaScript

INP is a JavaScript problem. Audit every third-party script — chat widgets, analytics, A/B tools, page-builder runtime — and remove what you don’t need. Defer or lazy-load the rest so the main thread is free to respond to taps. This is where a static-first architecture wins structurally: it ships far less JavaScript to begin with.

Step 5 — Serve from the edge

Host on a global CDN / edge network (Cloudflare Pages, for example) so your pages are delivered from a node near the visitor rather than one origin server. Edge delivery plus HTTP/2 or HTTP/3 and long-lived caching cuts the network latency that inflates LCP — especially for mobile visitors on cellular.

Step 6 — Right-size every asset

Compress and convert images to AVIF/WebP, lazy-load anything below the fold, subset fonts to the characters you actually use, and strip unused CSS and JS. Asset weight is the quiet killer of mobile scores; a lean page is a fast page.

Step 7 — Re-measure on field data and defend it

Speed regresses the moment someone adds a tracking pixel or a heavy embed. Re-run PageSpeed Insights, confirm the field data has moved, and put a guardrail in place — a performance budget or a monitor — so the next marketing change doesn’t quietly push you back over the thresholds.

DIY vs done-for-you: the honest math

You have two real options, and both can work. Build and defend the speed in-house, or hand the marketing site to a team that guarantees the score. Here’s the comparison we walk Pittsburgh founders through:

The point isn’t that in-house is wrong — a team with a spare performance engineer can absolutely hit and hold these numbers. It’s that for most Pittsburgh SaaS companies and the agencies serving them, a done-for-you Astro build at $137/month plus a one-time fee ships a guaranteed 90+ site without pulling anyone off the product, and keeps it fast as you add pages. If you’re weighing platforms first, the Astro vs GoHighLevel breakdown lays out the trade-offs.

What “good” looks like after you ship

A healthy SaaS marketing site isn’t just green on launch day — it stays green. After you ship, “good” looks like this: PageSpeed Insights shows a 90+ score on mobile and desktop, and the CrUX field data reads “Good” on all three vitals — LCP at or under 2.5 s, INP at or under 200 ms, CLS at or under 0.1 — for 75% of real visits. Your hero renders before a visitor can lose patience, taps respond instantly, and nothing jumps as the page settles.

Then watch the number that pays the bills: the share of paid and organic clicks that reach your trial or demo form instead of bouncing. Speed is upstream of conversion, so a faster site should show up as a lower bounce rate and more form starts within weeks. To make sure those faster-arriving signups actually activate, wire them into a tight time-to-value onboarding flow and cut the friction that causes demo no-shows. A fast site fills the top of the funnel; the lifecycle behind it is what turns those trials into MRR.

Frequently asked questions

Sources

• web.dev — Core Web Vitals
• web.dev — Defining the Core Web Vitals metrics thresholds
• web.dev — INP is a Core Web Vital (March 12, 2024)
• Google — The need for mobile speed (53% mobile abandonment)
• Google / SOASTA — New Industry Benchmarks for Mobile Page Speed
• Portent — Site Speed Is (Still) Impacting Your Conversion Rate
• Deloitte + Google — Milliseconds Make Millions
• Google Search Central — Understanding page experience in Google Search
• HTTP Archive — Web Almanac 2024, Performance
• Pittsburgh Technology Council — State of the Industry
• CBRE — Pittsburgh in Scoring Tech Talent

About the author

Devon Asante is a GHL Automation Architect based in Denver, CO. A former agency operator who resold GoHighLevel to software clients, he now designs snapshot systems and fast, static-first marketing sites that drop in clean and fire on day one. He’s happiest documenting a build so clearly that a non-technical founder can ship it before lunch.

Related reading: Astro vs GoHighLevel Websites for SaaS · Astro vs WordPress for SaaS · SaaS SEO in 2026 · Time-to-Value for SaaS · Reduce SaaS Demo No-Shows