# Metrical Digital — full content > Every public page of metrical.digital as Markdown, concatenated. Generated from the same source as the HTML pages. See https://metrical.digital/llms.txt for the linked index. --- # Metrical — Web Performance Audits, in Plain English > Metrical runs a real-browser performance test on your URL, measures Core Web Vitals, and returns a prioritised, plain-English list of what to fix first. _Source: https://metrical.digital — Markdown: https://metrical.digital/index.md — Part of Metrical (https://metrical.digital)._ ## Your website's performance, explained by an expert Metrical runs a real-browser performance test on your URL. AI translates the results into plain English and gives you a prioritized list of exactly what to fix first. No account is required to run your first scan. Paste a URL, wait 30–90 seconds, and read the report. ## How it works 1. **Scan — real browser, real conditions.** Metrical's performance lab runs your site across desktop and mobile profiles, measuring what a real user experiences rather than a synthetic estimate. Network throttling, multi-pass testing, and filmstrip capture are included. 2. **Understand — every metric, explained.** See your Core Web Vitals at a glance (LCP, CLS, INP, FCP, TTFB) with a frame-by-frame filmstrip of how your page loads. The deep dive report explains what each number means, what is causing it, and why it matters for your users and your search rankings. 3. **Take action — know what to fix first.** Get a prioritized action plan specific to your site, not a generic checklist. Each fix is ranked by impact, explained in plain English, and scoped to your actual bottlenecks. ## What you get - **Real browser, real data.** Tests run with real network throttling profiles across desktop and mobile, not synthetic estimates. - **Plain English analysis.** Every finding is explained without assuming a performance engineering background. - **Prioritized, not exhaustive.** You get the 5–8 fixes that will actually move the needle. - **No sign-up to try.** Paste a URL and run a scan. Sign up free to unlock the full action plan and track improvements over time. - **Exportable reports.** Download your full report as CSV, JSON, or Markdown. - **Core Web Vitals focus.** LCP, CLS, INP, FCP, and TTFB — the metrics Google uses as a ranking signal. ## Core Web Vitals Metrical measures | Metric | Name | What it measures | | --- | --- | --- | | LCP | Largest Contentful Paint | How quickly the main content of the page renders | | INP | Interaction to Next Paint | How responsive the page is to user input | | CLS | Cumulative Layout Shift | How visually stable the page is while loading | | FCP | First Contentful Paint | How quickly the first pixel of content appears | | TTFB | Time to First Byte | How quickly the server starts responding | ## Start here - Run a free scan: - Plans and pricing: - Frequently asked questions: - Developer resources and API: --- # About Metrical > Metrical is an indie web performance auditing tool built for people who want to know what to fix, not every metric that exists. _Source: https://metrical.digital/about — Markdown: https://metrical.digital/about.md — Part of Metrical (https://metrical.digital)._ Performance data shouldn't require a PhD to understand. ## The problem You've noticed your website feeling slow. Maybe pages take too long to load, or interactions feel sluggish. So you open Google PageSpeed Insights or Lighthouse and you're hit with a wall of numbers, grades, and jargon: "Eliminate render-blocking resources." "Reduce unused JavaScript." Great — but what does that actually mean for your specific site, and where do you even start? Most performance tools are built for performance engineers. They surface every possible metric and leave the prioritisation entirely up to you. For everyone else — developers shipping features, agency teams managing client sites, founders running their own product — that isn't particularly useful. ## What Metrical does differently Metrical runs your URL through its own performance lab with real network throttling, multi-pass testing, and filmstrip capture, then translates the results into plain English. Not a list of everything that could theoretically be improved, but a prioritised action plan: what to fix first, why it matters, and roughly how to approach it. - **Plain English explanations.** Every finding is explained in language that doesn't require you to already be a performance expert. - **Prioritised recommendations.** Focus on the changes with the biggest impact on your scores and real user experience. - **Built-in performance lab.** Tests run in Metrical's own lab with real network throttling, not synthetic estimates on your local machine, so results are consistent and comparable. - **Core Web Vitals focus.** Google's Core Web Vitals directly influence search rankings. Metrical makes improving LCP, CLS, INP, and TTFB accessible without a specialist on your team. ## Built by a developer, for developers Metrical is an indie product, not a venture-backed startup with a growth team. It was built because the existing tools felt unnecessarily complex for most use cases. The goal is to stay small, focused, and genuinely useful. If you have feedback, run into a bug, or just want to say hello, the contact page is always open: --- # Metrical Pricing > Plans, prices, scan allowances, and what each Metrical tier includes. _Source: https://metrical.digital/pricing — Markdown: https://metrical.digital/pricing.md — Part of Metrical (https://metrical.digital)._ Unlock deeper insights and personalized action plans to improve your website performance. ## Plans | Plan | Monthly | Annual (per month) | Scans per month | | --- | --- | --- | --- | | Free | Free | Free | 1 | | Starter | €19 | €16 | 50 | | Pro | €49 | €41 | 250 | Prices are in EUR. Annual billing saves roughly 17%. ### Free — Free See what's slow. - 1 full scan per month - Core Web Vitals & CrUX field data - 2 devices, 1 location, 2 connections ### Starter — €19 See exactly what to fix first. Everything in Free, plus: - Full prioritized action plan with implementation guidance - All opportunities (deep dive, code examples) - Scan history & historical trends - 50 scans per month - Watch up to 3 URLs with email alerts - 8 devices, 6 locations, 4 connections - Report downloads (CSV, JSON, Markdown) ### Pro — €49 Stay fast as you ship. Everything in Starter, plus: - 250 scans per month - Watch up to 15 URLs with email alerts - All devices, locations & connections - API access - PDF reports ## Billing - Cancel any time from account settings; access continues until the end of the billing period. - Full refund within 14 days if you are not happy with your purchase. - Scan allowances reset at the start of each billing cycle. See the live pricing page at https://metrical.digital/pricing. --- # Metrical FAQ > Answers to common questions about Metrical: how scans work, what Core Web Vitals are, pricing, and support. _Source: https://metrical.digital/faq — Markdown: https://metrical.digital/faq.md — Part of Metrical (https://metrical.digital)._ Answers to common questions about Metrical. Can't find what you need? Ask at https://metrical.digital/contact. ## Product ### What is Metrical? Metrical is a web performance auditing tool. You enter a URL, and it runs a full performance scan. We measure Core Web Vitals, load times, and other key metrics. We then explain the results in plain English and give you a prioritised list of things to fix. ### What are Core Web Vitals? Core Web Vitals are a set of metrics defined by Google that measure real-world user experience: Largest Contentful Paint (LCP) measures loading speed, Interaction to Next Paint (INP) measures responsiveness, and Cumulative Layout Shift (CLS) measures visual stability. Google uses these scores as a ranking signal, so improving them can directly help your search visibility. ### How is this different from Google PageSpeed Insights? Google PageSpeed Insights gives you raw scores and a list of potential improvements. Metrical goes further: it prioritises what actually matters for your specific site, explains each issue in plain language, and gives you an actionable plan rather than a list of every possible optimisation. It also lets you test different devices, locations, and connection speeds. ### Does it work with SPAs, React, or Next.js sites? Yes. Metrical uses real browser-based testing, so it measures what users actually experience on your site regardless of how it's built. This includes client-side rendered React apps, Next.js, Vue, or any other framework. ### How long does a scan take? Most scans complete in 30–90 seconds. The exact time depends on the size of the page being scanned, the device and location settings you choose, and current queue load. ## Pricing & Plans ### What's the difference between the free and paid plans? The free plan gives you 1 full scan per month with Core Web Vitals, Deep Dive analysis, and your personalised Action Plan. Paid plans (Starter and Pro) unlock more scans per month and the ability to download PDF reports. See the pricing page at https://metrical.digital/pricing for the full comparison. ### How many scans can I run per month? Free plan: 1 scan/month. Starter plan: 50 scans/month. Pro plan: 250 scans/month. Scans reset at the start of each billing cycle. ### Do you offer refunds? If you are not happy with your purchase, contact us within 14 days and we will issue a full refund. ### Can I cancel my subscription at any time? Yes. You can cancel from your account settings at any time. You will retain access to your plan until the end of the current billing period. ## Technical ### What devices and locations can I test from? You can choose between mobile and desktop device profiles, and select from several geographic locations to simulate how your site performs for users in different regions. Connection speed presets (e.g. fast 4G, slow 3G) are also available on paid plans. ### Is my data private? Scan results are stored and associated with your account. We do not share your results with third parties. See the Privacy Policy at https://metrical.digital/privacy for full details on how your data is handled. ### Can I scan any URL? You can scan any publicly accessible URL. Private pages, password-protected content, or pages behind a login wall cannot be scanned, as the scanner operates like a regular browser visiting your page without authentication. ## Support ### How do I get help if something is not working? The best way to get help is via the contact page at https://metrical.digital/contact. Metrical is an indie product, so responses may not be instant. But every message is read and responded to. ### I found a bug. How do I report it? Please get in touch at https://metrical.digital/contact with a description of what happened, the URL you were scanning, and any error messages you saw. The more detail you can provide, the faster it can be investigated. --- # Metrical Digital API — Developer Documentation > Developer resources for Metrical Digital: OpenAPI specification, HTTP endpoints, authentication, report export formats, and API early access. _Source: https://metrical.digital/developers — Markdown: https://metrical.digital/developers.md — Part of Metrical (https://metrical.digital)._ Programmatic access to Metrical. Run performance audits, retrieve results, and monitor Core Web Vitals directly from your code. ## Machine-readable resources | Resource | URL | Media type | | --- | --- | --- | | API index | | `application/json` | | OpenAPI 3.1 specification | | `application/openapi+json` | | API catalog (RFC 9727) | | `application/linkset+json` | | llms.txt index | | `text/plain` | | llms-full.txt (full corpus) | | `text/plain` | | Sitemap | | `application/xml` | | Crawler policy | | `text/plain` | Every prose page on metrical.digital also has a Markdown representation. Request it with `Accept: text/markdown`, or append `.md` to the path: ```sh curl -H 'Accept: text/markdown' https://metrical.digital/developers curl https://metrical.digital/developers.md ``` ## Available today The endpoints below are live on `https://metrical.digital` and described in the OpenAPI specification. They authenticate with the browser session — a signed-in customer session or the `metrical_guest_session_id` cookie issued on first visit — and are intended for use from the Metrical web app. ### `GET /api/v1/scan/{scanId}/report` Export a completed scan report. The `format` query parameter accepts `csv` (default), `json`, or `markdown`. Returns `401` without a session, and the upstream status when the report cannot be generated. Unversioned alias: `GET /api/scan/{scanId}/report`. ### `POST /api/v1/scans/{scanId}/feedback` Submit feedback on a scan result. Accepts a JSON body and returns the upstream response. Unversioned alias: `POST /api/scans/{scanId}/feedback`. ## Versioning and deprecation Every endpoint is available under a version prefix, currently `/api/v1`. Breaking changes ship as a new prefix; the existing one keeps working. - The current version is `v1`, served from . - Additive changes — new endpoints, new optional parameters, new response fields — ship within the current version. Treat unknown response fields as forwards-compatible and ignore them. - A change that would break an existing client ships as a new version prefix. The previous version keeps responding until its sunset date. - A version is never sunset with less than 180 days of notice. - Once deprecated, every response from that version carries a `Deprecation` header (RFC 9745), a `Sunset` header (RFC 8594), and a `Link` header with `rel="successor-version"`. - The unversioned paths under are permanent aliases of the current version and move with it. Pin to a version prefix if that matters to you. - Every response names the version that produced it in the `API-Version` header. The policy is published as JSON at and as the `x-api-versioning` extension in . ## Error responses Every failure returns JSON, including unknown paths and unsupported methods. `error.code` is stable and safe to branch on; `error.hint` describes how to recover. ```json { "error": { "code": "not_found", "message": "No API endpoint exists at GET /api/nope.", "hint": "Check the path and method against the OpenAPI description at https://metrical.digital/openapi.json.", "status": 404, "documentation_url": "https://metrical.digital/developers", "specification_url": "https://metrical.digital/openapi.json" }, "message": "No API endpoint exists at GET /api/nope." } ``` Codes: `not_found`, `method_not_allowed`, `unauthorized`, `invalid_request`, `quota_exceeded`, `upstream_error`. ## Planned A standalone REST API with API-key authentication is in development and not yet released. When it ships it will cover: - **Run scans programmatically** from CI/CD pipelines, scripts, and applications. - **Retrieve structured results** as JSON: Core Web Vitals, performance scores, prioritised recommendations, and plain-English explanations. - **Monitor over time** with scheduled scans and threshold-based alerts. - **Webhooks for async results** so you do not have to poll while a scan runs. API access is included in the Pro plan. To register interest or describe a use case you need supported, get in touch at . --- # Contact Metrical > How to reach Metrical Digital for support, bug reports, feedback, and API early access. _Source: https://metrical.digital/contact — Markdown: https://metrical.digital/contact.md — Part of Metrical (https://metrical.digital)._ ## Get in touch Metrical is an indie product. Every message is read and responded to, though responses may not be instant. - **Email:** - **Contact form:** - **X / Twitter:** ## What to include When reporting a bug, include a description of what happened, the URL you were scanning, and any error messages you saw. The more detail you provide, the faster it can be investigated. For API early access, say which endpoints and use cases you need. See for the current developer surface. --- # Metrical Blog > Articles on web performance, Core Web Vitals, and diagnosing slow websites. _Source: https://metrical.digital/blog — Markdown: https://metrical.digital/blog.md — Part of Metrical (https://metrical.digital)._ Writing about web performance, Core Web Vitals, and what actually makes sites slow. ## Posts - [Why Your WordPress Site Is Slow](https://metrical.digital/blog/why-your-wordpress-site-is-slow) — Real data from 500+ WordPress site scans: the most common causes of slow load times, ranked by frequency and impact _(published 2026-05-20, 10 min read)_ --- # Why Your WordPress Site Is Slow > Real data from 500+ WordPress site scans: the most common causes of slow load times, ranked by frequency and impact _Source: https://metrical.digital/blog/why-your-wordpress-site-is-slow — Markdown: https://metrical.digital/blog/why-your-wordpress-site-is-slow.md — Part of Metrical (https://metrical.digital)._ _Published 2026-05-20 · 10 min read · 2007 words_ _Tags: wordpress, performance, lighthouse, page-speed-insights, core-web-vitals, ttfb, lcp, inp, render-blocking, web-performance, wordpress-optimization, google-fonts_ Over the past two months, we've scanned over 500 WordPress sites. In this article, we break down the real causes behind slow WordPress load times. We will dive into what each issue is, why it happens, and what to do about it. _[WordPressIssuesChart: interactive element — view it at https://metrical.digital/blog/why-your-wordpress-site-is-slow]_ --- ## 1. Your plugins have added too many stylesheets ### What is the user experience? A blank white screen for the first one to three seconds of a visit. Google's own research shows that more than half of mobile visitors abandon a page that takes longer than three seconds to load, and with this issue most of that time passes before a single pixel appears. ### Why does this happen? Every WordPress plugin installs its own styling code. WooCommerce, Elementor, Yoast SEO, Contact Form 7, WPForms, Slider Revolution, WPML: each adds at least one stylesheet, some add three or four. None of them coordinate with each other, or check whether their styles are actually needed on the page you're visiting. Before your browser can display anything on screen, it needs two things: the page structure (your HTML) and the styling rules (your CSS). If it hasn't finished downloading every CSS file, it won't paint a single pixel. The technical term for this is render-blocking. A site with 15–20 active plugins routinely has 12–18 separate CSS files loading in this blocking position before anything shows up. This is the most widespread issue in our data, appearing in roughly 25% of WordPress scans. Several problems compound it: - **One file pulling from another**: some stylesheets tell the browser to go fetch a second file. The browser has to wait for the first one to arrive, then go back out for the second. Each extra trip adds delay. - **Styles loading on the wrong pages**: a WooCommerce stylesheet loading on a blog post, a contact form stylesheet loading on a page with no form. Each plugin loads its styles everywhere by default. - **Too many separate files**: twelve separate requests is significantly slower than one or two combined, even on a fast connection. ### What are some common fixes? To see what's happening on your own site: open Chrome DevTools (F12), go to the Network tab, and filter by CSS. Each row is a stylesheet your browser had to download before it could show the page. The CSS minification and async loading settings in [WP Rocket](https://docs.wp-rocket.me/article/1350-css-minify-combine) or [LiteSpeed Cache](https://docs.litespeedtech.com/lscache/lscwp/pageopt/) are the highest-impact toggles you can enable without touching code. --- ## 2. Your hero image is loading too late ### What is the user experience? The page layout appears with a large blank space at the top, then the image suddenly pops in. The page feels unfinished. Beyond the visitor experience, Google uses LCP as an official search ranking signal, which means a slow hero image directly suppresses where your site appears in results. LCP image problems appear in 22% of WordPress scans. ### Why does this happen? Several problems tend to stack on top of each other: - **The image isn't marked as important.**: Even with a regular image tag, the browser treats all images the same priority by default. It can't tell your hero apart from a small logo or a decorative icon below the fold. WordPress 6.3 and above does this automatically for images in the main content area, but heroes set inside page builders or theme headers are usually missed. - **The image is too large for mobile.**: Sending a 2400-pixel-wide image to a phone screen that's 390 pixels wide downloads 8–12 times more data than necessary. WordPress can create smaller versions of your images automatically, but page builders like Elementor and Divi often load the full desktop image regardless of the device. - **The image format is outdated.**: WordPress has generated WebP images on upload since version 5.8, but only for images uploaded after that upgrade. Anything older in your media library is still being served in its original format. ### What are some common fixes? A quick way to check: right-click your hero image in the browser, choose "Inspect," and look at the src attribute. If it's loading a 2400px wide file on a phone, you're transferring far more data than necessary. WP Rocket has a guide on [serving WebP images in WordPress](https://wp-rocket.me/blog/webp-use-image-format-wordpress/) if your media library predates version 5.8. If your hero is a CSS background, the partial workaround is adding a preload hint in the head of your theme. This tells the browser to start fetching the image early even before it processes the CSS. WordPress has a native filter for this ([wp_preload_resources](https://developer.wordpress.org/reference/hooks/wp_preload_resources/)) which you can use to register the image correctly, including responsive sizes and fetch priority. The proper fix is converting it to a regular image tag and marking it as high priority, which you can do in your theme or page builder template. --- ## 3. Your JavaScript is blocking user interaction ### What is the user experience? The page looks fully loaded — content is visible, layout is correct — but nothing responds. Tapping a button does nothing; clicking a menu item produces no reaction. After a second or two, it finally catches up. Most visitors don't think "this page is slow." They think the site is broken, and most don't come back. On any action-driven page — a contact form, a product page, a booking flow, a checkout — unresponsive clicks feel broken. ### Why does this happen? JavaScript runs in a queue in your browser. When a script is running, everything else waits — including your taps and clicks. If a script takes a long time to finish (more than 50 milliseconds, which is barely perceptible to humans but significant to browsers), the page freezes for that entire duration. Google now measures this directly. The metric is called Interaction to Next Paint (INP), and it became an official ranking factor in 2024. Sliders, carousels, popup builders, and form plugins all run their JavaScript immediately when the page loads, regardless of whether you'll ever interact with those features. Blocking JavaScript appears in 7.4% of WordPress scans, with the highest average impact of any category we track. ### What are some common fixes? - **Load scripts after the page**: a defer flag on a script tells the browser "download this while the page loads, but don't run it until after everything is displayed." This removes the freeze without removing the feature. [WP Rocket](https://wp-rocket.me) and [LiteSpeed Cache](https://wordpress.org/plugins/litespeed-cache/) can apply this automatically across all scripts. - **Move scripts to the bottom of the page**: less precise than defer, but scripts at the bottom run after the visible content is ready rather than blocking it. - **Only load scripts when needed**: the best option for sliders or popups is to not load their JavaScript at all unless the user is about to interact with them. This requires a bit more work, but it eliminates the cost entirely. --- ## 4. Your server responds slowly before anything can load ### What is the user experience? Staring at a blank browser tab with nothing happening. Someone actively clicked a link to reach your site and every extra second of delay is a chance for them to click back & choose a competitor instead. For WooCommerce stores in particular, slow server response is one of the most direct contributors to cart abandonment, because it happens at every stage of the funnel. ### Why does this happen? Every time someone visits a WordPress page that isn't cached, the server has to build it from scratch. It loads all your active plugins, queries the database for your content, assembles everything together, and only then sends the result to the visitor. On a default shared hosting setup with no caching, this can take 1–3 seconds. Everything else on the page waits until it's done. This appears in 17% of WordPress scans and is almost entirely absent from non-WordPress sites. The metric for this is Time to First Byte (TTFB). This is how long from when your browser asks for a page to when the server starts answering. On a well-configured site, TTFB is under 200ms. Above 400ms and you have a server configuration problem that image compression will not fix. The most common causes: - **No page caching**: without a cache, every visitor gets a freshly built page. With one, most visitors get a pre-built copy served almost instantly. - **Slow database lookups**: WordPress asks your database the same questions on every page load (site settings, menu items, widget content) instead of remembering the answers. - **WordPress running housekeeping tasks during visitor visits**: WordPress handles scheduled jobs by piggybacking on real visitor requests. When a housekeeping task fires, that visitor's page load waits for it to finish. ### What are some common fixes? To check your TTFB: open DevTools, click the Network tab, reload the page, and click the first row (your HTML). The "Waiting" segment is your server response time. - **Install a page cache**: [WP Rocket](https://wp-rocket.me), [LiteSpeed Cache](https://wordpress.org/plugins/litespeed-cache/), and [W3 Total Cache](https://wordpress.org/plugins/w3-total-cache/) all work. To confirm your cache is actually serving pages (not just installed), right-click your page, choose "View Page Source," and scroll to the very bottom. You should see that a working cache plugin leaves a timestamp comment there. - **Consider a managed host**: most managed WordPress hosts ([WP Engine](https://wpengine.com), [Kinsta](https://kinsta.com), [Flywheel](https://getflywheel.com)) include database memory caching by default, which handles the repeated lookup problem automatically. - **Ask your host about disabling WP-Cron**: this moves WordPress's housekeeping tasks off visitor requests and onto a proper background schedule. --- ## 5. Google Fonts adds an extra request most sites haven't noticed ### What is the user experience? Text is either invisible for a noticeable moment before appearing in the correct font, or loads immediately in a generic system font and then flickers to your branded font when it arrives. Neither is a disaster on a fast connection, but on a slow mobile connection 400–600ms of missing or flashing text is jarring enough to make a page feel unfinished. 4.3% of WordPress scans flag this as a contributing issue. ### Why does this happen? Most WordPress sites load fonts from Google's servers, not their own. That means your browser has to make extra requests to a different site before it can display your text. The chain looks like this: - contact Google's font directory → download a CSS file → contact Google's file servers → download the actual font files. On a slow mobile connection that round-trip adds 200–600ms before any text can appear. While the fonts are loading, browsers handle the missing text in one of two ways. Some show a flash of invisible text where your font will be. Others show your fallback system font immediately, then swap to your chosen font when it loads. The second approach is better for users, and most Google Fonts embeds include it by default now. ### What are some common fixes? The fix is serving your fonts from your own domain instead of Google's. This removes the extra round-trip entirely. The [OMGF (Optimize My Google Fonts)](https://wordpress.org/plugins/host-webfonts-local/) plugin does this automatically: install it, run the scan, and it downloads and serves your fonts locally with no coding required. If your theme uses multiple font weights (regular, medium, bold), consider switching to a variable font. Instead of downloading a separate file for each weight, one file contains all of them. Fewer requests, same result. --- ## Summary Most WordPress performance problems are fixable without touching code. A page cache plugin resolves the TTFB issue for the majority of sites. WP Rocket or LiteSpeed Cache handle render-blocking CSS and deferred JavaScript in a few clicks. OMGF sorts out Google Fonts in minutes. The hero image (LCP) and JavaScript interaction (INP) problems are more specific to your theme and page builder. The diagnostic steps above will tell you exactly what you're dealing with before you change anything. If you want to see which of these are affecting your site, [scan it with Metrical](https://metrical.digital). It breaks down the real issues in plain language, ranked by impact. --- ## Frequently asked questions ### What makes WordPress sites slow compared to other platforms? WordPress sites run on a dynamic stack where every uncached page visit triggers a full build: loading all active plugins, querying the database, and assembling the HTML. On a default shared hosting setup this can take 1–3 seconds before the first byte is sent. Combined with multiple plugin stylesheets that block the browser from rendering, even moderate traffic can produce sluggish load times. ### How do plugin stylesheets slow down WordPress? Each WordPress plugin installs its own stylesheet, and none of them coordinate with each other. With 15–20 active plugins a site can accumulate 12–18 separate CSS files loading in a render-blocking position, which means the browser cannot paint a single pixel until every file has downloaded. This is the most common issue in our scan data, appearing in 25% of WordPress sites. ### How do I fix a slow hero image (LCP) in WordPress? Check whether your hero image has a high fetch priority set. WordPress 6.3+ does this automatically for images in the main content area, but heroes inside page builders are usually missed. Also check the image is sized for mobile — sending a 2400px image to a 390px phone transfers 8–12x more data than necessary. LCP problems appear in 22% of WordPress scans. ### What is TTFB and how do I improve it in WordPress? Time to First Byte (TTFB) measures how long from when the browser requests a page until the server starts responding. On a well-configured WordPress site it should be under 200ms. The most effective fix is a page caching plugin such as WP Rocket, LiteSpeed Cache, or W3 Total Cache, which serves pre-built pages instead of rebuilding them for every visitor. ### Does hosting Google Fonts locally improve WordPress speed? Yes. Loading Google Fonts from Google's servers requires your browser to make two round-trips to a different domain before any text can appear. On slow mobile connections this adds 200–600ms. Hosting fonts on your own domain removes this round-trip entirely. The OMGF plugin does this automatically with no coding required.