Website performance and Core Web Vitals check

A slow page loses visitors before they see anything. This page explains the Core Web Vitals thresholds, what a browser-based performance check can tell you, and a test task your AI beta tester can run on your key pages.

Who it’s for

  • Marketers and founders whose landing pages feel slow
  • Developers who added scripts, images or a new framework
  • Store owners worried about mobile load times
  • Teams preparing for a launch or a big campaign

Updated 2026-10-19.

What a performance check is (and is not)

A website performance check loads your pages in a real browser and looks at how fast they become visible and usable, which requests are slow or heavy, and whether the layout jumps around. It is not load testing: it does not simulate thousands of visitors or stress your servers. For capacity testing, use dedicated load testing tools on infrastructure you control.

Slow pages are a quiet kind of bug. Nothing is broken, but visitors wait, tap twice, or leave before the page is ready. Adding a performance check to each beta test catches the new heavy image or extra script while it is still easy to remove.

Core Web Vitals in plain words

Google's Core Web Vitals are a common way to measure page experience. The "good" thresholds are:

  • LCP (Largest Contentful Paint): the main content appears within 2.5 seconds.
  • INP (Interaction to Next Paint): the page responds to clicks and taps within 200 milliseconds.
  • CLS (Cumulative Layout Shift): layout shift score of 0.1 or less, so things do not jump while loading.

One test run is a snapshot from one location and connection. Real-user data (for example in Google Search Console or your own monitoring) shows what your visitors actually experience over time. Use a check like this to find causes, and field data to confirm improvements.

How to run a website performance check

  1. Pick the pages that matter: home, the main landing pages, pricing, signup and the heaviest page in your app.
  2. Load each page fresh, with the cache cleared, and note when the main content appears and when the page is usable.
  3. Open the network list and sort by size and by time to find the largest files and the slowest requests.
  4. Watch the page load and note anything that moves after it first appears.
  5. Click the main buttons right after load and note any delay before something happens.
  6. Repeat on a mobile viewport, where slow pages hurt most.
  7. Read the console for errors that block scripts.
  8. Write each finding with the exact resource, its size or timing, and a suggested fix.

Performance checklist

Loading

  • The hero image or main heading appears quickly, without waiting for every script.
  • Images are compressed, sized for how large they are displayed, use modern formats and lazy-load below the fold.
  • CSS and fonts are not blocking the first paint longer than needed.
  • The server responds quickly to the first request; uncached pages and slow APIs show up as a long wait before anything arrives.

Scripts and third parties

  • JavaScript bundles are not much larger than the page needs.
  • Chat widgets, trackers and A/B testing tools load after the main content.
  • No script errors in the console stop parts of the page from working.

Stability and responsiveness

  • Images and embeds have set dimensions so nothing jumps when they load.
  • Late banners, cookie notices and font swaps do not push content down.
  • Buttons respond right away after load, not after a frozen second.

Requests

  • No 404s for assets, no redirect chains, no mixed content on HTTPS pages.
  • The same file is not downloaded twice.

Example bug report

Title: Home page hero image is 3.8 MB and delays main content on mobile
Environment: Chrome 129, phone-width viewport (390px), cache cleared
Page: /
Steps to reproduce:
1. Open the home page with an empty cache at 390px wide
2. Watch the network list sorted by size
Expected: main heading and hero visible within about 2.5 s (LCP "good")
Actual: hero.jpg is 3.8 MB at 2400px wide, displayed at 390px; it is the
        largest element and appears last. A chat widget script also loads
        before the hero and blocks rendering.
Severity: Medium (page works but feels slow on the most visited page)
Suggested fix: serve resized, compressed images per width in a modern
               format; load the chat widget after the page

Common mistakes

  • Testing only on a fast office connection with a warm cache.
  • Chasing a perfect lab score instead of fixing the biggest real causes.
  • Optimizing a rarely visited page while the home page carries the heavy image.
  • Adding third-party scripts without checking what they cost.
  • Confusing a performance check with load testing, and expecting it to show how the server behaves under heavy traffic.

What to fix first

  1. Anything that breaks or blocks: script errors, failed requests and pages that freeze on interaction.
  2. The biggest single causes on high-traffic pages: oversized images, render-blocking scripts, slow server responses.
  3. Layout shifts that make people tap the wrong thing.
  4. Smaller savings: minor bundle trimming, caching tweaks and font loading details.

Turning results into fixes

Good findings name the exact resource and the fix: "hero.jpg is 3.8 MB at 2400px wide but displayed at 1200px, compress and resize it", or "the chat widget script blocks rendering, load it after the page". Prioritize fixes on the pages with the most traffic and the most revenue.

Doing it manually vs with an AI beta tester

Running a lab tool on one page is quick. Turning the numbers into specific fixes, and repeating it across key pages after every release, is the part that tends not to happen.

An AI beta tester like betatest.ing loads your key pages in a real browser, reviews the slowest and heaviest requests, watches for layout shifts and console errors, and writes findings that name the resource and the likely fix, with screenshots and recordings. Scheduled runs make it a regression check, so a new oversized image shows up soon after it ships. It never runs load or stress tests against your site.

Honest limits: a single run can't reproduce every visitor's network, device and location, and it does not replace real-user monitoring or field data. Use it to find and fix causes, and confirm the results with data from your actual visitors.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Check the performance of [SITE URL] in the browser on these pages: [PAGES TO CHECK]. For each page, load it fresh and note when the main content appears and when the page responds to the first click, estimate LCP, INP and CLS against the good thresholds (2.5 s, 200 ms, 0.1) where you can measure them, and look at the network requests: list the largest files, the slowest requests, failed requests, redirects and third-party scripts that load before the content. Note images that are much bigger than their display size or not lazy-loaded, layout shifts while loading, and console errors (call logs). Repeat the main page at mobile width. Do not run load tests or send repeated requests. Log each problem with the page, the exact resource and a suggested fix, with an annotated screenshot where useful, and end with a report that scores each page and lists the 5 fixes likely to help most.

Fill in your details

Here, or later in the chat with your tester.

  • [SITE URL] Your website, e.g. https://example.com
  • [PAGES TO CHECK] e.g. "home, pricing, a product page and the blog index"

What the AI beta tester checks

  • Time until main content is visible and the page is usable
  • LCP, INP and CLS against the good thresholds where measurable
  • Largest files and slowest requests
  • Oversized or non-lazy-loaded images
  • Render-blocking and third-party scripts
  • Layout shifts during loading
  • Failed requests, redirects and console errors
  • The main page at mobile width

What you get

  • A per-page performance summary with scores
  • The exact resources slowing each page, with suggested fixes
  • Annotated screenshots of layout shifts and heavy elements
  • The 5 fixes likely to help most, ranked

How to run it with betatest.ing

  1. Add your site as a project
  2. Paste the task and list your most important pages
  3. Send it; the tester loads each page in a real browser and inspects requests
  4. Apply the top fixes and confirm with field data over the following weeks

Tips

  • Fix images first: they are often the biggest and easiest win
  • Audit third-party scripts and remove the ones nobody uses
  • Always set width and height on images and embeds to prevent layout shifts
  • Schedule the check after each release so new scripts do not slip in unnoticed

Website performance check: FAQ

Is this a load test?

No. It loads pages like a single visitor in a real browser. It does not simulate traffic or stress your servers.

Why do my scores differ from PageSpeed Insights?

Lab tests depend on location, device, connection and caching, so numbers vary between tools and runs. Use them to find causes and compare before and after, and use real-user data to judge what visitors experience.

What are good Core Web Vitals?

LCP within 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, measured at the 75th percentile of real visits.

Does performance affect SEO?

Page experience, including Core Web Vitals, is one of many signals search engines consider. A faster page also simply keeps more visitors.

What slows down a website the most?

The usual culprits are oversized images, too much JavaScript (often third-party widgets and trackers), render-blocking CSS and fonts, and slow server responses. Layout shifts from images without dimensions make a page feel worse even when it loads quickly. A check that names the specific heavy or slow resources tells you where to start.

Which pages should I check for performance first?

Start with the pages that get the most traffic and the ones closest to revenue: the home page, main landing pages, pricing, signup and checkout. Then add the heaviest page in your app. A fix on a high-traffic page helps far more visitors than the same fix on a rarely visited one.

How often should I run a website performance check?

Check before launch and after any release that adds images, scripts, fonts or third-party tools. Scheduling a regular run catches slow creep, where each small addition seems harmless until the page is noticeably slower.

Related beta testing guides

  • Broken links checker — Broken links and JavaScript errors are cheap to fix and expensive to leave: they break flows, hurt trust and waste crawl budget. This page shows what to collect, how to group it, and a task your AI beta tester can run across your site.
  • Landing page testing — A landing page has one job: make a visitor understand the offer and take the next step. Testing it means checking both that it works and that it is clear. This page covers what to check on a landing page before you send traffic to it, and a task your AI beta tester can run.
  • Smoke testing — A smoke test is a short, shallow test that answers one question: is this build working well enough to use and test further? It takes minutes, and it is the first thing to run after any deploy.
  • Website beta testing — A website beta test is a run-through of your site by someone who has never seen it, before real visitors do. This guide covers what breaks most often on marketing and content sites, how to set up the test, and a ready-to-run task your AI beta tester can start on right now.
  • Free tool: Free website test — Enter a URL, get an instant report: SEO basics, mobile, security headers, broken links and a score.

More in by test type