Test lecture/écriture stockage

Test lecture/écriture - Évaluez les performances disque

Outil Web pour mesurer la rapidité du stockage navigateur (IndexedDB + localStorage). Les tests couvrent l'écriture, la lecture et la gestion de fichiers volumineux afin d'évaluer la rapidité de vos applis web.

Comment fonctionne le test de vitesse stockage ?

Le test mesure les performances de stockage navigateur en exécutant des opérations de lecture et d'écriture :

1. Écriture IndexedDB : test d'écriture de 1 000 éléments (1 Ko chacun)
2. Lecture IndexedDB : mesure de la lecture de 1 000 éléments
3. Écriture localStorage : test d'écriture de 100 éléments
4. Lecture localStorage : mesure de la lecture de 100 éléments
5. Fichier volumineux : test lecture/écriture d'un Blob de 10 Mo

Chaque test calcule le débit (MB/s) et la latence (ms par opération). Plus de MB/s et moins de latence = meilleures performances.

IndexedDB vs localStorage ?

IndexedDB et localStorage sont des systèmes de stockage navigateur aux caractéristiques différentes :

localStorage :
- Stockage clé/valeur simple
- API synchrone (bloque le thread principal)
- Limité à ~5-10 Mo par origine
- Ne stocke que des chaînes (objets via JSON.stringify)
- Idéal pour de petits états d'interface

IndexedDB :
- Base de données complète avec index et curseurs
- API asynchrone (non bloquante)
- Quota bien plus grand (souvent en gigaoctets)
- Stocke des clones structurés (objets, Blobs, ArrayBuffers)
- Idéal pour gros volumes et apps offline

Le benchmark mesure les deux pour comparer leur coût réel sur votre appareil.

Quels facteurs influencent la vitesse ?

Plusieurs facteurs influencent les performances de stockage navigateur :

- Type de disque : SSD >> HDD
- Interface : NVMe > SATA SSD > eMMC > HDD
- Espace disponible : disques remplis à plus de 80 % ralentissent (TRIM et over-provisioning se réduisent)
- Moteur du navigateur : Chromium utilise IndexedDB sur LevelDB ; Firefox utilise SQLite
- Système d'exploitation : journalisation, comportement de fsync et taille du page cache comptent
- Processus en arrière-plan : antivirus ou sauvegarde I/O concurrente ralentit lectures/écritures
- RAM : plus de RAM libre = meilleur cache de pages OS

Pour des résultats fiables, fermez les autres applications et gardez de l'espace disque libre.

Qu'est-ce qu'un bon score de vitesse de stockage ?

Lecture des résultats :

Vitesses typiques par type :
- SSD NVMe : 50-200+ MB/s navigateur (3-7 Go/s natif)
- SSD SATA : 20-100 MB/s navigateur (550 Mo/s natif)
- HDD rapide (7200 tr/min) : 5-20 MB/s
- HDD lent (5400 tr/min) : 2-10 MB/s
- eMMC/UFS mobile : 10-50 MB/s

Note : la surcouche navigateur et les frontières JavaScript rendent ces débits 10 à 100 fois plus lents que l'I/O disque natif. Une latence < 1 ms est aussi essentielle pour une UI réactive.

Pourquoi tester le stockage navigateur ?

Le test du stockage navigateur est précieux car :

- Performance Web App : montre la rapidité de stockage/lecture des web apps
- PWA : critique pour les apps utilisables hors-ligne
- Cache du navigateur : impacte le temps de chargement et le Service Worker
- Débogage : identifie les goulots avant que les utilisateurs se plaignent
- Comparaison : benchmark navigateurs et appareils côte à côte

Ce test reflète la performance réelle de toute web app reposant sur les API de stockage navigateur.

Pourquoi mes écritures IndexedDB sont-elles plus lentes que les lectures ?

Les écritures IndexedDB sont typiquement 2 à 10 fois plus lentes que les lectures car chaque écriture doit :

1. Acquérir un verrou exclusif sur l'object store (les lectures readonly utilisent un verrou partagé)
2. Mettre à jour les index secondaires définis (chaque index = écriture B-tree supplémentaire)
3. Ajouter au write-ahead log pour la durabilité
4. Vider sur disque au commit de la transaction (fsync)

Les lectures, en revanche, tapent souvent dans le page cache de l'OS et reviennent sans toucher au disque. Pour accélérer les écritures : regroupez plusieurs put dans une seule transaction (les commits amortissent les fsync), évitez les index inutiles et utilisez put() avec des clés explicites au lieu d'autoIncrement.

Quel est le quota de stockage du navigateur et que se passe-t-il quand on l'atteint ?

Les navigateurs modernes attribuent à chaque origine un quota basé sur l'espace libre et la politique de stockage. Limites typiques :

- Chrome/Edge : jusqu'à 60 % du disque libre par origine
- Firefox : jusqu'à 50 % du disque libre (quota de groupe)
- Safari : 1 Go sans demande, puis permission utilisateur requise

Consultez votre limite réelle avec navigator.storage.estimate() qui renvoie {quota, usage} en octets. En cas de dépassement, les transactions IndexedDB sont annulées avec QuotaExceededError et localStorage lève une exception au setItem(). Le stockage persistant via navigator.storage.persist() empêche le navigateur d'éviter vos données sous pression disque.

Pourquoi le test 10 Mo échoue-t-il parfois sur mobile ?

Les navigateurs mobiles imposent plusieurs limites qui peuvent casser le test du Blob de 10 Mo :

1. Taille de chaîne : la stringification d'un Blob 10 Mo pour localStorage double à 20 Mo UTF-16 ; Safari iOS refuse les chaînes au-delà de 16 Mo.
2. Pression sur le heap : le heap de Chrome mobile est de 256-512 Mo ; allouer le Blob plus le copier pour IndexedDB peut provoquer un OOM de l'onglet.
3. Quota d'origine : les Android d'entrée de gamme avec 8 Go internes n'accordent parfois que 100-500 Mo par origine.
4. Éviction en arrière-plan : si vous changez d'application en plein test, iOS peut éliminer l'onglet et la transaction est silencieusement annulée.

Pour des tests fiables sur mobile, libérez au moins 2 Go et gardez le navigateur au premier plan. Cet outil utilise désormais un Blob binaire de taille fixe (octets réels) au lieu d'une chaîne UTF-16 géante, bien plus léger en mémoire.

Quels navigateurs et appareils prennent en charge ces tests, et les résultats sont-ils comparables ?

Matrice de support et comparabilité :

- Chromium (Chrome/Edge/Brave/Opera) : IndexedDB sur LevelDB, localStorage sur LevelDB. navigator.storage.estimate() pris en charge.
- Firefox : IndexedDB sur SQLite, localStorage sur SQLite. estimate() pris en charge.
- Safari/iOS WebKit : IndexedDB sur SQLite, quotas et limites de chaîne plus stricts ; estimate() limité.
- Ancien WebView Android / IE : IndexedDB partiel ou absent.

Comme chaque moteur utilise un backend différent (LevelDB vs SQLite), les chiffres absolus en MB/s NE sont PAS directement comparables entre navigateurs. Comparez le MÊME navigateur sur des appareils différents, ou le même appareil entre navigateurs uniquement à titre indicatif. Notez toujours le navigateur/UA (l'export l'inclut) lorsque vous partagez des chiffres.

Est-ce identique à la vitesse de mon SSD ou HDD ? Puis-je l'utiliser pour certifier un disque ?

Non. Cet outil mesure le DÉBIT DU STOCKAGE NAVIGATEUR, pas la vitesse brute du disque. Les chiffres passent par JavaScript, le moteur de stockage (LevelDB/SQLite), le page cache de l'OS, la journalisation et fsync, ils sont donc généralement 10 à 100 fois plus lents que l'I/O natif et très influencés par le cache. N'utilisez PAS ces résultats pour certifier ou classer un SSD face à un HDD, valider un RMA de disque ou citer des chiffres de benchmark constructeur. Utilisez un outil natif (CrystalDiskMark, fio, dd) pour la certification de support. Ce test sert à diagnostiquer le comportement de stockage des applis web et à repérer un eMMC vraiment lent/défaillant par rapport au jitter du cache via des passes répétées.

Mes données sont-elles envoyées ? Est-ce privé et sécurisé ?

Le test est 100 % local. Il s'exécute entièrement dans votre navigateur, écrit uniquement dans le stockage isolé de l'origine actuelle et supprime automatiquement la base IndexedDB de test après chaque exécution. Rien n'est envoyé à un serveur et aucune télémétrie n'est collectée. L'export CSV/JSON se fait côté client via un téléchargement Blob. Remarque : navigator.storage.estimate() et navigator.storage.persist() exigent un contexte sécurisé (HTTPS) ; en HTTP simple, les champs quota/utilisation peuvent afficher « Inconnu » même si les tests de lecture/écriture fonctionnent.

Comment lancer plusieurs passes et exporter les résultats pour un ticket QA ?

L'I/O du stockage navigateur est bruité (page cache, I/O en arrière-plan, ramasse-miettes), donc une seule passe n'est pas fiable. Choisissez 3 ou 5 dans le sélecteur Passes avant d'appuyer sur Démarrer : l'outil répète toute la suite et indique le min, le max, la moyenne et la médiane par test pour voir la variance et distinguer un eMMC vraiment lent/défaillant du jitter du cache.

Après une session terminée, les boutons Exporter CSV et Exporter JSON apparaissent. Le fichier inclut un bloc d'en-tête (user agent de l'appareil, horodatage, passes demandées, quota/utilisation du stockage) plus chaque vitesse et latence par passe et les statistiques par test. Joignez-le à un ticket de réparation ou utilisez-le pour comparer des appareils avec des preuves reproductibles.

Fonctionnalités

• 5 tests de stockage complémentaires
• Benchmark lecture/écriture IndexedDB
• Tests localStorage
• Gestion de fichier 10 Mo
• Mesures MB/s et latence ms
• Statistiques multi-passes min/max/moy/médiane
• Export des résultats en CSV et JSON
• Affichage du quota et de l'utilisation
• Calcul des vitesses moyennes
• Progression visuelle
• Arrêt et nettoyage automatiques
• 100 % local, compatible hors ligne
• Support mobile et desktop
• Mode sombre