Le 18 novembre dernier, nous indiquions dans nos colonnes que Mozilla reléguait au second plan son projet Electrolysis. Ce dernier avait pour ambition de modifier drastiquement l’architecture entière de Firefox pour adopter un modèle multiprocessus. La raison invoquée était que d’autres projets à plus court terme pouvaient apporter un bénéfice plus immédiat au navigateur. Le projet Snappy en fait partie.
Snappy est donc un projet qui a été lancé il y a deux semaines, mais qui apporte aujourd’hui des résultats intéressants. Il est l’équivalent de l’initiative MemShrink qui a vu un groupe de développeurs se constituer pour faire la chasse aux consommations mémoires trop élevées dans Firefox, avec de gros bénéfices dans la version 7. Snappy est du même acabit, mais vise exclusivement la réactivité.
Les buts de Snappy sont d’établir certaines bases, telles que :
En fin de semaine dernière, un nouveau rapport a été publié pour faire part des observations assemblées par le groupe.
Premièrement, un outil a permis de transformer automatiquement les divers blocages de plus de 30 secondes en plantages complets du navigateur. Verdict : certains problèmes sont pires que prévus. Deuxièmement, la surveillance télémétrique va être activée pour surveiller le traitement des requêtes SQL considérées comme lentes. Troisièmement, les sites actuels utilisent l’API DOM Storage qui ralentit les performances du navigateur car elle n’est pas asynchrone. Une solution de contournement devrait être mise en place.
Taras Glek, membre du groupe, rappelle sur son blog que le groupe considère être de son ressort tous les éléments de performances qui peuvent engendrer une frustration chez l’utilisateur. Cela peut toucher aussi bien une pause importante comme pour l’énumération des polices qui de petites saccades qui surviennent régulièrement, comme dans les animations des onglets.
Une nouvelle réunion aura lieu cette semaine, et de premières solutions devraient être proposées, notamment sur les opérations d’entrées/sorties sur le cache lorsque le navigateur démarre ou quitte.
Snappy est donc un projet qui a été lancé il y a deux semaines, mais qui apporte aujourd’hui des résultats intéressants. Il est l’équivalent de l’initiative MemShrink qui a vu un groupe de développeurs se constituer pour faire la chasse aux consommations mémoires trop élevées dans Firefox, avec de gros bénéfices dans la version 7. Snappy est du même acabit, mais vise exclusivement la réactivité.
Les buts de Snappy sont d’établir certaines bases, telles que :
- Une réactivité de 50ms lors de la frappe dans une zone de texte
- Rester à 60 images par seconde dans les opérations sur l’interface
- Vérifier les performances via la télémétrie
- Avoir un temps de démarrage comparable à celui de Chrome ou Internet Explorer
- Des fonctionnalités Précédent et Suivant aussi rapides que sous Opera
En fin de semaine dernière, un nouveau rapport a été publié pour faire part des observations assemblées par le groupe.
Premièrement, un outil a permis de transformer automatiquement les divers blocages de plus de 30 secondes en plantages complets du navigateur. Verdict : certains problèmes sont pires que prévus. Deuxièmement, la surveillance télémétrique va être activée pour surveiller le traitement des requêtes SQL considérées comme lentes. Troisièmement, les sites actuels utilisent l’API DOM Storage qui ralentit les performances du navigateur car elle n’est pas asynchrone. Une solution de contournement devrait être mise en place.
Taras Glek, membre du groupe, rappelle sur son blog que le groupe considère être de son ressort tous les éléments de performances qui peuvent engendrer une frustration chez l’utilisateur. Cela peut toucher aussi bien une pause importante comme pour l’énumération des polices qui de petites saccades qui surviennent régulièrement, comme dans les animations des onglets.
Une nouvelle réunion aura lieu cette semaine, et de premières solutions devraient être proposées, notamment sur les opérations d’entrées/sorties sur le cache lorsque le navigateur démarre ou quitte.
