--- title: Performance Tuning description: "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…" url: "https://webstepper.io/docs/trustlens/troubleshooting/performance-tuning/" updated: "2026-10-18" category: Troubleshooting --- # 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](/docs/trustlens/troubleshooting/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