WebKit est un fork du moteur de rendu KHTML du projet KDE (l’environnement de bureau Linux) utilisé notamment dans le navigateur Konqueror.

KHTML a été développé en même temps que la technologie à composants KPart qu'il utilise pour être intégré à Konqueror, le gestionnaire de fichiers de KDE. Il est sorti en 2000, en même temps que la version 2 de KDE.

En 2002 Apple choisit KHTML ainsi que KJS pour l'interpréteur JavaScript comme base de son moteur de rendu HTML qu'utilisera son navigateur web Safari. Ce nouveau moteur, placé sous licence LGPL et appelé WebKit subit de nombreuses modifications visant notamment à réduire les dépendances aux bibliothèques KDE, à tel point que les échanges de code entre les deux moteurs devinrent très compliqués. Ces problèmes ont été réglés lorsque Apple a ouvert le développement de Webkit en utilisant un dépôt SVN et un système de suivi des bug utilisant Bugzilla1. C'est ainsi que certaines modification d'Apple ont pu être intégrées à KHTML, comme celles ayant permis au moteur de rendu de KDE de passer le test Acid2.
Source : Wikipedia

On voit ici les gains de l'OpenSource : tu prends un produit et tu l’améliores en rendant publiques tes modifications. Il y a un beau travail de base créée par les équipes de KDE qui a été amélioré par Apple puis Google.

Aujourd'hui la masse de travail pour faire un bon moteur de rendu fait qu'il n'y aura plus de nouveaux moteurs autre que des fork. C'est pour cela qu'il faut vraiment éviter que Firefox abandonne Gecko. A noter que Firefox sous iOS utilise Webkit (obligation d'Apple).

le graphique est pas terrible, les navigateurs n'attendent pas d'avoir récupérer x.css avant de lancer le téléchargement de X.js
pas contre en http2, cela n'utilise qu'une connexion ouverte (c'est donc des poignées de main en moins)

Ce truc me parait une bonne idée, mais cela doit être traité avec une attention particulière, non ?

Dans ton cas, l'image, css et js peuvent et sont potentiellement présent dans le cache local : dans ce dernier cas, tu vas faire télécharger plus de données que nécessaire par le client, ce qui peut-être problèmatique pour les héres propulsés par DSL (ou pire, par onde)

Il existe un mécanisme d'annulation de la part du client quand il commence a recevoir un truc 'pushé' qu'il a déjà en cache (le client envoi un RST_STREAM).

En pratique ca marche bien et l'overhead est minime.

Sur les réseaux sensibles a la conso, le client peut explicitement interdire le push.

source: http://http2.github.io/http2-spec/#PushResources

Si je comprends bien avec http/2 il y a quand même un changement de paradigme. Car on peut rassembler toutes ces ressources sur le même domaine (tous les fichiers mais jusqu'à combien) pour échanger une seule poignée de main et un seul canal de communication.

Et donc que le fonctionnement avec des domaines pour les fichiers statiques semblent compromis. Quel est l'impact de http/2 d'un site à fort traffic qui utilise le CDN à tout va ?