Practical WordPress performance, tested and explained.

Speed Test

SitePulse Labs

WordPress Performance Glossary

Plain-English definitions of WordPress performance, hosting, Core Web Vitals, caching, security, and SEO terms, for beginners and experienced readers alike.

This glossary collects clear, practical definitions for the WordPress performance, hosting, Core Web Vitals, caching, security, technical SEO, and diagnostic-tool terms used across SitePulse Labs guides. It’s written to help beginners understand unfamiliar terminology without oversimplifying, while still giving more experienced readers useful, precise technical context.

Software, browsers, hosting platforms, and measurement standards change over time, so a term’s exact current behavior (a specific threshold, a specific tool interface, a specific WordPress default) can shift after this page was written. Where a definition depends on a detail that changes periodically, that’s noted directly.

Quick alphabetical index

Terms are grouped by topic below for context, but this index lists all of them alphabetically for quick lookup.

WordPress fundamentals

WordPress core

The base WordPress software itself, maintained by the WordPress open source project, as distinct from any theme or plugin installed on top of it. Core updates, particularly minor releases, frequently include security fixes, which is why keeping core current is a standard part of WordPress security hardening.

Plugin

An installable package of code that adds functionality to WordPress without modifying core files directly. Plugin quality varies enormously; a poorly built plugin can add unnecessary database queries, front-end weight, or admin-area slowdowns regardless of how many plugins a site runs in total. Auditing what a specific plugin actually does on each page, rather than counting plugins, is the more useful diagnostic approach.

Theme

The package of templates and styles that controls a WordPress site’s visual design and, often, a meaningful share of its front-end CSS and JavaScript weight, covered in WordPress Fonts, CSS, Scripts, and Plugin Weight Explained.

The URL structure WordPress uses for posts, pages, and other content, configurable under Settings → Permalinks. Changing an established site’s permalink structure without redirecting the old URLs breaks every existing indexed link and inbound reference at once, one of the more damaging technical SEO mistakes possible, covered in WordPress Technical SEO Audit.

WP-Cron

WordPress’s built-in scheduling system for recurring tasks, such as checking for updates or publishing scheduled posts, triggered by site visits by default rather than a genuine system-level cron job unless configured otherwise. A plugin scheduling frequent or expensive WP-Cron tasks can add periodic overhead to whichever page request happens to trigger it, and some plugins, particularly WooCommerce and its extensions, instead use the related Action Scheduler library for heavier background job processing.

Browser and rendering terminology

DOM

The Document Object Model: the browser’s in-memory representation of a page’s HTML structure, built as the page is parsed. A very large or deeply nested DOM increases the cost of layout and style calculations.

CSSOM

The CSS Object Model: the browser’s representation of all CSS rules that apply to a page, built in parallel with the DOM. The browser combines DOM and CSSOM into a render tree before it can paint anything, which is why a stylesheet is generally render-blocking by default.

Critical rendering path

The sequence of steps, from parsing HTML through building the DOM and CSSOM to layout and paint, that a browser must complete before a page becomes visible. Render-blocking resources are the ones sitting directly on this path.

Render-blocking resource

A stylesheet or script the browser will not paint any content without, meaning it must be downloaded and processed before the page can visually appear. Not every resource blocks rendering; images and deferred scripts generally don’t.

Above the fold

The portion of a page visible on screen without scrolling, which varies by device and viewport size rather than being a single fixed boundary. Content in this area, particularly a page’s likely Largest Contentful Paint element, generally shouldn’t be lazy-loaded, since doing so delays the very content a visitor sees first.

Main thread

The primary browser thread responsible for running JavaScript, calculating style and layout, and coordinating much of the rendering work. A long task can delay an interaction and contribute to poor Interaction to Next Paint, although INP reflects the complete interaction latency rather than JavaScript execution alone.

Core Web Vitals

Core Web Vitals

A set of three specific metrics, LCP, INP, and CLS, that Google surfaces as important indicators of page experience. Each is assessed at the 75th percentile of real visits and evaluated separately for mobile and desktop. See the Core Web Vitals category for a guide to each metric.

LCP

Largest Contentful Paint: the render time of the largest visible image, text block, or video in the viewport. Current good threshold is 2.5 seconds or under. Covered in detail in Largest Contentful Paint in WordPress.

INP

Interaction to Next Paint: measures responsiveness across a visitor’s entire session by timing the delay between an interaction and the next visual update. Current good threshold is 200 milliseconds or under. Covered in Interaction to Next Paint in WordPress.

CLS

Cumulative Layout Shift: measures unexpected visual movement of page elements, scored by impact fraction times distance fraction. Current good threshold is 0.1 or under. Covered in Cumulative Layout Shift in WordPress.

Performance metrics

FCP

First Contentful Paint: when the first piece of content, text, an image, anything, becomes visible on screen. It’s an early loading signal, distinct from LCP, which marks the largest element rather than the first one, and is one of several metrics factored into a Lighthouse lab performance score.

TTFB

Time to First Byte: the time from requesting a resource until the first response byte arrives, reflecting redirects, connection setup, network latency, caching, and origin processing together. A slow initial document response can delay resource discovery and later loading milestones. Related to hosting concepts in WordPress Hosting, PHP Version, and the Server Performance Floor.

TBT

Total Blocking Time: a lab-only metric measuring cumulative time the main thread was blocked by long tasks between First Contentful Paint and full interactivity. It functions as a lab proxy correlated with the field metric INP, though the two aren’t directly interchangeable numbers.

Speed Index

A lab metric measuring how quickly a page’s visible content is painted overall during loading, expressed as a score where lower is better. It captures the general visual loading progression rather than any single specific moment, complementing point-in-time metrics like FCP and LCP.

Field data

Real-world performance measurement collected from actual visitors, aggregated over time, as opposed to a single simulated lab test. Field data reflects the range of real devices, networks, and locations Google’s Core Web Vitals assessment is based on.

Lab data

Performance measurement from a single, controlled, simulated test run, such as a Lighthouse report. Useful for reproducible debugging, but it reflects only one specific scenario, not the distribution of real visitor conditions field data captures.

CrUX

The Chrome User Experience Report: Google’s dataset of real-user field measurements from opted-in Chrome users, aggregated over a rolling 28-day window at the 75th percentile. It’s the field-data source behind Search Console’s Core Web Vitals reporting and PageSpeed Insights’ field data section, covered in How to Use PageSpeed Insights for WordPress.

Caching

Page cache

A caching layer that stores a page’s rendered HTML output so future requests can be served without re-running WordPress’s PHP and database work. For cacheable public pages, it can substantially reduce origin work, though logged-in, personalized, cart, and checkout pages commonly need exclusions. Covered in WordPress Caching Explained.

Full-page cache

Another term for page caching, emphasizing that the entire rendered page, not just individual assets, is cached and reused. It generally cannot safely serve logged-in sessions or personalized content.

Browser cache

Storage of static files locally on a single visitor’s own device, controlled by Cache-Control headers, benefiting only that visitor’s repeat visits rather than every visitor to a site.

Object cache

A cache for database query results and other computed data. WordPress’s default object cache is non-persistent, meaning it only lasts for the duration of a single request and does not carry over between visitors; a persistent object cache using an external backend such as Redis or Memcached keeps that data available across requests and visitors, meaningfully reducing repeated database load on busy or dynamic sites.

Cache HIT

A response served directly from cache rather than freshly generated, typically visible via a response header such as X-Cache. Its counterpart, a MISS, means the content wasn’t found in cache and had to be generated or fetched fresh; other common values include BYPASS (cache deliberately skipped) and EXPIRED (a stale entry needing revalidation).

Cache key

The set of request characteristics, typically the URL and sometimes device type or cookie presence, that a caching system uses to decide whether two requests should be treated as the same for caching purposes.

Cache-Control

An HTTP response header that tells browsers and shared caches how a response should be cached: whether it can be stored, for how long, and by which type of cache (private, browser-only, versus public, shared caches too).

CDN and network delivery

CDN

A content delivery network: a geographically distributed set of servers, or points of presence, that can cache and serve content from locations closer to visitors, reducing network latency for cacheable requests. A CDN does not speed up PHP or database execution for uncached requests, and its benefit depends heavily on how much of a site’s traffic is genuinely cacheable and how far its audience sits from the origin server.

Edge cache

A cache located at a CDN’s distributed edge location rather than at the origin server, allowing a cached response to be served without contacting the origin at all.

Origin server

The actual hosting server where a website’s files, database, and PHP execution genuinely live, as distinct from any CDN edge sitting in front of it.

TLS

Transport Layer Security: the encryption protocol behind HTTPS, establishing a secure connection between browser and server. Establishing a TLS connection involves its own network round trips before content transfer begins.

DNS

The Domain Name System: translates a human-readable domain name into the server address a browser needs to connect to. DNS resolution is one of several network round trips, alongside TCP and TLS handshakes, involved before a page can begin loading at all.

Hosting and server resources

PHP worker

A process capable of handling one PHP request at a time on a server. A limited number of PHP workers can cause slowdowns during traffic spikes even if the site otherwise loads quickly under normal conditions, covered in WordPress Hosting, PHP Version, and the Server Performance Floor.

Shared hosting

A hosting model where multiple websites share a server’s CPU, memory, and storage capacity, typically the most affordable entry point and adequate for many low-traffic sites, though performance can be affected by other sites on the same server. Compared with other hosting categories in Shared, VPS, Cloud, or Managed WordPress Hosting.

VPS

Virtual Private Server: a physical server divided into isolated virtual instances, each with dedicated resource allocations, generally offering more predictable performance than shared hosting.

Staging environment

A separate, non-public copy of a website used to safely test updates, configuration changes, or code before applying them to the live site.

Server response time

How long a server takes to process a request and begin sending a response, closely related to TTFB and capped by hosting resources, PHP configuration, and database performance.

PHP and database concepts

PHP

The server-side programming language WordPress is built on. PHP version affects both performance and security; WordPress.org periodically updates its recommended minimum PHP version as older versions reach end-of-life.

Database query

A single request made to the site’s MySQL or MariaDB database, for example to retrieve a post’s content or check a plugin setting. Slow or duplicate queries are a common, diagnosable cause of database-related slowness, often traceable to a missing index or an inefficient query structure, and identifiable with tools like Query Monitor. Covered in WordPress Database Optimization.

Autoloaded option

A WordPress setting stored in the options table and loaded into memory automatically on every single page request, regardless of relevance. Excessive autoloaded data is a genuine, checkable performance concern.

CSS and JavaScript

Minification

Removing unnecessary characters (whitespace, comments, unused formatting) from CSS or JavaScript files to reduce their file size without changing their function. It reduces download size but doesn’t address how many separate files load or when they execute.

Critical CSS

The minimal set of styles needed to render the visible, above-the-fold portion of a specific page, often inlined so rendering does not wait for the full stylesheet. It is page- and template-dependent and may need regeneration when layouts or components change.

Async

A script-loading attribute that lets a script download without blocking HTML parsing and execute as soon as it finishes downloading, in no guaranteed order relative to other scripts.

Defer

A script-loading attribute that lets a script download without blocking parsing, but delays execution until parsing completes, preserving the script’s original document order relative to other deferred scripts.

JavaScript long task

Any single piece of main-thread JavaScript execution lasting roughly 50 milliseconds or more, during which the browser cannot respond to user interactions, a direct contributor to poor INP.

Third-party script

A script loaded from an external domain, such as analytics, advertising, or embedded widgets, generally outside a site owner’s direct control to optimize. These scripts frequently show up as significant contributors to main-thread activity and are a common, easily overlooked cause of poor responsiveness.

Preconnect

A resource hint (<link rel="preconnect">) that tells the browser to establish a connection to a third-party origin in advance, saving time when the actual request fires.

Preload

A resource hint (<link rel="preload">) that tells the browser to fetch a specific, critical, often late-discovered resource earlier than it would otherwise be found. Should be used selectively, since overuse competes with other high-priority resources.

Images and fonts

Lazy loading

Deferring the download of an off-screen image or resource until the browser determines it’s likely needed soon. The page’s LCP image should generally not be lazy-loaded, since doing so delays the very content being measured. Covered in How to Optimize Images and the LCP Element in WordPress.

WebP

An image format that generally produces smaller files than equivalent-quality JPEG or PNG at similar visual quality, supported natively by WordPress since version 5.8, provided the server’s image library supports encoding it. AVIF, supported since WordPress 6.5, often achieves smaller files still.

Responsive images (srcset)

An HTML mechanism (the srcset and sizes attributes) that lets a browser choose the most appropriately sized image file for a visitor’s specific device and viewport, generated automatically by WordPress since version 4.4.

Font-display

A CSS property controlling how a browser handles the gap between a page loading and a custom web font becoming available, with values like swap and optional offering different trade-offs between visible text delay and font-swap layout shift.

Technical SEO

Canonical URL

The URL a search engine is told to treat as authoritative when multiple URLs could show the same or similar content, such as a page reachable with and without a tracking parameter. Set via a self-referencing rel="canonical" tag on the preferred version, which Google recommends including even before any duplicate actually exists, as a safeguard. Covered in Canonical URLs, Redirects, and Duplicate Content in WordPress.

Redirect chain

A sequence where one URL redirects to a second URL that itself redirects again before reaching the final destination. Long chains add latency and are not reliably followed by every crawler or browser, so Google’s own guidance recommends redirecting directly to the final destination wherever possible.

Duplicate content

Substantively identical or near-identical content accessible at more than one URL. Multiple versions can make canonical selection and signal consolidation less clear, so a preferred version is usually reinforced with consistent internal links, canonical tags, or redirects where appropriate. This is generally a consolidation issue rather than an automatic penalty.

Crawling and indexing

Crawling

The process of a search engine’s bot requesting and downloading a page. Distinct from indexing: a page can be perfectly crawlable and still excluded from search results by a separate signal, such as a noindex tag or a canonical pointing elsewhere.

Indexing

A search engine’s decision to store a crawled page and make it eligible to appear in search results. Covered alongside crawling in WordPress XML Sitemaps and Robots.txt.

Robots.txt

A plain-text file that tells well-behaved crawlers which parts of a site to avoid requesting. It controls crawl access, not whether a URL can appear in search results; a disallowed page can still be indexed if other pages link to it.

XML sitemap

A file listing a site’s canonical, indexable URLs to help search engines discover them efficiently. WordPress core has generated a basic sitemap automatically since version 5.5.

Noindex

A directive telling a search engine not to include a specific, crawlable page in search results. The page must remain accessible to the crawler so the directive can be seen; combining noindex with a robots.txt disallow can prevent discovery of the instruction. For staging sites, authentication or network-level access control is stronger than relying on noindex alone.

WordPress security

Least privilege

The principle of giving each user account only the access it genuinely needs, limiting the damage a single compromised account can cause. In WordPress terms, this means assigning Editor, Author, or Contributor roles where appropriate instead of defaulting every user to Administrator for convenience. Covered in WordPress Login Security.

Multi-factor authentication

An authentication method requiring a second factor beyond a password alone, meaningfully reducing account-takeover risk, particularly for administrator accounts. Not all methods offer equal protection; phishing-resistant methods such as hardware security keys are generally considered stronger than authenticator-app codes, which in turn are stronger than SMS-based codes.

Brute-force attack

An attack that systematically guesses many possible passwords against one specific account, distinct from credential stuffing, which instead tries username/password combinations already leaked from unrelated breaches elsewhere. Both are addressed by rate limiting, multi-factor authentication, and unique passwords.

Application Password

A WordPress core feature intended for API-based authentication, such as the REST API or XML-RPC where enabled, stored hashed, shown only once at creation, and individually revocable, rather than intended for interactive dashboard logins through wp-login.php. Using a dedicated application password for a specific integration limits the exposure if that integration is later compromised.

Diagnostic and testing tools

PageSpeed Insights

A free Google tool combining real-user field data (from CrUX) with simulated lab data (from Lighthouse) into one report. Covered in How to Use PageSpeed Insights for WordPress.

Lighthouse

The open-source auditing engine behind PageSpeed Insights’ lab data section, running a single simulated page load under controlled conditions and producing a weighted performance score. The same engine is also available directly inside Chrome DevTools for local testing.

Chrome DevTools Performance panel

A browser-based diagnostic tool that records a detailed trace of network activity, main-thread execution, and rendering work for a single page load or interaction. Covered in Chrome DevTools Performance Panel for WordPress.

Query Monitor

A free WordPress plugin that surfaces database queries, PHP errors, hooks, HTTP requests, and enqueued assets for a specific page request, attributed to the responsible plugin or theme. Covered in Query Monitor for WordPress.

HTTP and request terminology

HTTP request

A single request a browser or other client makes to a server for a specific resource, such as a page, image, or script. A typical page load involves many individual HTTP requests.

HTTP status code

A numeric code a server returns with each response, indicating the outcome: 200 for success, 404 for not found, 5xx for a server error, among others. Auditing a site for unexpected 404s or 5xx responses is a standard part of a technical SEO review.

Redirect (301/302)

An instruction telling a browser or search engine that a URL has moved. A 301 signals a permanent move; a 302 signals a temporary one. Using the wrong type is a common technical SEO mistake.

REST API

WordPress’s built-in interface allowing external applications and front-end JavaScript to read and write site data over HTTP, used by the block editor and many plugin features such as dynamically loaded filters or search. Diagnostic tools like Query Monitor can debug REST API requests specifically, including background requests that don’t trigger a full page reload.

AJAX

A technique allowing a page to send and receive data from the server in the background, without a full page reload, commonly implemented in WordPress via requests to admin-ajax.php.

Related pages

For a guided path through related topics rather than individual definitions, see Start Here and Methodology. To browse full guides by subject, visit the WordPress Speed, Core Web Vitals, WordPress Hosting, Technical SEO, WordPress Security, and Tools & Experiments category hubs.