# EXP-007 — Client-Side Media Processing

## Objectif

Mesurer le traitement média client-side de WordPress 7.1 et le comparer au traitement serveur, en séparant architecture, réseau, coût navigateur et coût serveur.

## Hypothèse

Le client-side processing déplace une partie du coût vers le navigateur et peut réduire le travail serveur, mais son gain end-to-end dépend du réseau et du coût WASM initial.

## Environnement

WordPress 7.1, PHP 8.4.24, MariaDB 11.4.12, MCP Adapter 0.5.0, site de test sans données client.

## WordPress

Source MEDIUM : 4000×2667, 5,635,889 octets, SHA-256 `742e6c2838425cabf9d5c8819eca754d3183db5c1eb03058808c582f9bd85cc3`.

## Navigateur

Les HAR Chromium authentifiés sont validés et démontrent le pipeline client. Le Chromium local n’est pas pilotable dans cet environnement ; les résultats navigateur fournis constituent la preuve de référence.

## Capabilities navigateur

Les capacités brutes du navigateur ne sont pas archivées localement. Les HAR démontrent worker/WASM, sideload et finalize.

## Assets

Les assets source, dimensions, poids et hashes sont dans `lab/output/EXP-007/assets.txt`. Le MEDIUM a été utilisé pour tous les runs. Aucun asset source n’a été modifié.

## Méthodologie

Client : 1 cold et 3 warm, avec HAR validés. Server : 3 imports `wp media import`, mesurés localement, explicitement `SERVER PROCESSING ONLY — NETWORK EXCLUDED`.

## Pipeline client-side

Démontré par worker/WASM, 7 requêtes sideload et finalize. Le cold charge 4,561,631 octets de worker/WASM.

## Pipeline server-side

Démontré par les imports WP-CLI et les métadonnées des attachments 17–19. Chaque run produit 7 fichiers, dont une image scaled 2560×1707 et six sous-tailles.

## Preuves de traitement

Client : HAR validés, attachments 13–16. Server : métadonnées JSON des attachments 17–19 et durées `server-runs.txt`.

## Cold start

26.118915 s de worker load ; 111.874231 s du démarrage worker au finalize ; 67.508195 s d’upload original.

## Warm runs

84.251009 s, 84.289461 s et 84.343643 s. Médiane : 84.289461 s.

## Résultats

Le serveur local traite le fichier en 11.051–11.490 s, médiane 11.120 s, hors réseau. Le client warm reste dominé par l’upload original d’environ 67.4 s.

## Statistiques

Les min/max/moyenne/médiane sont dans `statistics.md`. Les runs client et serveur ne sont pas mélangés dans une moyenne unique.

## Fichiers générés

Client : scaled 551,239 octets, thumbnail 4,724, medium 10,730, medium_large 56,159, large 96,589, 1536 204,044, 2048 355,696 ; total estimé 6,915,070 octets avec original.

Server : original scaled 734,799 octets, derivatives 985,084 octets, total 1,719,883 octets. Les dérivés serveur sont environ 23.0 % plus petits que les dérivés client, mais la comparaison totale inclut des originaux différents.

## Réseau

Original request : 5,636,291 octets ; sideload total : 1,282,111 ; finalize : 1,008 ; total média : 6,919,410, soit environ +22.8 % par rapport à la source.

## CPU serveur

SERVER_CPU = NON DÉMONTRÉ.

## Mémoire serveur

SERVER_MEMORY_DELTA = NON DÉMONTRÉ.

## Fallback

NON TESTÉ.

## Architecture vs performance

L’architecture client est réellement utilisée et observable. Le coût WASM est élevé à froid puis disparaît du warm run, mais l’upload réseau reste dominant. Le serveur-only est plus court localement ; aucune supériorité end-to-end ne peut être affirmée puisque le réseau est exclu des runs serveur.

## Limites

Les runs serveur ne mesurent pas un parcours utilisateur complet. CPU/RAM serveur ne sont pas instrumentés. Les HAR warm-03 contenaient warm-02 avec Preserve Log ; la duplication a été dédupliquée par filename/timestamp.

## Rollback

Les attachments client 13–16 et serveur 17–19 ont été vérifiés par préfixe puis supprimés. Les copies locales de runs ont été supprimées ; les sources restent conservées.

## Conclusion

EXP-007 démontre une vraie évolution d’architecture et un traitement client réellement actif. Il ne démontre pas un gain end-to-end : le serveur-only médian est 11.120 s hors réseau, tandis que le client warm médian est 84.289461 s, dont environ 67.4 s d’upload original. Le client déplace le coût ; il ne prouve pas ici une supériorité de performance utilisateur.

## Niveau de confiance

Fort pour les mesures HAR client et les trois mesures serveur ; modéré pour toute extrapolation end-to-end.

## Production

Acceptable sous conditions ; CPU/RAM et navigateur/fallback restent à caractériser.

## Matière éditoriale

### Fait démontré

Le navigateur charge un worker/WASM, génère des dérivés et les envoie par sideload avant finalize.

### Chiffre principal

Client warm médian : 84.289461 s ; server-only médian : 11.120 s ; cold worker transfer : 4,561,631 octets.

### Surprise

Les dérivés serveur sont plus petits, mais les runs serveur excluent les 67 secondes d’upload utilisateur.

### Contre-intuition

Déplacer le traitement dans le navigateur ne rend pas automatiquement l’expérience plus rapide : le réseau peut dominer.

### Limitation

Aucune réduction CPU/RAM serveur n’a été mesurée.

### Décision QuantumDev

Présenter le client-side processing comme une évolution d’architecture et de répartition de charge, pas comme un gain de vitesse universel.

### Capture exploitable

`results.csv`, `statistics.md`, `cold-vs-warm.md` et les JSON de métadonnées serveur.

### Angle LinkedIn 1

Le navigateur peut traiter l’image, mais l’upload reste le coût dominant.

### Angle LinkedIn 2

Comparer un benchmark local serveur à un parcours réseau complet sans séparer les coûts produit une conclusion trompeuse.

### Niveau de preuve

Démontré pour le pipeline et les temps observés ; partiellement démontré pour la performance end-to-end.