Performance Tuning
3 min read
TrustLens is engineered to be performant on production WooCommerce stores — sub-100ms scoring, indexed customer lookups, transient caching on dashboards. If you’re experiencing slowness, the cause is usually identifiable: a specific bottleneck rather than general inefficiency. This page covers diagnosing and fixing the most common performance issues.
Where to Look First #
| Symptom | Most Likely Cause |
|---|---|
| Slow Dashboard loads | Cache hasn’t warmed; large customer count |
| Slow Customers list | Missing indexes; pagination too large |
| Slow checkout | Card-Testing fingerprint computation (rare); other plugin |
| Slow order saves | Synchronous score recalculation (should be async — verify) |
| Slow Historical Sync | Batch size too large; memory pressure |
| Action Scheduler queue growing | WP-Cron stalled; jobs failing silently |
Slow Dashboard #
Cache State #
The Dashboard caches expensive analytics queries as transients with 15-minute and 1-hour TTLs. Cold loads (after cache invalidation) are slower than warm.
- First load after activation or after a wave of new events: 2–10 seconds
- Subsequent loads within cache window: 200–500ms
If first loads are consistently slow on a large store, it’s the cold-cache cost; subsequent loads should be fast.
Large Customer Count #
The high-risk customers query runs against indexed columns and limits to a small result set — should be sub-second even on million-row tables. If it’s slower, indexes may be missing or corrupt.
Verify indexes:
- Use phpMyAdmin or a database client
- Inspect
{prefix}trustlens_customers - Confirm indexes on
trust_score,segment,email_hash
If missing: deactivate and reactivate TrustLens to trigger schema upgrade.
Slow Customers List #
Pagination Size #
Default page size is 20. Raising to 100+ via screen options can produce noticeably slower loads. Lower if needed.
Complex Filter Combinations #
Filters compose with AND. Some combinations don’t have composite indexes and fall back to full-table scans. If a specific filter combo is consistently slow, simplify.
Search Performance #
Search-by-email uses an indexed LIKE query. Slower on tables with billions of rows; fast on stores with millions or less.
Slow Checkout #
Card-Testing Fingerprint Computation #
The fingerprint script runs client-side; checkout latency comes from the server-side velocity check. Should be sub-10ms.
If checkout is slow and you suspect Card-Testing:
- Temporarily disable the Card-Testing module
- Test checkout speed
- Re-enable
If checkout speeds up significantly with Card-Testing off, file a support ticket. Usually it’s not the cause.
Plugin Conflicts #
Other plugins hooking into checkout can slow it down. Common culprits: review plugins, marketing automation, analytics. Disable non-essential plugins to identify.
Slow Order Saves / Refunds #
Score recalculations should be async (queued via Action Scheduler). If order saves are slow because of TrustLens, something is wrong.
Verify Async Behavior #
- Place a test order
- Watch the order-save response time
- Should complete in normal WooCommerce time
- Score updates should arrive 1–2 minutes later, not immediately
If order save is blocked by score calculation, a custom filter or extension may be forcing sync calculation. Look for code calling wstl_calculate_trust_score() directly in critical paths.
Slow Historical Sync #
Batch Size #
Default batch size is 100 orders. Larger batches process more per tick but consume more memory.
For memory-constrained hosts: lower to 50.
For high-memory hosts: raise to 200 for faster sync.
Action Scheduler Concurrency #
Action Scheduler runs jobs sequentially on most installations. If you have many other Action Scheduler jobs (subscription renewals, etc.), TrustLens sync waits its turn.
Workaround: run sync during off-peak hours when other Action Scheduler activity is low.
HPOS Migration Concurrency #
If WooCommerce HPOS migration is running, it heavily contends with TrustLens sync. Pause TrustLens sync until HPOS completes.
Action Scheduler Queue Growing #
If the Scheduled Actions list shows hundreds of pending TrustLens actions:
WP-Cron Stalled #
Most common cause. See Scores Not Updating Step 3 for the fix.
Concurrent Job Limit #
Action Scheduler limits concurrent jobs. If many TrustLens actions queue at once (e.g. after a bulk recalculate), processing is gradual.
Wait — the queue will drain. If it doesn’t drain over hours, WP-Cron isn’t running.
Jobs Repeatedly Failing #
If actions fail and retry, the queue can grow. Check failed actions:
- Filter Scheduled Actions to Failed status
- Read the error
- Fix the underlying cause
Database Bloat #
Over time, the {prefix}trustlens_events table can grow large. Mitigations:
- Event log retention setting (default 365 days) — lower to reduce size
- Card-testing velocity retention (default 90 days)
- Automation log retention (default 90 days)
The retention cron runs daily and purges old records automatically.
Profiling Tools #
To diagnose specific slowness:
- Query Monitor — shows slow queries, plugin overhead, per-page profiling
- New Relic — production-grade profiling, identifies slow code paths
- WordPress debug log with
SAVEQUERIES— captures all DB queries for offline analysis
Hosting Recommendations #
For stores with 100k+ orders:
- Managed WordPress hosting (Kinsta, WP Engine, Pressable)
- PHP 8.1+ with OPCache
- MySQL 8.0+ or MariaDB 10.6+
- Persistent object cache (Redis or Memcached)
- Adequate PHP memory (512MB+)
- Real cron (not WP-Cron)
TrustLens doesn’t require enterprise hosting, but on under-provisioned shared hosts, performance issues are amplified.
When to Contact Support #
If you’ve worked through this page and performance is still poor:
- Document the specific operation that’s slow
- Capture Query Monitor or New Relic profiling data
- Note your store size (orders, customers, disputes)
- Note your hosting configuration
- Submit a support ticket with the details
