Speedix Help Center

After installing Speedix, go to Tools > Speedix. The Speedix Setup wizard opens the first time. Choose a profiling mode (we recommend Balanced), select the pages to profile, and finish. Profiling then runs on those pages. If you skipped the wizard, open the Settings tab and turn profiling on.

For best results:

• Add your homepage and 2-3 important pages under "Pages to Profile"
• Let it run for at least 15-30 minutes to gather meaningful data
• Visit the pages you added to generate profiling data

Step 1: Initial Assessment - Start with Balanced preset to identify which plugins consume the most time. Run for 30 minutes to 1 hour.

Step 2: Deep Dive - If you find a problematic plugin, switch to Detailed mode temporarily to see exactly which hooks are slow.

Step 3: Take Action - Either disable/replace slow plugins, contact the developer, or accept the tradeoff if the plugin is essential.

Step 4: Ongoing Monitoring - Switch to Safe Mode for continuous monitoring with minimal overhead. This helps catch regressions after updates.

Focus on pages that matter most for your site's performance:

• Homepage - Usually the most visited page
• Main landing pages - Product pages, service pages
• WooCommerce pages - Shop page, cart, checkout (if applicable)
• Blog archive - If you have a blog

You don't need to add every page. 3-5 key pages give you a good picture of overall performance.

Minimal impact when configured properly. Profiling does add some work to the requests it measures, and how much depends on the preset:

• Safe Mode: profiles 10% of requests, records only slow hooks (5 ms and up) and skips plugin identification. Built for production
• Balanced: profiles 25% of requests and identifies the plugin behind each slow hook
• Detailed: profiles every request with a 1 ms threshold. More overhead and more database writes, so use it temporarily

Hook profiling is skipped on unsampled requests; lightweight response-time tracking and the small Frontend Timing script (about 2 KB) still run for visitors, and Frontend Timing can be switched off in Settings. At a 25% sample rate, only 1 in 4 requests is hook-profiled.

If overhead ever gets too high, overload protection pauses profiling automatically.

No. Speedix uses read-only profiling with built-in safety limits. If overhead gets too high, it automatically pauses for 1 hour. You can also turn profiling off at any time in Settings.

Yes, especially in Safe Mode. The sample rate means only 10-25% of requests are profiled, and overload protection prevents a performance impact.

Frontend Timing collects timing data from your visitors' browsers using the browser's Performance APIs. Speedix records:

• FCP (First Contentful Paint) - When the first text or image appears. Google rates under 1.8 s as good
• LCP (Largest Contentful Paint) - When the largest content element is visible. Google rates under 2.5 s as good
• DOM Ready - When the HTML is fully parsed
• Load - When the page and its resources have loaded

LCP is one of Google's Core Web Vitals. FCP is a supporting diagnostic, and DOM Ready and Load are general timings. INP and CLS, the other Core Web Vitals, are not measured. Speedix splits the results into desktop and mobile visitors so you can spot device-specific problems.

Frontend Timing is on by default. To check or change it:

• Go to Tools > Speedix > Settings
• Find the "Frontend Timing" checkbox
• Tick it to collect browser metrics, untick it to stop

Speedix adds a small script (about 2 KB gzipped) to your pages. It sends the timing data to your own site with sendBeacon(), so nothing goes to a third party.

The Frontend Timing card shows desktop and mobile results side by side for each metric. Speedix tells them apart by the visitor's user agent, not by screen size.

This helps identify mobile-specific performance issues. Mobile is often slower due to slower network connections and less powerful devices. Click the chart icon to see full history with trend lines.

Yes! Unlike server-side profiling which gets bypassed by page caching, Frontend Timing works on cached pages because it measures from the browser perspective.

Speedix also records whether a page load looked cached, using the Navigation Timing API (for example when no bytes were transferred, or the HTML was generated several seconds before the visit), so you can tell the difference.

Google's Core Web Vitals thresholds for LCP:

• Good: <2.5 seconds
• Needs Improvement: 2.5-4 seconds
• Poor: >4 seconds

Common causes of slow LCP on WordPress:

• Large unoptimized hero images
• Slow server response (TTFB)
• Render-blocking JavaScript and CSS
• Web fonts loading slowly

Focus on server response time (TTFB) first, then optimize the largest content element (usually a hero image or heading). TTFB is general web-performance advice here: it is not one of the metrics Speedix's Frontend Timing records.

The 22-point Site Health Scan looks for database bloat, configuration problems and PHP settings that slow a site down.

Database cleanup (10 checks):

• Post revisions
• Orphaned post meta
• Orphaned comment meta
• Expired transients
• Spam comments
• Trashed posts
• Old drafts
• Orphaned term relationships
• Expired user sessions
• Action Scheduler history

Database size and loading (4 checks):

• Database size
• Autoload size and number of autoloaded options
• Autoloaded transients
• Total number of options

Site configuration (6 checks):

• Cron jobs, overdue and total
• Rewrite rules
• Active plugins
• Registered post types
• Registered taxonomies
• Registered image sizes

PHP (2 checks):

• OPcache status
• PHP version and settings, including the memory limit

Per-request numbers such as memory use, output buffer size, included files, translation text domains, JS and CSS file counts, CPU time and the SAVEQUERIES constant are live metrics in the dashboard's System Status. They are not part of the scan.

Speedix runs the scan once a day on its own and keeps the latest result. You can also run it yourself:

• Dashboard - Open the Site Health Scan and click Scan Now
• Setup wizard - Tick "Run initial scan now" on the last step

After scanning, you can:

• Email - Send the results to your own account email
• Copy - Copy the report to the clipboard for sharing or documentation

Autoload bloat occurs when too much data is loaded into memory on every page request from the wp_options table.

The Site Health Scan reports it as:
Warning: more than 500 autoloaded options or more than 800 KB
Critical: more than 1,000 options or more than 1,000 KB

Common causes:

• Plugins storing large serialized arrays as options
• Abandoned plugin settings left behind
• Transients that should be using the object cache

How to fix:

• Use a database cleanup plugin (WP-Optimize, Advanced Database Cleaner)
• Review plugins with large option values
• Enable object caching (Redis/Memcached) to offload transients

Speedix counts the JS and CSS files enqueued on a page and lowers the Health Score when the total passes these levels:

• Good: 25 combined JS and CSS files or fewer
• Warning: more than 25 files - consider consolidating
• Concerning: more than 40 files - likely hurting performance
• Critical: more than 60 files - significant HTTP overhead

Tips to reduce:

• Use an asset optimization plugin (Autoptimize, WP Rocket)
• Disable unused plugin features that load extra scripts
• Review the Assets modal to see which plugins add the most files

Yes. You can turn on a daily Site Health report:

• Go to Tools > Speedix > Settings
• Under "Site Health", tick "Email Reports"
• Reports are sent to the admin email address

The email is an HTML report of the scan results, sorted by severity. It helps you catch issues, like a growing autoload size or OPcache problems, before they affect visitors.

Safe Mode (10% sample rate, 5 ms threshold, plugin identification off)

• Best for production sites running 24/7
• Lowest overhead of the three presets - safe for high-traffic sites
• Only captures the slowest hooks
• No Reflection overhead (plugin identification disabled)
• Less data stored = can use longer retention periods

Balanced (25% sample rate, 2 ms threshold, plugin identification on)

• Recommended starting point for most users
• Shows which plugins cause slowdowns
• Moderate overhead
• Good balance of data volume and insight

Detailed (100% sample rate, 1 ms threshold, plugin identification on)

• For deep debugging sessions only
• Captures many more hooks than the other presets
• Higher overhead and more database writes
• Use temporarily, then switch back

The threshold is the minimum execution time (in milliseconds) a hook must take to be logged. Hooks faster than this are ignored.

A general guide (the presets set the value for you: Safe 5 ms, Balanced 2 ms, Detailed 1 ms):

• 1 ms or lower - Captures many more hooks. Use for detailed debugging.
• 2 ms - A good balance for general use.
• 5 ms - Only slow hooks. Best for production monitoring.
• 10 ms or more - Only the slowest hooks. Use on high-traffic sites.

Click the Auto button next to the threshold to let Speedix recommend a value from a profile of your homepage. See "How does Auto-Calibrate work?" below.

Sample rate controls what percentage of requests are profiled:

• 100% - Every request is profiled
• 25% - 1 in 4 requests profiled (the other 75% are not profiled)
• 10% - 1 in 10 requests profiled (the other 90% are not profiled)

Lower sample rates mean:

• Less overall impact on site performance
• Less data stored in the database
• May need more time to gather meaningful statistics

For most sites, 25% gives good data while keeping overhead low. Use 10% on high-traffic production sites.

Plugin identification (the "Plugin Attribution" setting) uses PHP Reflection to trace each hook callback back to its source file, then maps that to a plugin, theme, or WordPress Core.

Benefits:

• See exactly which plugin registered each slow hook
• Get "By Plugin" breakdown showing total time per plugin
• Essential for identifying which plugins to optimize

Trade-offs:

• Adds some overhead to each profiled request
• Results are cached to minimize repeat overhead

Recommendation: Enable it when actively optimizing (Balanced/Detailed modes). Disable it for lightweight ongoing monitoring (Safe Mode).

Auto-Calibrate profiles a homepage request and recommends a threshold. Click the Auto button next to the threshold in Settings; the result appears as "Auto-Detect Results".

How it calculates the threshold:

• Measures how long the homepage request takes
• Takes 1% of that time
• Compares it with the 90th percentile of the hook times captured in that request
• Uses the higher value, clamps it to 1-10 ms and rounds it to a whole millisecond

Example: A 400 ms homepage gives a 4 ms threshold, unless the 90th percentile of hook times is higher. This keeps the log to hooks that make up a meaningful part of the response time.

Speedix supports retention periods from 1 hour to 7 days.

Recommendations:

• 1-6 hours - For active debugging sessions
• 24 hours - For day-to-day monitoring (default)
• 3-7 days - For tracking trends and comparing before/after changes

Longer retention means more database storage. If you're using Safe Mode with low sample rate, you can safely use 7 days. The setup wizard sets 12, 24 or 48 hours for Safe, Balanced and Detailed; the default is 24 hours.

Response time targets for WordPress/WooCommerce sites:

• <200ms - Excellent. Very fast site.
• 200-500ms - Good. Acceptable for most sites.
• 500ms-1s - Needs improvement. Look for slow plugins.
• >1s - Slow. Prioritize optimization.

Note: These are server response times (how long WordPress takes to build the page), not total page load time. They don't include frontend rendering, JavaScript execution, or asset loading.

This is completely normal. WordPress Core handles essential functions like:

• Database initialization and queries
• User authentication and sessions
• Loading plugins and themes
• Template hierarchy and rendering
• Asset enqueuing

Core usually accounts for a large share of hook time, even on a healthy site. Focus on:

• Third-party plugins using a large share of hook time (for example more than 10%)
• Plugins you can live without or replace
• Specific hooks that are unexpectedly slow

By Hook shows individual WordPress hooks (actions/filters) sorted by execution time:

• See which specific hooks are slow
• Shows which plugin(s) have callbacks on each hook
• Useful for debugging specific performance issues

By Plugin aggregates all hooks by their source plugin:

• See total time consumed by each plugin
• Quick overview of which plugins need attention
• Percentage breakdown for easy comparison

Start with "By Plugin" to identify problematic plugins, then switch to "By Hook" for detailed analysis.

The Health Score (0-100) is a quick performance read-out. It starts at 100 and loses points for:

• Slow average response time (from 1 second up)
• Slow hooks (averaging more than 10 ms, with a bigger penalty above 50 ms)
• Plugins taking more than 80% of hook time
• Large autoload size or too many autoloaded options, and autoloaded transients
• Requests that timed out
• More than 25 enqueued JS and CSS files

The card reads Good at 80 and above, Needs work from 50 to 79, and Poor below 50. The Site Health score is a separate number that comes from the Site Health Scan.

DB Time - Time spent on database queries. DB Time and query counts appear only when SAVEQUERIES is set to true in wp-config.php. High DB time indicates:

• Too many queries per page
• Slow or unoptimized queries
• Missing database indexes
• Consider enabling object caching (Redis/Memcached)

HTTP Time - Time spent on external HTTP requests. High HTTP time indicates:

• Plugins making API calls during page load
• Remote services your server calls during the page load (licence, update, payment or shipping checks)
• Slow third-party APIs
• Consider caching external API responses

The Hotspots card shows your three slowest hooks at a glance, out of the hooks that average at least 1 ms. They are the hooks with the highest average execution time. If every hook is under 1 ms, the card says so.

Hotspots help you:

• Quickly identify the biggest performance bottlenecks
• Prioritize which areas to investigate first
• Track if optimizations are working (hotspots should improve)

Hover a hotspot to see the full hook name, then find it in the By Hook tab.

The External APIs section lists slow server-side HTTP requests (50 ms or longer) that WordPress makes during page loads, for example licence and update checks, payment, shipping and other remote APIs.

The dashboard shows:

• Grouped by hostname - See which external services are being called
• Unique endpoints - Number of different API paths per host
• Call count, average time, max time - Performance metrics
• Error count - Failed API calls highlighted in red

Click any host row to expand and see individual endpoints. Click the chart icon to view historical trends for any API endpoint.

Why it matters: External API calls are often the biggest source of slow page loads because they depend on network latency and third-party server response times. Identifying slow APIs helps you decide what to cache, defer, or replace.

History Charts let you see performance trends over time. Click the chart icon on any metric card or table row to open the history modal.

Available history views:

• Response Time - Overall server response with min/max/avg lines
• Page-specific - Response time for individual profiled pages
• Plugin - Time spent in a specific plugin over time
• Hook - Execution time trends for individual hooks
• Memory - Peak memory usage trends
• OPcache - Hit rate and memory usage percentage
• Database - Query time and count trends
• External API - Individual API endpoint response times

Time ranges: from 1 hour up to 7 days, depending on your retention setting.

Summary stats: Each chart shows summary statistics (average, min, max, total) for the selected period.

Use history charts to spot patterns (e.g., slowdowns during peak traffic), verify that optimizations worked, and track long-term trends.

OPcache is PHP's built-in bytecode cache that dramatically speeds up PHP execution by caching compiled scripts.

Speedix tracks:

• Hit Rate - Percentage of script requests served from cache (higher is better, aim for 95%+)
• Memory Usage - How much of OPcache's allocated memory is used
• Cached Scripts - Number of scripts currently in the cache

What to look for:

• Low hit rate (<90%) - Cache may be too small or being invalidated too frequently
• Memory near 100% - OPcache is full; scripts are being evicted. Increase opcache.memory_consumption
• Hit rate fluctuations - May indicate deployments, cache resets, or configuration issues

Click the OPcache card to view historical trends showing hit rate and memory usage over time.

When WooCommerce is active, Speedix automatically adds a dedicated WooCommerce tab that categorizes hooks by commerce area:

• Checkout - woocommerce_checkout_*, woocommerce_review_order*
• Cart - woocommerce_cart_*, woocommerce_add_to_cart*
• Products - woocommerce_product_*, woocommerce_single_product*
• Orders - woocommerce_order_*, woocommerce_new_order*
• Shipping - woocommerce_shipping_*, woocommerce_package_rates*
• Payment - woocommerce_payment_*, woocommerce_available_payment_gateways*
• Subscriptions - woocommerce_subscription_*, wcs_*
• Memberships - wc_memberships_*, woocommerce_memberships_*
• Blocks - woocommerce_blocks_*, woocommerce_store_api_*

For WooCommerce stores, add these pages to your profiled pages list:

• Shop page - Main product listing (/shop/)
• Single product - A representative product page
• Cart - The cart page (/cart/)
• Checkout - The checkout page (/checkout/)
• My Account - Customer account area (if logged-in performance matters)

Checkout and cart are often the slowest due to shipping calculations, payment gateway initialization, and cart validations.

Checkout is often the slowest page because it involves:

• Shipping rate calculations - API calls to carriers
• Payment gateway loading - External scripts and validation
• Cart validation - Stock checks, coupon validation
• Address validation - Some plugins validate addresses via API

Optimization tips:

• Cache shipping rates where possible
• Limit active payment gateways to those you actually use
• Disable checkout plugins you don't need
• Consider using the WooCommerce Blocks checkout for better performance

Overload protection automatically pauses profiling when overhead gets too high. This protects your site from performance degradation.

When it triggers:

• Profiling pauses after 5 consecutive requests where profiling overhead exceeds 20% of request time or 100 ms

What happens:

• Profiling pauses automatically
• A notice appears on the dashboard explaining why
• Profiling resumes automatically after 1 hour
• You can reset it by hand and re-enable profiling with a different preset

Solution: Switch to the Safe Mode preset, which has much lower overhead, or reduce the sample rate.

Server load: A high server load average (over 5) only shows a warning on the dashboard. It does not pause profiling, but Safe Mode is a good choice until the load drops.

Common causes for no data appearing:

• Profiling not enabled - Check that profiling is turned on in Settings
• Full-page caching - Cached responses don't run PHP, so nothing is profiled
• Time range filter - Try a longer range such as Last 24 hours or Last 7 days
• No traffic - Visit the profiled pages to generate data
• Sample rate - At 10% sample rate, you need ~10 visits to get one profiled request
• Threshold too high - If all hooks are faster than your threshold, nothing is logged

Some variation is normal. Server response time varies due to:

• Server load - Other processes competing for resources
• Database caching - First request may be slower (cold cache)
• OPcache state - Fresh cache vs warmed cache
• External APIs - Network latency varies
• Content differences - Different query parameters, logged-in state

For accurate results:

• Let profiling run for at least 30 minutes
• Look at average times rather than individual requests
• Profile during typical traffic periods
• Test with page caching disabled to see true PHP time

Speedix shows environment notices to help you understand factors affecting results:

OPcache and autoload size - These checks are shown in System Status and the Site Health Scan, not as dashboard notices. Without OPcache, PHP code is compiled every request, so enabling it makes PHP much faster.

WP_DEBUG is enabled - Debug mode adds overhead. Results will be slower than production. This is expected.

Xdebug is active - Xdebug significantly slows PHP. Disable it for accurate benchmarks.

SAVEQUERIES is enabled - SAVEQUERIES adds overhead but is required for database time, so enable it while investigating.

Low memory limit - Profiling many hooks may hit memory limits. Consider increasing to 128M+.

Full-page caching detected - Cached pages won't be profiled. This is expected behavior.

There are several reset options:

Clear data only: Use the "Clear Speedix Data" button in Settings. It deletes only the performance statistics Speedix collected and keeps your settings. Your posts, pages, WooCommerce products and orders are never touched.

Reset settings: Use "Reset to Defaults" in Settings to restore the default configuration. This also restarts the setup wizard.

Setup wizard again: Deactivate and reactivate the plugin to see the Speedix Setup wizard again. Your settings are kept.

Complete removal: Deactivate and delete the plugin. This removes all data, settings, and database tables.

Check these in order:

1. Is profiling enabled? The toggle must be on in Settings.
2. Is the page whitelisted? Only pages in "Pages to Profile" are tracked.
3. Is the sample rate too low? At 25%, only 1 in 4 requests is profiled. Set it to 100% for testing.
4. Is the threshold too high? Set it to 0 ms temporarily to capture all hooks.
5. Are you visiting the right page? Make sure it is in your whitelist.

Turn on "Plugin Attribution" in Settings. Without it, hooks are captured but not attributed to specific plugins. Safe Mode leaves it off.

It appears when callbacks can't be traced to source files. Common causes are anonymous closures, dynamically generated functions, or code outside the plugin and theme directories.

Speedix uses WordPress's all hook to capture every action and filter as it fires. Here's the process:

• Registers on the all hook at priority -999999 (start) and 999999 (end)
• Uses hrtime(true) for nanosecond precision timing
• Measures time between hook start and hook end
• Only logs hooks that exceed the threshold setting
• Batches all data and writes to the database once at shutdown

When plugin identification is enabled, Speedix:

• Uses PHP's ReflectionFunction or ReflectionMethod on each callback
• Gets the source file path from the reflection
• Maps the file path to a plugin folder, theme, or Core
• Caches results persistently to avoid repeat Reflection calls

The cache stores up to 500 callback-to-plugin mappings. This keeps repeat overhead low after the initial discovery.

Speedix creates four custom database tables:

• wp_speedix_stats - Hook-level timing data with plugin attribution
• wp_speedix_stats_plugins - Pre-aggregated plugin totals for faster dashboard queries
• wp_speedix_responses - Response time, memory, OPcache, and DB metrics history
• wp_speedix_http_log - External API call tracking by host and endpoint

Data is aggregated by minute to reduce the number of rows. A cron job runs hourly to clean up data older than the retention period.

All tables are removed when the plugin is uninstalled (deleted, not just deactivated).

Minimum requirements:

• WordPress 6.3 or higher
• PHP 8.0 or higher

Tested up to:

• WordPress 7.1
• PHP 8.5
• WooCommerce 11.0 (optional, for the WooCommerce tab)

Speedix 2.1.9 raised the minimum PHP version from 7.4 to 8.0, because the plugin already used PHP 8.0 syntax.

Yes. Each site keeps its own profiling data. Network admins can open the dashboard on any site.

Yes, Speedix supports multiple export formats:

• CSV - For spreadsheet analysis in Excel, Google Sheets
• JSON - For programmatic processing and integration
• Markdown - For documentation and reports

Click the export icon in the dashboard toolbar and choose Hooks (CSV), Plugins (CSV), All Data (JSON) or Report (Markdown).

Yes, Speedix is fully compatible with object caching solutions. When object caching is enabled:

• Hook timing remains accurate
• Database-related hooks may show faster times (this is the benefit of caching working)
• A notice appears indicating object cache is active

Object caching is recommended for database-heavy WordPress sites and doesn't interfere with profiling.

Debugging plugins show detailed information about the current request. Speedix takes a different approach: it aggregates performance data over time to find persistent slow spots and trends across many page loads.

The profiler measures uncached PHP execution. Cached pages bypass PHP entirely and won't appear in profiles. This is expected, since cached pages are already optimized. Frontend Timing, which measures in the browser, can still report on cached pages.