Author: onetwothreeadmin

Most WordPress performance issues trace back to database queries. A plugin runs a suboptimal SELECT, your homepage load time jumps from 800ms to 4.2 seconds, and you’re left guessing which of your 23 active plugins is responsible.

MySQL’s slow_query_log is the diagnostic tool that ends the guessing. It records every query that exceeds a time threshold you set—usually one or two seconds. The log tells you exactly which SQL statement ran, how long it took, and which rows it examined.

Here’s how to turn it on, read the output, and use it to fix the query that’s killing your site speed.

Enabling slow_query_log on your WordPress host

Most managed WordPress hosts disable direct my.cnf access, but many expose slow query logging through their dashboard. BigScoots, for example, lets you toggle it on via cPanel’s MySQL configuration panel. If you’re on a VPS or dedicated server, you’ll edit the MySQL config file directly.

Add these lines to /etc/mysql/my.cnf (or /etc/my.cnf depending on your distro):

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 1

The long_query_time value is in seconds. Setting it to 1 captures anything longer than one second. For high-traffic sites, you might start at 2 to reduce noise.

Restart MySQL: sudo systemctl restart mysql

Queries now log to /var/log/mysql/slow-query.log. If the file doesn’t exist, MySQL will create it on the first slow query.

Reading the log: what the output actually means

Open the log file. Each slow query entry looks like this:

# Time: 2026-08-30T14:22:35.442891Z
# User@Host: wpuser[wpuser] @ localhost []
# Query_time: 3.204571 Lock_time: 0.000312 Rows_sent: 1847 Rows_examined: 124503
SELECT * FROM wp_posts WHERE post_status = 'publish' ORDER BY post_date DESC;

Here’s what matters:

• Query_time: Total execution time in seconds. This query took 3.2 seconds.
• Lock_time: Time waiting for table locks. Usually negligible unless you’re running MyISAM tables (you shouldn’t be).
• Rows_sent: How many rows the query returned. Here, 1,847.
• Rows_examined: How many rows MySQL scanned to build that result. Here, 124,503. That’s a 67:1 examination-to-return ratio—terrible efficiency.

The query itself follows. In this case, it’s a broad SELECT * with no LIMIT clause, scanning every published post.

Identifying the plugin or theme responsible

The slow query log shows the SQL, but not which PHP file triggered it. To trace that, enable WordPress’s SAVEQUERIES constant in wp-config.php:

define('SAVEQUERIES', true);

Install the Query Monitor plugin. It cross-references the slow queries with the calling function, showing you the exact plugin or theme file responsible.

In most cases, you’ll find one of three culprits:

• A poorly-coded custom query in a theme’s functions.php
• An analytics or “related posts” plugin running uncached lookups on every page load
• A WooCommerce or membership plugin querying order or user meta without indexes

Once you’ve identified the source, you have three options: optimize the query, cache the result, or replace the plugin.

One non-obvious tip: check Rows_examined even for fast queries

A query might finish in 0.8 seconds—just under your long_query_time threshold—but still examine 200,000 rows to return 12. That’s inefficient, and it will degrade as your database grows.

Manually review your site’s most-used queries with Query Monitor’s “Queries by Component” view, sorted by row examination count. If any query examines more than 10x the rows it returns, add an index or rewrite it.

Run EXPLAIN on the suspect query in phpMyAdmin or the MySQL command line to see which indexes MySQL is using (or ignoring). If the “type” column shows “ALL,” you’re doing a full table scan—add an index on the columns in your WHERE or ORDER BY clause.

Want more infrastructure deep-dives like this? Subscribe to One Two Three Send—every article covers one specific tool, feature, or workflow decision for solo operators running content businesses.

WordPress enabled native lazy loading by default in 2020, and most operators never think about it again. The browser handles it, images load as users scroll, and Core Web Vitals improve. Simple.

Except lazy loading doesn’t work the same way on mobile and desktop. The threshold that triggers an image to start loading—called the “distance-from-viewport” threshold—varies by browser, device type, and connection speed. That inconsistency affects how fast your site feels, even when the technical metrics look fine.

How lazy loading thresholds actually work

When WordPress adds loading="lazy" to an image, it’s telling the browser: don’t load this until the user is about to see it. But “about to see it” isn’t a fixed distance.

Chrome and Edge use a threshold of roughly 1250 pixels on desktop with a fast connection. That means an image starts loading when it’s still more than a full screen away. On mobile, that threshold drops to around 2500 pixels—proportionally much larger relative to viewport height, but still about two to three scroll lengths.

On slower connections (defined by the browser’s effectiveType API), those thresholds shrink. Chrome drops to around 2500 pixels on desktop and 1250 pixels on mobile when it detects 3G speeds.

Firefox uses similar logic but calculates thresholds as a multiplier of viewport height rather than fixed pixels. Safari’s implementation is more conservative across the board.

The result: the same page can trigger image loads at wildly different scroll positions depending on device and connection. A hero image that loads instantly on desktop might not even start fetching until a mobile user scrolls halfway down the page.

Where this breaks perceived performance

Lazy loading improves Largest Contentful Paint (LCP) and Total Blocking Time by deferring offscreen images. But it can hurt perceived speed if critical above-the-fold images get lazy-loaded by mistake.

WordPress excludes the first image in the content from lazy loading, but that heuristic fails when:

• Your hero image is a background image in CSS, not an <img> tag
• Your layout uses a sidebar, and the “first” image is a small thumbnail in the sidebar, not the main content image
• You’re using a page builder that injects images via JavaScript after initial render

On mobile, where thresholds are proportionally larger, users scroll faster and notice the delay more. An image that starts loading at 2500 pixels might not finish rendering before the user reaches it, especially on slower devices or connections.

This is why some sites feel faster on desktop even when mobile scores higher in Lighthouse. The lazy loading threshold mismatch creates a perception gap that metrics don’t fully capture.

How to adjust lazy loading behavior

You can’t directly control browser thresholds, but you can control which images get the loading="lazy" attribute.

The simplest fix: remove lazy loading from above-the-fold images. WordPress provides a filter to exclude specific images:

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

That disables it globally, which is overkill. Instead, target specific images by hooking into wp_get_attachment_image_attributes and removing the loading attribute for images in the first few blocks or above a certain position in the DOM.

Most page builders and themes offer a “disable lazy loading” toggle for hero sections. Use it. The performance cost of eagerly loading one or two large images is trivial compared to the perceived-speed hit of lazy-loading them incorrectly.

For mobile-specific tuning, consider using the fetchpriority="high" attribute on your primary hero image. It’s supported in Chrome, Edge, and Safari, and it tells the browser to prioritize that image even if lazy loading would otherwise delay it. WordPress doesn’t add this by default, but you can inject it via the same attribute filter.

Test with real throttling, not just Lighthouse

Lighthouse simulates a slow connection, but it doesn’t show you the scroll-and-wait behavior real users experience. Open Chrome DevTools, switch to the Network tab, and throttle to “Slow 3G.” Then actually scroll your site on a mobile viewport.

Watch where images start loading. If they’re popping in after you’ve scrolled past them, your thresholds are too conservative or your images are too large. If they’re all loading at once on page load, you’re not benefiting from lazy loading at all.

Run the same test on desktop. The behavior should be noticeably different. If it’s not, you might have a plugin overriding WordPress’s native implementation with a JavaScript-based lazy loader—those usually use fixed thresholds regardless of device.

Most solo operators optimize for Lighthouse scores and call it done. But perceived speed matters more than any single metric, and lazy loading thresholds are one of the few variables that affect perception without showing up in reports.

Reply with the laziest-loading image you’ve ever encountered. We’re collecting examples for a follow-up piece on edge cases that break WordPress’s heuristics.