Speed is no longer a nice-to-have for WordPress sites. Google’s Core Web Vitals are a confirmed ranking signal, and the gap between a passing score and a failing one often comes down to specific elements on specific pages behaving poorly for real users. The challenge is figuring out exactly which elements, on which pages, and on which devices.
This is where BlinkSpeed’s performance logs panel becomes one of the most useful tools in your optimization workflow. Rather than relying on lab-based tests that simulate a single visit under controlled conditions, BlinkSpeed collects CWV data from actual visitors and stores it in your WordPress database – giving you a real-world CWV report tied to real URLs, real device types, and real timestamps.
This guide explains how the logging system works, how to read every column in the log table, how to use the filters to isolate the most important issues, and how to turn what you see in the performance logs into concrete speed improvement tracking actions.
What Core Web Vitals Are and Why Logs Matter
Before working with the log interface, it helps to understand what each metric measures and why it matters for your performance logs.
LCP – Largest Contentful Paint
LCP measures how long it takes for the largest visible element on the page to fully render. This is typically a hero image, a large banner, a product photo, or a prominent heading. Google’s threshold for a good LCP score is under 2.5 seconds. Between 2.5 and 4 seconds is classified as “needs improvement.” Anything above 4 seconds is classified as poor.
LCP monitoring is critical because it is the metric most directly felt by users. When the main visible content takes too long to appear, visitors perceive the page as slow even if the rest of the content loads quickly. LCP monitoring through real visit data tells you which pages have genuinely slow hero content – something that lab tests often miss because they simulate fresh network conditions rather than real-world connection speeds.
CLS – Cumulative Layout Shift
CLS measures visual instability – how much the layout shifts unexpectedly as the page loads. A good CLS score is under 0.1. Anything above 0.25 is considered poor. CLS tracking captures events like images without defined dimensions loading and pushing text down, fonts swapping and reflowing content, or ads and embeds injecting themselves into the layout after the initial render.
CLS tracking is particularly important for content-heavy sites because layout shifts frustrate users at the moment of interaction. A visitor about to tap a link that shifts before they tap will either miss the link or accidentally tap the wrong element. CLS problems logged from real visits frequently reveal specific elements – identified by their CSS class names – that are causing shifts on particular pages.
INP – Interaction to Next Paint
INP measures the delay between a user’s interaction (click, tap, key press) and the browser’s next visual update. Google’s threshold for a good INP is under 200 milliseconds. Between 200 and 500 milliseconds is “needs improvement.” Above 500 milliseconds is poor.
INP entered the Core Web Vitals suite as the replacement for FID in March 2024. It captures a broader range of interactions than FID did, making it a more complete picture of real interactivity on your pages. Performance logs from INP failures often point to JavaScript execution blocking the main thread during user interactions.
How BlinkSpeed Collects the Data
Understanding the data collection process helps you interpret the logs more accurately.
When you enable Core Web Vitals logging, BlinkSpeed injects a compact inline script into every page on your site. This script dynamically loads Google’s official web-vitals.iife.js library from BlinkSpeed’s asset directory. Once loaded, the library registers handlers for all three metrics – CLS, LCP, and INP.
These handlers are selective by design. A handler only fires and sends data to your database if the metric rating is not ‘good’. This means your performance logs do not record every page view – they record only the visits where a metric crossed into “needs improvement” or “poor” territory. A page that consistently delivers good scores across all metrics will have no entries in the logs. Only pages with real performance problems generate records.
When a non-good metric fires, the handler serialises the full metric object from the web-vitals library, including entries, values, attribution data, and CSS class names of the offending elements – and sends it via an AJAX POST request to your WordPress database, storing it in the wp_blinkspeed_core_web_vitals table with the page URL, issue type, device type, and timestamp.
This architecture means the logs are noise-free by default. Every entry you see represents a genuine performance problem experienced by a real visitor.
Enabling the Logs
Go to BlinkSpeed → Debug Logs in your WordPress admin. If the Enable Core Web Vitals Logs toggle is off, the panel displays a message: “Enable Debug Log options for Logging.” Until this toggle is turned on, no data is collected, and the log table is not populated.
Turn the toggle on and save. From this point forward, BlinkSpeed begins collecting CWV data from live visitors whose sessions trigger non-good metric events. Give it at least 24–48 hours of traffic before analysing the logs, and longer on lower-traffic sites, to accumulate a statistically meaningful set of entries.
Reading the CWV Report Table
Once logging is enabled and data is accumulating, the log panel displays a table with six columns. Each row represents one metric event from one visitor session on one page.
Column 1 – ID
A sequential integer auto-incremented by the database. This is primarily used by the system to paginate and reference entries internally. You will not typically need to act on the ID value directly, but it is useful when cross-referencing entries you have noted down during an investigation.
Column 2 – URL
The full URL of the page where the metric event occurred. This is the most actionable column in the CWV report. Every performance log entry is tied to a specific page, so you can immediately identify which page needs attention without having to guess or run manual tests.
URLs are stored exactly as the visitor’s browser reported them, including any query string parameters if present. For speed improvement tracking purposes, look for URLs that appear multiple times in the logs – repeated appearances for the same URL indicate a persistent, consistent performance problem rather than a one-off anomaly.
Column 3 – Issue Type
This column shows which Core Web Vitals metric triggered the log entry. Values are:
- LCP – The page has a slow Largest Contentful Paint. The LCP monitoring data in the Data column will show the metric value, rating, element involved, and timing breakdown.
- CLS – The page has layout shift issues. CLS tracking data in the Data column identifies which elements shifted and by how much.
- INP – The page has poor interaction responsiveness. The Data column will show which interaction triggered the event and which element was involved.
Filtering by Issue Type is the most efficient way to focus your speed improvement tracking on a specific problem category.
Column 4 – Device Type
Shows whether the metric event was triggered on Mobile or Desktop. BlinkSpeed determines device type client-side using a User Agent check – if navigator.userAgent matches /Mobi|Android/i, the device is classified as Mobile; otherwise as Desktop.
This column is essential for understanding where your performance problems are concentrated. LCP monitoring data for the same URL may look very different between mobile and desktop. A hero image that loads in 1.8 seconds on desktop might take 4.5 seconds on a mobile device over a 4G connection. Device type filtering lets you prioritise fixes for the channel that matters most for your traffic.
Column 5 – Data
This is the richest column in the table. Each entry shows a truncated JSON preview by default, with a View More button that opens a popover displaying the full pretty-printed JSON payload from the web-vitals library.
The JSON structure varies by metric type but consistently contains:
- name – The metric name (LCP, CLS, INP).
- value – The raw metric value. For LCP and INP, this is in milliseconds. For CLS, it is a unitless decimal score.
- rating – Either “needs-improvement” or “poor”. Since only non-good entries are logged, you will never see “good” here.
- delta – The change in value since the last report. For LCP, this is typically the same as value. For CLS, the delta represents the additional shift accumulated in the reporting window.
- id – A unique string identifier for this metric instance. Useful for deduplicating if the same session sends multiple reports.
- entries – An array of performance entry objects from the browser’s Performance API. For LCP entries, each object includes the element that was the Largest Contentful Paint candidate (stored as the CSS class name via targetElement), its startTime, renderTime, loadTime, size, url (if it was an image), and id. For CLS entries, each object includes.
- sources – an array of shifted elements with their before/after layout rectangles and the CSS class name of the element (targetElement). For INP entries, each object shows the interaction startTime, duration, processingStart, processingEnd, and the targetElement class name.
Column 6 – Time
The timestamp of when the metric event was recorded in your database. Stored in your WordPress server’s local time. Use the date range filter to narrow performance logs to specific time windows – particularly useful for before/after comparisons when evaluating whether a BlinkSpeed settings change has improved your CWV scores.
Using the Filters for Targeted Speed Improvement Tracking
The filter row above the log table contains five controls that let you build precise queries against your performance logs. Learning to combine them effectively turns the log table from a raw data dump into a focused diagnostic tool.
Show (Entries Per Page)
A dropdown that controls how many log rows are displayed per page: 10, 20, 30, 40, or 50. The log table paginates using numbered page buttons with previous/next navigation. When working through a large CWV report dataset, setting this to 50 rows and working page by page gives you the broadest view of patterns.
Issue Type Filter – Isolate LCP, CLS, FID, or INP
This dropdown lets you narrow the table to show only one type of metric at a time. For example, selecting LCP shows you only the pages where loading time is the problem, making it easy to build a ranked list of your slowest-loading pages. Select CLS to focus only on layout shift problems. Select INP to see all responsiveness issues. This is the fastest way to work through one problem type at a time rather than trying to address everything simultaneously.
Device Filter – Mobile vs Desktop
Switches the view between mobile-only and desktop-only entries. Start here if you suspect your site performs differently across devices. It is common to discover that all your LCP monitoring entries come from mobile visitors, which immediately tells you that image file size – not overall server speed – is the priority to fix.
URL Filter – Investigate One Page at a Time
A search field where you can type a specific page address. Once you type the URL, the table refreshes to show only log entries for that exact page. This is the most useful filter when a customer or colleague mentions a specific page feels slow, or when you want to check whether a page you recently updated is now performing better.
Date Range Filter – Compare Before and After Changes
Two date-picker fields (From and To) that let you limit the log view to a specific time window. This is extremely useful for measuring whether a change you made actually helped. Set the “before” date range, note what you see, then set the “after” date range and compare. If your optimisation worked, the volume of log entries for that page should be noticeably lower.
Apply Filters and Clear
After selecting your filter options, click Apply Filters to update the table. Click Clear to reset everything and return to the full unfiltered view.
Managing Log Data – The Delete Function
The Delete Logs dropdown and button let you prune old entries from the wp_blinkspeed_core_web_vitals database table to prevent it from growing indefinitely. Five retention options are available:
- Keep last 7 Days – Deletes all entries older than 7 days
- Keep last 30 Days – Deletes entries older than 30 days
- Keep last 90 Days – Deletes entries older than 90 days
- Keep last 180 Days – Deletes entries older than 180 days
- All – Deletes all entries regardless of date (full table wipe)
BlinkSpeed also runs a background cron job every 24 hours (blinkspeed_delete_core_web_vitals_log) that handles automatic log cleanup based on the retention period you have configured. This means you do not need to manually delete old logs – the cron job manages it, and the manual delete button is available for on-demand cleanup when needed.
Recommended retention strategy:
For most sites, keeping 30 days of data is a sensible default. It gives you enough history to compare before/after improvement periods while keeping the database table size manageable. High-traffic sites generating hundreds of log entries per day may want to reduce this to 7 days. Sites doing active CWV improvement work benefit from keeping 90 days to enable longer comparison windows for speed improvement tracking.
Turning Log Data into Real Speed Improvements
Reading the data is step one. Here is how to act on it.
Find Your Worst-Performing Pages First
Look for URLs that appear more than five times in your logs, especially with a Poor rating in the Data column. These are the pages where the most visitors are having bad experiences. Fix these before worrying about pages that appear only once or twice.
Match the Issue Type to the Right Setting
Your logs are telling you what kind of problem exists. BlinkSpeed’s settings are the solution. Here is how to match them:
LCP monitoring keeps flagging the same page:
Go to BlinkSpeed → Image Optimization and enable WebP conversion for JPG and PNG images. Also check that lazy loading is enabled – but make sure your main banner or hero image is excluded from lazy loading. Deferring the largest above-the-fold image actually makes LCP worse, not better.
CLS tracking shows repeated layout shift issues:
Go to BlinkSpeed → CSS Optimization and look for the “Load Style Tag in Head to Avoid CLS” option. Enabling this makes stylesheets load before the page renders, which eliminates one of the most common causes of layout shift. Also check whether images on the affected pages have defined width and height attributes.
INP entries are common across multiple pages:
Go to BlinkSpeed → JavaScript Optimization and enable Lazyload JavaScript. This delays non-essential scripts until after the page finishes loading, freeing up the browser to respond quickly to visitor clicks. Also enable the Fix INP Issues toggle in the General tab, which tells the browser to prepare connections to external script sources ahead of time.
Clear Cache and Monitor Again
After making changes, clear the BlinkSpeed cache so updated settings apply to all visitors. Then wait at least a week – longer on lower-traffic sites – and review the logs again. Successful optimisations show up as a clear drop in log entries for the pages you worked on. This feedback loop is the core of practical speed improvement tracking.
Performance Logs Settings Reference
| Feature | Location | What It Controls |
|---|---|---|
| Enable Core Web Vitals Logs | Debug Logs tab | Master toggle to start collecting LCP, CLS, INP, FID data |
| Show entries | Debug Logs tab | Rows displayed per page (10–50) |
| Issue Type filter | Debug Logs tab | Filter by LCP, CLS, INP, or FID |
| Device filter | Debug Logs tab | Filter by Mobile or Desktop |
| URL filter | Debug Logs tab | Filter by specific page URLs |
| Date range filter | Debug Logs tab | Filter entries by From/To dates |
| Delete Logs | Debug Logs tab | Prune entries by time window or delete all |
| Auto log cleanup cron | Background | Runs every 24 hours to manage table size |
Summary
BlinkSpeed’s performance logs transform Core Web Vitals from abstract scores into actionable, element-level diagnostics. By collecting real visitor data and storing it per-URL, per-device, and per-metric, the CWV report gives you the specifics needed to fix problems efficiently. LCP monitoring tells you which image is slow and whether it is a network or render issue. CLS tracking names the exact HTML element that is shifting your layout. INP logs measure interaction delay down to the millisecond and attribute it to specific page elements.
Enable the logging toggle, let data accumulate for a few days, then start with the Issue Type filter set to LCP and the Device filter set to Mobile – that combination almost always reveals the highest-priority, highest-impact issues on most WordPress sites. Work through the Data payloads with the View More button, trace the offending elements back to specific BlinkSpeed settings, make the changes, and use the date range filter over the following weeks to verify the improvement in real visitor data.
Frequently Asked Questions Related to BlinkSpeed Core Web Vitals Logs
Q1. Why are there no entries in my performance logs after enabling the setting?
Two common reasons. First, BlinkSpeed only logs non-good metric events – pages that score “good” on all three Core Web Vitals do not generate entries. If your site is genuinely performing well across all pages, the table may stay sparse. Second, logs accumulate from live visitor sessions. If your site has low traffic or you just enabled the setting, give it 48–72 hours before expecting meaningful data. On very low-traffic sites, consider running a few test sessions from mobile devices on slower network throttling settings to seed the logs.
Q2. Does LCP monitoring affect my site’s performance?
The overhead is minimal. BlinkSpeed injects a compact inline script that dynamically loads the web-vitals.iife.js library. The library itself is small (approximately 2KB gzipped) and is loaded asynchronously, meaning it does not block rendering. AJAX requests to save metric data fire only when a non-good metric event occurs, not on every page view. The performance impact on your site is negligible and should not affect the very metrics it is measuring.
Q3. Why does the same URL appear many times in the CWV report?
Each row in the performance logs represents one metric event from one visitor session. If 20 different visitors experienced a poor LCP score on the same page, there will be 20 separate entries for that URL. Repeated appearances for the same URL are actually a signal – they confirm that the problem is consistent and reproducible rather than a one-off. Prioritise URLs with the highest frequency of entries when deciding which pages to fix first.
Q4. Can I filter by both Issue Type and Device at the same time for speed improvement tracking?
Yes. All filters combine additively using AND logic. Selecting LCP from Issue Type and Mobile from Device Type shows only LCP events that occurred on mobile devices. Adding a URL filter on top of that narrows to LCP mobile events on a specific page. This three-filter combination is the most targeted approach for diagnosing a specific page’s mobile LCP problem with real visitor data.
Q5. What does CLS tracking data tell me that Google Search Console does not?
Google Search Console’s Core Web Vitals report shows field data aggregated at the page group level with a 28-day rolling window. It tells you that a page group is failing CLS but not which specific element is causing the shift, and not whether the shift is more severe on mobile or desktop. BlinkSpeed’s CLS tracking logs the CSS class name of the shifting element, the device type, and the exact timestamp, giving you the specific HTML element to fix rather than just a failing score to investigate.
Q6. How long should I wait after making changes before checking the performance logs for improvement?
The logs reflect real visitor data, so the delay depends on your traffic volume. On high-traffic sites (thousands of daily visitors), meaningful before/after data may be visible within 3–5 days. On medium-traffic sites, allow 1–2 weeks. On low-traffic sites, allow 2–4 weeks. Use the date range filter to compare equivalent time windows before and after your change. Also check Google Search Console’s Core Web Vitals report after 28 days – it operates on a rolling 28-day window, so a fix made today will take up to 28 days to fully reflect in the GSC report.
Q7. Does deleting log entries affect my site in any way?
No. The wp_blinkspeed_core_web_vitals table stores diagnostic data only and is not referenced by any frontend output or caching logic. Deleting entries frees database space and keeps query performance fast as the table shrinks, but has no effect on your site’s frontend behaviour, cached pages, or any BlinkSpeed optimization features.
