Performance Tuning

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:

1. Use phpMyAdmin or a database client
2. Inspect {prefix}trustlens_customers
3. 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:

1. Temporarily disable the Card-Testing module
2. Test checkout speed
3. 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 #

1. Place a test order
2. Watch the order-save response time
3. Should complete in normal WooCommerce time
4. 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:

1. Filter Scheduled Actions to Failed status
2. Read the error
3. 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