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; email search on a very large table
Slow checkout	Card-Testing fingerprint computation (rare); Pro automation rules on Order Placed (e.g. Send Email with slow mail); other plugin
Slow order saves	Synchronous score recalculation (should be async — verify)
Slow Historical Sync	Slow server responses; memory pressure; the sync page left in the background
Action Scheduler queue growing	WP-Cron stalled; jobs failing silently

---

Slow Dashboard #

Cache State #

The Dashboard caches expensive analytics queries as transients with 5-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 #

The page size is fixed at 20 customers — there’s no screen option to raise it — so page size isn’t a factor.

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 is a contains-match (LIKE '%term%'), which can’t use an index and scans the customers table. It’s quick on typical stores but is the first thing to slow down on very large customer tables.

---

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.

Automation Rules on Order Placed (Pro) #

Automation actions other than Send Webhook run inside the checkout request. A rule that sends an email on every Order Placed waits for your mail server; pause the engine (TrustLens → Automation → Engine running) to test whether rules are 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 TrustLens_Score_Calculator::instance()->recalculate_score() (or firing trustlens/calculate_score) directly in critical paths instead of wstl_queue_score_update().

---

Slow Historical Sync #

Batch Size #

The sync runs from your browser, 10 orders per request, one request after another. The batch size is fixed — there’s no setting — so sync speed comes down to how quickly your server answers each request.

Keep the Dashboard or Settings → Data tab in the foreground: browsers slow down background tabs, and closing the page pauses the sync until you reopen it.

Server Load #

Each batch request competes with normal store traffic. On busy stores, run sync during off-peak hours.

HPOS Migration Concurrency #

If WooCommerce HPOS migration is running, it heavily contends with TrustLens sync. Pause TrustLens sync (Stop 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 Historical Sync, which queues a score recalculation for every customer), 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. It has no retention setting and isn’t purged automatically — rows are removed only when a customer’s TrustLens data is deleted or erased. The other log tables are trimmed:

• Card-testing velocity events — kept 48 hours by default; adjustable from 24 hours to 7 days under Card-Testing Defense → Event retention
• Automation log — kept 90 days (developers can set 7–365 with the trustlens/automation/retention_days filter)
• Linked-account fingerprints — removed 365 days after they were last seen
• Webhook delivery log — capped at the most recent 1,000 rows

The retention crons run daily and purge 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