Website Speed Optimization: Improve Core Web Vitals, Performance & Load Time

A business checks PageSpeed Insights and sees a mobile score of 42 and a desktop score of 88. The immediate reaction is usually the same: the website must be broken. But that single number does not say what users actually experience, whether real-world field data is even available, which specific metric is failing, or whether the underlying cause is images, JavaScript, hosting, third-party scripts, layout instability, slow API calls, or something else entirely.

Website performance is not one number. A fast website is the result of several things working together: reasonable architecture, efficient delivery, optimized assets, hosting that fits the workload, responsible use of third-party tools, and ongoing measurement after launch—not a one-time fix applied before things quietly drift backward again.

This guide exists to help you diagnose the real bottleneck before applying random optimization techniques. It covers how to test a website correctly, how Core Web Vitals actually work, the most common causes of slow performance, and how to decide whether the fix belongs to your content team, your developer, or a dedicated performance project.

Why Website Speed Matters

Speed affects more than a single metric. Visitors form an impression of a website within the first few seconds, and a slow or unstable page can make an otherwise well-designed business look unreliable before a visitor reads a single word of content. On mobile connections in particular, delay compounds: a slow server response pushes back every resource that depends on it.

Search systems also consider page experience signals as part of a much larger set of ranking factors, which means performance can support—but never replace—strong, relevant content. Crawling efficiency benefits too: a faster, more stable site is generally easier for search engines to process at scale.

The most useful way to think about speed is as a support for business outcomes—completed forms, finished checkouts, read content, booked appointments—rather than as a vanity score to chase for its own sake. A team that optimizes toward real user tasks tends to make better decisions than one optimizing purely toward a number in a report.

How to Test Website Speed Correctly

No single tool tells the whole story, because each one measures something slightly different. A reliable performance review typically combines at least one field-data source with a lab-testing tool, checked on both mobile and desktop.

Google PageSpeed Insights

Available at pagespeed.web.dev, this is usually the fastest way to get a combined view of field data (when available) and a lab-based Lighthouse audit for a single URL.

Lighthouse

Lighthouse runs a simulated, controlled test of a page and returns a detailed diagnostic report with specific opportunities for improvement. It is built into Chrome DevTools and also powers the lab-data portion of PageSpeed Insights. Chrome Developers' Lighthouse documentation covers what each audit category actually measures.

Chrome DevTools Performance Panel

For a hands-on, technical look at exactly what happens during a page load—which scripts run, how long they take, and where the main thread is busy—the DevTools Performance panel gives a level of detail beyond what an automated report can summarize.

Chrome UX Report (CrUX)

CrUX aggregates real-user experience data collected from Chrome users across the web, and is the underlying source for the field data shown in PageSpeed Insights and Search Console.

Search Console Core Web Vitals Report

This report shows field data across an entire site, grouped by similar page types, which makes it useful for spotting a template-wide problem rather than a single page’s issue.

Real User Monitoring (RUM)

A first-party RUM setup collects performance data directly from your own site’s actual visitors, continuously, which is the most direct way to know what people are experiencing right now rather than in a monthly aggregate.

Field Data vs. Lab Data

These two categories answer different questions, and confusing them is one of the most common sources of frustration when a PageSpeed test does not match what a business believes about its own website.

Field Data

Field data comes from real users, on their real devices, over their real network conditions, typically aggregated over the previous 28 days through the Chrome UX Report. It reflects lived experience rather than a single simulated test, which also means it lags behind recent changes—a fix deployed yesterday will not be reflected in today’s field data yet.

Lab Data

Lab data comes from a controlled test environment—a specific device profile, a specific simulated network speed, run at a specific moment. It is extremely useful for diagnosis because it is repeatable and detailed, but it is a simulation, not a guarantee of what every real visitor experiences.

This is also why a PageSpeed test run today does not necessarily match what users experienced over the last month: the field score reflects the past, while the lab score reflects this one moment, under this one simulated condition.

What Are Core Web Vitals?

Core Web Vitals are a set of user-experience metrics that focus on three specific dimensions of a page’s quality: how quickly the main content loads, how quickly the page responds to interaction, and how visually stable the page remains while it loads. They are not the only performance metrics that matter, but they were selected because they map closely to what people actually notice and care about. web.dev's Core Web Vitals guidance maintains the current, authoritative definitions and thresholds for each metric.

The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). INP replaced the earlier First Input Delay (FID) metric as a Core Web Vital, so any guidance built around FID as a current metric should be treated as outdated.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible content element—typically a hero image, a large headline, or a prominent content block—to render within the viewport. It approximates when a visitor feels the page has actually loaded its main content, as opposed to when the browser technically finished processing the page.

Common LCP elements include a hero or featured image, a large block of headline text, or, on content-heavy pages, the first substantial paragraph or media block. Whatever that element is on a given template, it deserves specific attention rather than generic page-wide fixes.

Typical causes of a slow LCP include a slow server response delaying everything that follows, an oversized or unoptimized hero image, render-blocking resources that delay the browser from painting anything, the LCP element being rendered only after client-side JavaScript executes, and delay introduced by third-party scripts competing for the same bandwidth and processing time.

Practical improvements usually include correctly sizing and compressing the LCP image, marking it as a high-priority resource rather than lazy-loading it, removing unnecessary render-blocking CSS or JavaScript above the fold, and improving the server response time that everything else depends on.

Interaction to Next Paint (INP)

INP measures how responsive a page feels throughout a visit, not just on the very first interaction. It looks at the delay between a user action—clicking a menu, opening an accordion, submitting a form, changing a filter—and the moment the browser visibly responds to it.

A page can feel sluggish even after it has finished loading if interactions themselves are slow to register. This is often caused by long JavaScript tasks that block the main thread, heavy event handlers attached to common interactions, excessive hydration work in client-rendered frameworks, and third-party scripts running expensive code at the exact moment a user tries to interact with the page.

It is worth being clear that INP is not simply about how fast a single click registers—it reflects the full range of interactions across a session, which means a page can have one very fast interaction and one very slow one, and the slow one is what tends to define the user’s actual impression of responsiveness.

Cumulative Layout Shift (CLS)

CLS measures how much visible content unexpectedly shifts position while a page loads or while a user is interacting with it. A low score means the page stays visually stable; a high score means elements jump around in ways that can cause a visitor to click the wrong thing entirely.

Common causes include images or embeds that load without reserved dimensions, an advertisement or banner injected after the surrounding content has already rendered, a web font swap that changes text size and reflows the layout, and third-party widgets that insert themselves into the page after it initially appears stable.

The fix in each case follows the same underlying principle: reserve space for content before it arrives, whether that is setting explicit width and height (or aspect ratio) on images and embeds, choosing a font-loading strategy that minimizes reflow, or being deliberate about where and when dynamically injected content is allowed to appear.

Core Web Vitals Are Not the Same as Your PageSpeed Score

The Lighthouse performance score shown in PageSpeed Insights and Core Web Vitals field data are related but distinct things, and treating them as interchangeable leads to confusion. The Lighthouse score is a lab-based composite calculated from one simulated run under one set of conditions, and it can vary somewhat between consecutive tests of the exact same page due to normal variability in test conditions. Core Web Vitals field data, by contrast, represents accumulated real usage over time.

None of this makes the PageSpeed score irrelevant—it remains one of the most useful diagnostic tools available, precisely because it is detailed and repeatable. The distinction matters because the score should be treated as a starting point for investigation, not as the final measure of whether a website is actually fast for the people using it.

Why Is Mobile PageSpeed Lower Than Desktop?

It is common—almost universal—for a website’s mobile score to be noticeably lower than its desktop score, and this alone is not evidence that something is broken. Mobile lab tests simulate a mid-range device with deliberately throttled CPU performance and a slower, higher-latency network connection, specifically to approximate a more demanding real-world scenario than most desktop testing setups.

Several factors widen this gap further: the same JavaScript that runs quickly on a fast desktop CPU can take meaningfully longer on a throttled mobile profile, responsive images intended to reduce mobile payload are not always implemented correctly, mobile-specific layout and navigation patterns can introduce their own overhead, and third-party scripts execute at the same absolute cost regardless of how much slower the surrounding device is.

A lower mobile score does not automatically mean mobile visitors are having a broken experience, but given how much traffic arrives on mobile devices, it should always be investigated rather than dismissed as an artifact of the testing methodology.

15 Common Causes of a Slow Website

These causes rarely appear in isolation—most slow websites suffer from a combination of several at once, which is exactly why measuring before optimizing matters.

Image Optimization

Because images so often dominate page weight, getting them right delivers some of the largest performance gains available for the least implementation risk. Effective image optimization combines several practices rather than relying on any single one.

Serve images at the dimensions they will actually be displayed at, not the original upload size scaled down by CSS. Apply real compression rather than relying on a default export setting. Use responsive images—typically through srcset and sizes, as explained in MDN's guide to responsive images—so different devices receive an appropriately sized file rather than the same large image regardless of screen size. Choose a modern format where practical, and always set explicit width and height (or an aspect-ratio) so the browser can reserve space before the image arrives, preventing layout shift.

Lazy loading is valuable for images below the fold, since it defers work the browser does not need to do immediately. It should not be applied to the LCP image or other above-the-fold content, where deferring the load directly delays the metric that matters most.

WebP vs. AVIF vs. JPEG vs. PNG

JavaScript Performance Optimization

JavaScript is often the biggest contributor to slow interactivity because its cost is paid in three stages: downloading the file, parsing it, and executing it. A bundle that looks reasonably sized can still cause a slow experience if much of it runs before the browser can respond to the user.

Code splitting—loading only the JavaScript a given page or interaction actually needs, rather than one large bundle for the entire site—is one of the most effective structural improvements available. Lazy loading non-critical components, removing genuinely unused code, auditing large dependencies for lighter alternatives, and reducing the amount of work done during hydration in client-rendered frameworks all address different parts of the same underlying problem: too much JavaScript running before it is actually needed.

Long-running tasks on the main thread are a particularly direct cause of poor INP, since the browser cannot respond to user input while it is busy executing a script. Breaking up large tasks, deferring non-urgent work, and being deliberate about which third-party scripts are allowed to run early in the page lifecycle all help keep the main thread available for what the user is actually trying to do.

None of this is purely a developer concern—the business decision to add another marketing script, another widget, or another tracking pixel is often exactly where the JavaScript weight originates.

CSS Performance

CSS is smaller than JavaScript in most cases, but it can still block rendering: browsers generally wait for stylesheets to load before painting content, to avoid a flash of unstyled page. Unused CSS—rules that apply to components no longer on the page, or styles imported from a framework but never used—adds weight without adding value.

Reducing this impact usually means trimming genuinely unused styles, avoiding multiple sequential stylesheet requests where they can be consolidated, and being thoughtful about how much of a large CSS framework is actually needed for a given project. Extracting and inlining the small amount of CSS required to render visible above-the-fold content can help in some cases, though it adds build complexity and is not something every project needs to implement manually.

Web Font Optimization

Fonts affect both loading speed and visual stability. Loading many font weights and styles when only a few are actually used adds unnecessary download weight, and fonts served from a slow or distant third-party source can delay text from appearing altogether.

Useful practices include limiting the number of font files and weights actually loaded, using appropriate character subsets rather than a full font family when only certain characters are needed, choosing a sensible font-display strategy so text remains visible while a custom font loads, preloading a critical font file when it is genuinely essential to early rendering, and weighing the tradeoffs between self-hosting fonts and loading them from an external provider. In some cases, a well-chosen system font avoids the cost of a custom font entirely.

Third-Party Scripts: The Hidden Performance Cost

Analytics platforms, tag managers, chat widgets, heatmap and session-recording tools, advertising pixels, and social embeds are common on business websites for good reason—they support real marketing, support, and measurement needs. But each one adds its own JavaScript, its own network requests, and sometimes its own layout shifts, and that cost is paid by every visitor regardless of whether they interact with the tool.

The right question is rarely “should we delete our analytics,” which can cost more in lost visibility than the performance gain is worth. The right question is whether each script currently running still earns its place, is implemented efficiently, and is not duplicated across multiple tools measuring the same thing.

Google Tag Manager and Website Performance

Google Tag Manager itself is a lightweight container script—it is not automatically the source of a performance problem. The issue is usually what accumulates inside it over time: tags for campaigns that ended months ago, duplicate analytics implementations installed by different people at different points, and triggers configured to fire more often than necessary.

A periodic tag audit—reviewing what is actually installed, what it is used for, and whether it is still needed—often recovers meaningful performance without removing any tool that is still providing real value.

Caching Explained

Caching means storing a copy of content so it does not need to be regenerated or re-downloaded on every request. Several layers of caching exist, and an effective strategy usually uses more than one.

Browser Caching

Instructs a visitor’s browser to reuse a previously downloaded file—an image, a script, a stylesheet—instead of requesting it again on a repeat visit.

CDN Caching

Stores copies of static assets on servers distributed closer to visitors geographically, reducing the distance—and therefore the time—data has to travel.

Server or Application Caching

Stores the result of an expensive operation—a rendered page, a database query result—so it does not need to be recomputed on every single request.

Data and API Caching

Stores the response from an API call or data lookup for a period of time, reducing repeated calls for information that does not change on every request.

Every caching layer introduces a tradeoff between freshness and speed. Content that must always reflect the latest state—live inventory counts, account balances—may need shorter cache durations or no caching at all, while content that changes rarely can be cached aggressively with real performance benefit and minimal risk.

Does a CDN Make a Website Faster?

Often, yes, for the specific problem it solves: delivering static assets—images, stylesheets, scripts, fonts—from a location closer to the visitor, which reduces network latency, and absorbing traffic spikes more gracefully than a single origin server.

What a CDN cannot do is fix a slow backend, compensate for an oversized JavaScript bundle, shrink an unoptimized image before it is cached, or speed up a slow database query. A CDN is a genuinely valuable piece of the delivery chain, not a substitute for addressing the underlying causes of slow performance elsewhere in the stack.

Hosting and Server Performance

Hosting affects performance primarily through how quickly a server can generate and return a response, and how well it holds up under real traffic conditions. Relevant factors include the physical or logical location of the server relative to the audience, the compute and memory resources available to handle requests, whether database queries are efficient, whether server-side caching is configured, whether the hosting model is traditional, managed, or serverless, and how the site behaves under realistic traffic rather than only under light load.

“Upgrade your hosting plan” is a common but often incomplete answer. A larger server can mask an inefficient application for a while, but it does not fix an unindexed database query, unnecessarily large API payloads, or code that does more work than the task actually requires. Hosting is one legitimate factor among several, not the default first fix.

Time to First Byte (TTFB)

TTFB measures how long it takes for a browser to receive the first byte of a response after making a request. It reflects server processing time, network latency, and any redirects along the way, and it sets the floor for every loading metric that follows—nothing else on the page can begin until the first byte arrives.

TTFB is not itself a Core Web Vital, but a slow TTFB directly delays LCP and every other loading metric downstream of it, which makes it worth measuring even though it is not one of the three headline metrics.

WordPress Speed Optimization

WordPress is not inherently slow. A properly configured WordPress website—clean theme, reasonable plugin selection, correct caching, and optimized media—can perform well and pass Core Web Vitals comfortably. Performance problems on WordPress sites usually come from accumulated configuration issues rather than the platform itself.

Common areas worth reviewing include hosting quality (shared hosting under real traffic is a frequent bottleneck), theme complexity and whether it loads resources the site does not actually use, the number and quality of installed plugins, whether images are compressed and correctly sized on upload, database health as content and revisions accumulate over years, whether page and object caching are properly configured, whether a page builder is generating excessive markup and CSS, whether third-party scripts have accumulated unreviewed, and whether core, theme, and plugins are kept reasonably current.

A useful practice for any WordPress site is a periodic plugin audit: disabling and removing anything no longer actively used, checking for overlapping functionality between plugins, and confirming that caching and image optimization are actually configured rather than assumed to be working by default.

Next.js Website Performance

Next.js provides tools that can support strong performance, but the framework itself does not automatically make a website fast—how it is used determines the outcome. Server Components can reduce the amount of JavaScript shipped to the browser for content that does not need client-side interactivity, while client components remain appropriate for genuinely interactive parts of the interface.

Built-in image optimization can handle resizing and modern format delivery automatically when used correctly, and font optimization features can reduce layout shift caused by web fonts. Rendering strategy—static generation, server rendering, or a mix depending on the page—should be chosen based on how often content changes and how it needs to be discovered, not applied uniformly across an entire site. As with any framework, JavaScript bundle size and third-party script usage still need active management; choosing Next.js does not exempt a project from the same discipline required anywhere else. Next.js's own performance documentation covers these tools in more technical detail than a business-focused guide needs to.

E-Commerce Website Performance

E-commerce sites face more performance pressure than most other website types, because they typically combine large product image catalogs, search and filtering functionality, product recommendation widgets, multiple analytics and advertising scripts, a payment provider integration, and live inventory data, often all on the same pages that matter most for revenue.

Product listing and detail pages deserve particular attention to image optimization given how many images they typically display. Search and filter interactions should be evaluated for responsiveness, since these are exactly the interactions INP measures. Recommendation widgets and reviews are often third-party embeds worth auditing for their real performance cost. Checkout flows deserve special care: this is the point where slow performance most directly costs revenue, and where payment provider and inventory API response times become part of the customer’s experience rather than a background technical detail.

Website Builder Performance

Platforms like Wix, Squarespace, Webflow, and Shopify each operate within their own technical constraints, and some performance ceiling exists that cannot be engineered around from within the platform. That said, configuration and content decisions still account for a meaningful share of the performance difference between two sites built on the same platform.

Within these limits, image sizing and compression, the number of third-party apps or embeds installed, animation and interaction-heavy design choices, and the amount of custom code added to a template all remain within the site owner’s control. A thoughtfully built site on a website builder can meaningfully outperform a carelessly built one on the exact same platform.

Server-Side Rendering vs. Client-Side Rendering

These two approaches have different performance implications, and neither is universally faster. Server-side rendering sends a fully or partially rendered page to the browser, which tends to help initial content appear sooner and can benefit public, discoverable content where fast first paint and easy indexing matter.

Client-side rendering sends a smaller initial payload and builds the page in the browser using JavaScript, which can work well for highly interactive, authenticated experiences where the content is less about discovery and more about ongoing interaction. Many modern applications use a hybrid approach—rendering some content on the server for fast, discoverable initial loads, while handling interactive sections on the client—rather than committing entirely to one model.

Lazy Loading: What Should and Should Not Be Lazy Loaded?

Lazy loading defers loading a resource until it is actually needed, which is valuable for reducing initial page weight—but only for the right content.

Below-the-fold images are generally good candidates for lazy loading, since the visitor has to scroll before they become visible anyway. The same applies to heavy embeds like video players, maps, and social widgets further down a page. The hero image or other Largest Contentful Paint element should almost never be lazy-loaded, since doing so directly delays the metric that most affects perceived loading speed. Content immediately visible on page load, regardless of type, generally should not be deferred.

Website Speed and SEO

Page experience, including Core Web Vitals, is one of many signals search systems consider, but it exists alongside—not instead of—content relevance and quality, which remain critical. A technically fast page built around thin or irrelevant content will not outrank a slower page that better answers what someone actually searched for.

The more accurate framing is that speed removes a potential disadvantage rather than guaranteeing an advantage: a genuinely slow, unstable experience can hold back an otherwise strong page, while good performance clears the way for content quality to matter as it should. Businesses evaluating this tradeoff can review Google Search Central's documentation on page experience and ranking systems directly rather than relying on secondhand claims about exactly how much weight speed carries.

Website Speed and User Experience

Beyond search visibility, speed shapes how a visitor experiences a business directly. A delayed response to a tap or click reads as unresponsiveness, even when the underlying action is technically still processing. On mobile devices in particular, where attention spans and patience for delay tend to be shorter, slow or unstable pages can interrupt a task before it is completed—an abandoned form, an unfinished checkout, a closed tab.

None of this needs invented statistics to be a reasonable business concern: a visitor who cannot complete the task they came to do, because the page felt slow, unstable, or unresponsive, represents a real and avoidable loss regardless of the exact percentage involved.

Performance vs. Accessibility

These are related but distinct concerns that often improve together. Semantic HTML, reduced page complexity, responsible use of animation, and thoughtful responsive design tend to benefit both performance and accessibility at the same time, since both disciplines reward simplicity and clarity over unnecessary complexity.

They are not interchangeable, however: a fast page can still be inaccessible to a keyboard or screen-reader user, and a highly accessible page can still be slow if it is burdened with heavy scripts or oversized media. Teams that treat them as separate, deliberate workstreams tend to get better results in both than teams that assume solving one automatically solves the other. The W3C's introduction to web accessibility is a useful starting point for teams building out that separate workstream.

Website Speed Optimization Tools

Beyond the testing tools already covered for diagnosis, a few additional tools are worth knowing by name when discussing a performance project with a developer.

• WebPageTest — advanced, highly configurable lab testing across real device and network combinations, useful for deeper diagnostic work beyond what Lighthouse alone provides.
• Search Console — site-wide field data grouped by page type, useful for spotting template-level issues rather than one-off page problems.
• Chrome UX Report (CrUX) — the underlying real-user dataset behind the field data shown in several of these tools.
• Real User Monitoring (RUM) platforms — first-party, continuous performance data collected directly from your own site’s visitors.

No single tool replaces the others; a combination of a quick PageSpeed Insights check, a deeper Lighthouse or WebPageTest audit when something specific needs diagnosis, and ongoing field-data review is a reasonable baseline for most businesses.

Website Performance Monitoring

A single audit answers the question “how is this page performing right now,” but it says nothing about next month, after the next content update, or after the next plugin install. A website performance monitor—whether a dedicated RUM tool, a scheduled Lighthouse check, or a recurring review of the Search Console Core Web Vitals report—closes that gap by catching regressions while they are still small.

At minimum, ongoing monitoring should track Core Web Vitals trends over time, flag meaningful performance regressions after deployments, watch for uptime and error-rate issues that affect the same pages being optimized for speed, and keep an eye on API latency where pages depend on external or internal data. Treating performance as a one-time project rather than an ongoing responsibility is one of the most common reasons a well-optimized site quietly becomes slow again within a year.

Performance Budgets

A performance budget sets an explicit limit on a specific resource or metric—for example, a maximum JavaScript bundle size, a maximum total image weight for a template, or a maximum acceptable LCP time—and treats exceeding that limit as a problem to be addressed before a page ships, rather than something to notice after the fact.

The specific numbers should reflect a given project’s actual audience, typical devices, and network conditions rather than a generic industry rule, but the underlying discipline—deciding in advance what “acceptable” looks like, and treating that as a real constraint on new features and content—is valuable regardless of where the exact limits are set.

Common Website Speed Optimization Mistakes

Website Speed Optimization Checklist

When Do You Need Website Speed Optimization Services?

Not every performance problem requires outside help, and not every business needs a dedicated project to see meaningful improvement.

DIY effort is often enough when the problem is a clearly identifiable, isolated issue—a handful of oversized images, a website builder's built-in optimization settings left unconfigured, or a straightforward plugin cleanup on a simple site.

Professional website speed optimization services tend to make more sense when Core Web Vitals consistently fail across a site despite basic fixes, the JavaScript architecture itself needs restructuring rather than trimming, the application is custom-built and the bottleneck is in application code, database queries, or API design, hosting and backend performance are suspected but nobody on the internal team can diagnose them confidently, the site is e-commerce and checkout performance directly affects revenue, WordPress plugin or theme conflicts require technical investigation to resolve safely, or third-party script usage has become complex enough that removing the wrong one risks breaking something important.

The honest signal to watch for is not “we scored below 90”—it is “we have tried the obvious fixes and the problem persists, or we cannot confidently identify what the problem actually is.”

What Does Website Speed Optimization Cost?

There is no universal price for website speed optimization, and any number quoted without knowing the specific site should be treated with skepticism. Cost depends on the platform involved (WordPress, a website builder, or a custom application each carry different constraints), how much technical debt has accumulated over time, how many distinct page templates need review rather than a single homepage, how much JavaScript and how many third-party scripts are in use, whether backend and database performance are part of the scope, whether the site is e-commerce with its added complexity, how many images need review and reprocessing, and whether ongoing monitoring is included or handled separately.

It also helps to separate two distinct types of work when discussing cost: an audit, which diagnoses and documents the problems without necessarily fixing them, and an optimization project, which implements the fixes the audit identifies. Some engagements bundle both; others intentionally separate them so a business can decide on implementation scope after seeing what an audit finds. For businesses evaluating this alongside a broader custom software investment, factors that affect custom software development cost follow a similar logic.

Website Speed Audit vs. Optimization Project vs. Monitoring

20 Questions for a Website Performance Audit

Use this list as a self-audit, or as a benchmark for what a professional performance review should actually be covering.

1. Is field data available for this site, or only lab data?
2. Which specific Core Web Vital is failing—LCP, INP, or CLS?
3. Is the problem isolated to mobile, or present on desktop too?
4. What is the actual LCP element on the most important pages?
5. Is the LCP image prioritized and not accidentally lazy-loaded?
6. How much JavaScript is loaded, and how much of it is actually used?
7. Which third-party scripts are running, and why?
8. Is the tag manager carrying tags that are no longer needed?
9. Are images served at the correct dimensions and a modern format?
10. Are too many font files or weights being loaded?
11. What is the server’s time to first byte on key pages?
12. Is browser, CDN, and server-side caching configured effectively?
13. Is a CDN in place, and is it actually serving static assets?
14. Are any API calls taking longer than they reasonably should?
15. Are database queries on key pages efficient and properly indexed?
16. Are embeds (video, maps, social) deferred until needed?
17. Does performance noticeably regress after deployments?
18. Have templates beyond the homepage been tested?
19. Is real-user monitoring in place to catch regressions over time?
20. Who is responsible for reviewing performance on an ongoing basis?

How NogaTech Approaches Website Performance

NogaTech starts a performance review by diagnosing the actual cause rather than applying generic fixes: reviewing field and lab data together, identifying which Core Web Vital is actually failing, and examining images, JavaScript, third-party scripts, hosting, APIs, and backend architecture as connected parts of the same system rather than isolated checkboxes.

From there, the right fix depends on what the diagnosis actually shows—it may be asset and frontend optimization, hosting or server configuration, changes to how the site integrates with other systems, application-level changes for a custom product, or in some cases a broader redesign or rebuild when the underlying platform itself has become the limiting factor. Explore Website Development, Redesign & Support, custom applications and modernization, or automation and connected systems depending on where the bottleneck actually lives.

Frequently Asked Questions

Improve the Experience, Not Just the Score

Strong website performance comes from identifying the real bottlenecks and fixing the parts users actually depend on. Measure first, optimize carefully, and continue monitoring after launch.

You can also view our work to see the types of websites and business systems NogaTech supports.