Algolia Evidence-Based Performance Tuning
Overview
This skill decomposes perceived search time into input handling, network, provider request, response transfer, transformation, and render work. Optimization starts with an owned baseline and ends with a comparable measurement.
Prerequisites
- A named repository, environment, and Algolia application or index in scope
- The local lockfile and installed client types as implementation authority
- A safe read-only query or explicitly disposable test target
- Current first-party documentation for any provider behavior that affects the change
Tool Discipline
Use Read, Glob, and Grep to inspect local code, configuration names, tests, and dependency versions. Use WebFetch only for current official Algolia documentation. Use Write or Edit only after identifying the target files, constraints, and verification plan.
Current Contract
- Set targets from the application's SLO, user geography, device mix, and measured baseline.
- Inspect record and response shape before changing relevance or faceting settings.
- Separate query count amplification from individual request latency.
- Preserve correctness and relevance assertions alongside performance measurements.
Authentication
Run measurements with search-only or secured keys and sanitized representative queries. Do not expose write credentials or sensitive query logs.
Instructions
- Define the journey, environment, representative query set, device/network profile, and success criteria.
- Capture request count, component timings, payload size, cache behavior, result correctness, and render cost.
- Locate the dominant segment before proposing changes.
- Test bounded changes such as debouncing, stalled-search handling, requested attributes, query batching, or render work.
- Compare before and after with the same harness and inspect relevance and freshness regressions.
- Document the accepted change, uncertainty, monitoring signal, and rollback trigger.
Approval Boundaries
Do not change ranking, remove required facets, cache personalized responses, or publish claimed improvements without comparable evidence.
Output
Return the benchmark protocol, baseline distribution, bottleneck attribution, tested changes, before/after evidence, relevance checks, and rollout guardrails.
Error Handling
| Condition | Response | |---|---| | Results are noisy | Increase samples and control geography, device, cache, and query set. | | Faster response changes hits | Reject or obtain product acceptance for the relevance tradeoff. | | Client emits duplicate requests | Fix lifecycle or input handling before provider tuning. | | No SLO exists | Report the baseline without inventing a target. |
Examples
Use this compact input and expected handoff to calibrate scope and evidence quality.
Input:
journey=mobile-typeahead; queries=approved-100; network=recorded-profile
Expected handoff:
dominant=duplicate-client-requests; requests-keystroke=3-to-1; relevance=unchanged