Help Center & FAQ

After installing Speedix, go to Tools > Speedix. You'll see the Quick Setup wizard on first launch. Choose a preset (we recommend starting with "Balanced"), then click "Start Profiling". The plugin will begin collecting data immediately.

For best results:

• Add your homepage and 2-3 important pages to the profiled pages list
• 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.

Speedix is designed to be lightweight, but there is some overhead:

• Safe Mode: <1ms overhead - negligible impact
• Balanced: ~2-3ms overhead - minimal impact
• Detailed: ~5-10ms overhead - noticeable but acceptable for debugging

Additionally, sample rate reduces the percentage of requests that are profiled. At 25% sample rate, only 1 in 4 requests is profiled.

If overhead ever gets too high, the overload protection automatically pauses profiling to protect your site.

Frontend Timing tracks real user experience metrics directly from the browser using the Performance API. These metrics directly align with Google's Core Web Vitals:

• FCP (First Contentful Paint) - When the first text or image appears. Good: <1.8s
• LCP (Largest Contentful Paint) - When the largest content element is visible. Good: <2.5s
• TTFB (Time To First Byte) - Server response time. Good: <200ms
• DOM Ready - When DOM is fully parsed
• Load - When all resources are fully loaded

These metrics impact your Google rankings and user experience. Speedix shows desktop vs mobile comparisons to identify device-specific issues.

Frontend Timing is enabled by default for new installations (v2.1.0+). To check or toggle:

• Go to Tools > Speedix > Settings
• Find the "Frontend Timing" toggle in Extended Metrics section
• Enable it to start collecting browser metrics

Speedix injects a small JavaScript beacon (<2KB) that sends timing data via sendBeacon() with minimal performance impact.

The Frontend Timing card shows side-by-side comparison bars for each metric:

• Blue bars = Desktop visitors
• Purple bars = Mobile visitors

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 even detects when a page was served from cache using the Navigation Timing API (when transferSize=0 and response is very fast). The dashboard marks cached page loads so you can see 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 TTFB first (server-side), then optimize the largest content element (usually a hero image or heading).

The 22-point Site Health Scan runs comprehensive diagnostics:

Database Checks:

• Autoload options size (warns if >900KB)
• Total option count
• Post/user/term/comment meta bloat
• Post revisions count
• Transient bloat

Configuration Checks:

• PHP version (warns if <8.0)
• OPcache enabled and memory usage
• SAVEQUERIES constant (overhead warning)
• Action Scheduler completed actions

Performance Checks:

• Memory limit usage percentage
• Output buffer size (HTML bloat)
• Included PHP files count
• Textdomain (translation) count
• Enqueued JS/CSS files (warns at 25+, 40+, 60+)
• CPU time (user and system)

You can trigger a Site Health Scan in several ways:

• Quick Scan button - Click the scan icon on the Health Score card
• Setup Wizard - Runs automatically when completing the wizard
• Settings - Enable daily automated reports

After scanning, you can:

• Email Report - Send results to admin email
• Copy to 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.

Healthy: <500KB autoload size
Warning: 500KB-900KB
Critical: >900KB

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 uses these thresholds for enqueued scripts and stylesheets:

• Good: <25 combined JS+CSS files
• Warning: 25-40 files - consider consolidating
• Concerning: 40-60 files - likely hurting performance
• Critical: >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 enable daily automated Site Health reports:

• Go to Tools > Speedix > Settings
• Enable "Daily Site Health Email"
• Reports are sent to the admin email address

The email includes a mobile-responsive HTML report with all 22 diagnostic checks, color-coded by severity. This helps you catch issues (like growing autoload size or OPcache problems) before they impact users.

Safe Mode (10% sample rate, 2ms threshold, Plugin ID off)

• Best for production sites running 24/7
• Minimal overhead (<1ms) - 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, 1ms threshold, Plugin ID on)

• Recommended starting point for most users
• Shows which plugins cause slowdowns
• Moderate overhead (~2-3ms)
• Good balance of data volume and insight

Detailed (100% sample rate, 0.5ms threshold, Plugin ID on)

• For deep debugging sessions only
• Captures nearly all hooks
• Higher overhead (~5-10ms) and more DB 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.

Guidelines:

• 0.5ms - Captures most hooks. Use for detailed debugging.
• 1.0ms - Good balance. Recommended for general use.
• 2.0ms - Only slow hooks. Best for production monitoring.
• 5.0ms+ - Only the slowest hooks. Use on high-traffic sites.

Use the Auto-Calibrate button to let Speedix analyze your site and recommend an optimal threshold based on your actual performance data.

Sample rate controls what percentage of requests are profiled:

• 100% - Every request is profiled
• 25% - 1 in 4 requests profiled (75% have zero overhead)
• 10% - 1 in 10 requests profiled (90% have zero overhead)

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 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 ~1-2ms overhead per 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 your homepage multiple times and analyzes the results to recommend optimal settings.

How it calculates the threshold:

• Measures your average response time
• Calculates a threshold as 0.5% of that response time
• Compares with the 95th percentile of actual hook times
• Takes the higher value and clamps it between 0.5ms and 5.0ms

Example: If your homepage takes 400ms on average, the threshold would be ~2.0ms. This ensures you only capture hooks that represent a meaningful portion of 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. With Detailed mode, keep it shorter (1-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 (TTFB), 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 typically uses 40-60% of hook time on a healthy site. Focus on:

• Third-party plugins using >10% of hook time
• 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) gives you a quick performance assessment based on average response time:

• 90-100 - Excellent performance
• 70-89 - Good performance
• 50-69 - Needs improvement
• Below 50 - Poor performance, needs attention

The score is calculated relative to a 200ms baseline for excellent performance and scales down as response time increases.

DB Time - Time spent on database queries. 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
• External services (analytics, fonts, etc.)
• Slow third-party APIs
• Consider caching external API responses

The Hotspots card shows your top 5 slowest hooks at a glance. These are the hooks with the highest average execution time.

Hotspots help you:

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

Click on any hotspot to see full details in the By Hook view.

The External APIs section tracks all HTTP requests your WordPress site makes to third-party services during page loads. This includes:

• Plugin license checks and update checks
• Payment gateway API calls
• Shipping rate calculations
• Social media embeds and API calls
• Analytics and tracking services
• Any external REST API integrations

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 range options: 1 hour, 2 hours, 6 hours, 24 hours, 3 days, 7 days

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:

• Multiple consecutive requests have profiling overhead >10% of request time
• Server load is very high (load average check)

What happens:

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

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

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 selecting "All time" or a wider range
• 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 not enabled - Without OPcache, PHP code is compiled every request. Enable OPcache for much faster performance (and more accurate profiling).

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 - Query logging adds overhead. Consider disabling for profiling.

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 All Data" button in the dashboard to delete profiling data while keeping your settings.

Reset Settings: Use "Reset to Defaults" in Settings to restore default configuration without clearing data.

Full Reset: Deactivate and reactivate the plugin to reset both settings and show the Quick Setup wizard again.

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

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:

• PHP 7.4 or higher
• WordPress 6.3 or higher

Tested Up To:

• PHP 8.5
• WordPress 6.9

Speedix uses PHP features like typed properties (PHP 7.4+) and hrtime() (PHP 7.3+), with polyfills for PHP 8.0 string functions.

Yes, Speedix works on WordPress Multisite installations. Each site in the network has its own:

• Settings configuration
• Profiling data tables
• Dashboard and reports

Network admins can activate it network-wide or allow individual site activation.

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

Export options are available for both "By Hook" and "By Plugin" views. Click the download icon in the toolbar to access export options.

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.