Website performance needs monitoring, not one PageSpeed test

Start with a baseline

A PageSpeed test before launch is useful.

One test is not a monitoring system.

Websites change after launch.

• A new hero video arrives.
• A marketing script gets added.
• A chat widget appears.
• A team member uploads a heavy image.
• A custom code component changes.
• A new font gets introduced.
• A third party embed becomes slower.

None of those changes needs a full redesign to affect performance.

Save a baseline when the website goes live.

Use the important pages, not every URL.

• Homepage.
• Main service or product page.
• Pricing page where relevant.
• Main landing page.
• Contact or signup flow.
• One representative article or CMS page.

Run the same group again after meaningful website changes.

This gives the team a before and after comparison instead of a random score from one afternoon.

Measure the right signals

Google's Core Web Vitals focus on three parts of real user experience.

Largest Contentful Paint measures loading performance. Google's good threshold is 2.5 seconds or less.

Interaction to Next Paint measures responsiveness. Google's good threshold is under 200 milliseconds.

Cumulative Layout Shift measures visual stability. Google's good threshold is below 0.1.

Those metrics use real user data where enough Chrome field data exists.

Lighthouse serves a different purpose.

Lighthouse runs a controlled lab test. The report helps diagnose a page under a fixed test setup. Real user data reflects actual visitors across devices, networks, and locations.

Use both for different questions.

Field data asks how visitors experienced the page.

Lab data helps reproduce and investigate problems.

Search Console also groups Core Web Vitals issues across pages, which makes the report useful for trend review.

Do not chase a perfect Lighthouse number while ignoring the customer journey.

A page might score well in a lab and still create a poor real user experience on specific devices or networks.

A slow page might also come from a third party script outside the visible design.

Framer's current performance guidance calls out media, custom scripts, embeds, animations, shadows, blurs, and font loading as areas which affect site speed. Framer handles several performance tasks automatically, but content and integration choices still matter.

Keep a performance baseline

Create a small routine.

At launch: Save baseline PageSpeed and Core Web Vitals data where available. Confirm the main pages load correctly on mobile. Record major third party scripts. Check large media.

After a major publish: Run the same page group. Look for meaningful changes. Check whether a new asset or script lines up with the regression.

Monthly for an active site: Review Search Console Core Web Vitals. Check the most important pages. Review mobile separately. Check whether a new integration changed loading or interaction.

During a campaign or product launch: Watch the landing page more closely because paid traffic magnifies small technical problems.

The goal is not constant testing.

The goal is noticing regression before a client, customer, or search report becomes the first alert.

Performance belongs inside ongoing website ownership because the page keeps changing after the launch handoff.