Performance Optimization Practices for iQIYI International Site Backend

iQIYI International delivers high‑quality video to users in dozens of countries. Because the service is deployed overseas, it faces diverse network policies and varying user network conditions, making performance optimization a complex engineering challenge.

The article outlines the key technical highlights of the backend team’s optimization work, including full‑stack web performance tuning, a custom AB testing framework, multi‑instance local cache synchronization via Redis, rapid hot‑show updates, and a self‑developed cache framework.

1. Technical Research

Typical high‑concurrency optimizations focus on caching and asynchronous processing. Performance metrics such as FP, FCP for the web, and RT, TPS for the backend are used to evaluate improvements.

2. Business Background

The platform operates in a “mode” concept where each country or region is treated as an independent site, supporting dozens of languages. User mode and language are stored in cookies, which limits CDN strong‑caching.

3. Optimization Steps

Browser Cache Optimization

Compression Optimization

Server‑Side Cache Optimization

3‑1 Browser Cache

A dedicated web‑cache service was introduced between the front‑end SSR nodes and the backend Java services. This service caches rendered pages for 5 minutes, dramatically increasing cache‑hit rates.

3‑2 Compression

Enabling Brotli compression on Nginx reduced page size by ~30 % and improved First Contentful Paint (FCP) by about 6 %. The system also supports gzip for backward compatibility.

3‑3 Server‑Side Cache

Two‑level caching was built using Caffeine (local) and Redis (distributed). Local caches use the W‑TinyLFU algorithm for high hit rates, while Redis stores compressed byte arrays to reduce CPU overhead.

To address the 5‑minute update latency, a pub/sub mechanism in Redis synchronizes local caches across instances, ensuring real‑time updates for hot content.

A refresh‑task module proactively refreshes hotspot pages (e.g., home page, popular shows) without overwhelming the backend, achieving near‑100 % cache‑hit rates for these pages.

Cold‑start cache pre‑warming is implemented: when a new instance starts, it publishes an init message, other instances respond with hot‑key data, allowing the newcomer to populate its local cache before receiving traffic.

For high availability, a fallback cache with a 24‑hour TTL is stored in Redis. If the SSR service fails, the system falls back to this stale data, preventing complete page failures.

4. Optimization Results

After the optimizations, the iQIYI International web front‑end saw significant performance gains: FCP improvements of up to 6 %, a 4 % increase in 304 responses due to effective ETag handling, and overall revenue impact estimates of >1 % per 100 ms latency reduction. Backend cache‑hit rates and service metrics also improved markedly.

Further work includes GC tuning and reactive service redesign to continue the performance improvement journey.