> ## Documentation Index
> Fetch the complete documentation index at: https://docs.safesquid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance Accelerators

> Use SafeSquid performance accelerators such as caching, prefetching, bandwidth management, speed limits, and WCCP with deployment-aware expectations.

# Improve performance without losing control

## Problem statement

Enterprises need better web performance, but acceleration features can create risk when they are deployed without clear intent. A cache that serves the wrong content, a prefetch rule that creates unnecessary traffic, or a transparent-routing feature that is misunderstood can turn performance tuning into an operations problem.

## Client scenario

Use these guides when you need to:

* reduce repeated bandwidth consumption
* improve perceived user response time
* control upload or download pressure
* deploy transparent traffic steering with router integration

## Key benefits

SafeSquid performance accelerators help operators improve efficiency while keeping the proxy in the control path. They are most effective when used deliberately and validated with performance plots, logs, and production-safe rollout steps.

## Prerequisites

### Client-side preparations

* Identify whether the problem is latency, bandwidth contention, repeated downloads, or transparent-redirection design.
* Gather a baseline before changing acceleration features.

### SafeSquid-side setup

* Confirm the deployment topology can support the accelerator you plan to enable.
* Validate each feature separately instead of enabling several acceleration paths at once.

## Performance accelerator guides

### [Caching](/Caching)

Use caching when repeated requests for the same web objects waste bandwidth and increase user wait time. Caching can reduce origin fetches and improve response times, but it should be validated against content freshness requirements and application behavior.

### [Pre Fetching](/Pre_Fetching)

Use prefetching when perceived latency is driven by predictable follow-on requests. Prefetching can improve browsing responsiveness, but it must be monitored carefully so the proxy does not fetch unnecessary content that provides little operational value.

### [Manage Bandwidth](/Manage_Bandwidth)

Use bandwidth management when a few users, services, or content types consume disproportionate capacity. This is the right control for policy-driven allocation, not just raw speed optimization.

### [Speed Limits](/Speed_Limits)

Use speed limits when you need per-user, per-group, or per-content caps to protect shared capacity. This is especially useful when fairness and congestion control matter more than maximum download speed.

### [WCCP](/WCCP)

Use WCCP when the deployment requires router-driven traffic redirection and transparent proxy integration. WCCP is an architecture-sensitive feature and should be validated carefully with topology, failover, and traffic-path testing.

## Verification and validation

### Positive tests

For each accelerator you enable:

* record a before state
* enable one feature at a time
* test the target workflow again

Expected result:

* the intended metric improves
* unrelated traffic behavior remains stable
* logs and performance plots reflect the change window clearly

### Negative tests

Check a workflow that should not be affected by the accelerator.

Expected result:

* the optimization does not create a new application failure
* the feature remains scoped to the problem it was meant to solve

## Troubleshooting guide

### Performance improves for some users but breaks specific workflows

Likely causes:

* the accelerator is too broad
* the application is sensitive to caching, prefetching, or redirection behavior

Isolation steps:

* identify which exact feature changed
* compare the affected workflow against the intended scope

Remediation:

* narrow the feature scope
* disable the last change if needed
* retest with the affected application

### Capacity data remains unclear after tuning

Likely causes:

* too many changes were made at once
* no baseline was captured

Isolation steps:

* correlate the change window with performance plots and logs
* separate the effects of each accelerator

Remediation:

* roll forward one change at a time
* capture a fresh baseline and compare again

## Related controls / next steps

* Use [Performance Plot](/Performance_Plot) to validate whether an accelerator actually improved the right metric.
* Use [Proxy Clustering](/Proxy_Clustering) when the problem is scale-out resilience rather than optimization on one node.
* Use [Transparent Proxy](/Transparent_Proxy) and [WCCP](/WCCP) for topology-sensitive transparent deployment design.


## Related topics

- [Performance Plot](/use_cases/performance_acceleration/performance_plot.md)
- [Unable to Generate Performance Plot](/troubleshooting/not_generating_performance_plot.md)
- [Architecture and request pipeline](/admin_guide/start_here/architecture.md)
- [Audit & Forensics](/use_cases/audit_and_forensics/audit_forensics.md)
- [Security Logs](/use_cases/audit_and_forensics/security_logs.md)