Facebook se retrouve avec toutes les CSS ajoutées au fur et à mesure et est obligé de namespacer. Je veux pas étudier la conso mémoire de malade que ça doit faire. Plutôt que de passer son temps à trouver des techniques pour contourner, ils feraient mieux de soigner à la base.

Pour le fallback Javascript, il y a encore peu, Facebook filait une belle page blanche. Cela a jamais d’après mon rapide test du jour, mais je n’ai pas testé plus qu’un affichage.

Enfin voilà, ces deux techniques, c’est vraiment pas pour généraliser, mais plutôt avec parcimonie.

– Les pubs et l’invite indiquant qu’on est connecté. Franchement ce n’est pas trop grave. La pulicité demandera de toutes façons js et l’invite de connexion, tant qu’elle fonctionne ce n’est pas forcément trop grave si l’affichage n’est pas là quand js est asbent. (tant qu’il reste un lien pour aller vers la page d’identification)

– Les « fresh data » : js permet d’avoir la version à jour quand j’utilise mes actions persos, sinon j’ai la version générique avec un cache, donc éventuellement des données de rating un peu vieilles. Est-ce vraiment grave ?

– Les actions utilisateurs, la version js sait probablement quelle est la note que j’ai déjà donné à la vidéo, si j’ai aimé ou détesté. Pour les autres on a le formulaire qui permet d’envoyer les infos mais pas forcément de retour sur ce qui a déjà été fait. C’est dommage mais pas dramatique.

Bref, il faut voir ce qui a été fait, comment, ce qu’on peut faire avec et ce qu’on peut faire sans. La démarche est intéressante, savoir s’ils ont fait les choses « bien » ou s’ils ont sabré la version sans js pour en faire quelque chose d’inutile, ça je ne sais pas. Le warning est utile, mais ne jetons pas le bébé avec l’eau du bain.

Pour facebook même chose. Je n’ai pas de compte, je n’en ai jamais eu, du coup je ne sais pas ce qu’ils avaient avant, si le modèle ajax a du sens ou pas, s’il y a des fallack sans js ou pas, etc. Je m’arrête à la démarche, après faire les compromis entre qualité, performance et cout, je ne peux pas les faire pour vous et les exemples sont rarement adaptables à autre chose qu’à leur cas particulier. Bref, il s’agit de montrer les démarche et les outils, savoir où et quand les utiliser, c’est à toi de décider en fonction de ton contexte.

La navigation Ajax façon Facebook c’est la même chose. Ça peut être un bon conseil si on prévoit la version sans Javascript.

Le temps de zip sur le serveur et de dezip sur le client est généralement considéré comme quasi nul par rapport au traffic réseau. Il ne s’agit pas d’employer un dictionnaire de compression extraordinaire, un niveau de compression même assez faible réduira fortement des fichiers de type html/css/js sans impacter le cpu. Même pour les requêtes Ajax, il serait étonnant que ce temps soit significatif par rapport à la simple latence réseau dont tu vas souffrir.

Il ne faut pas oublier que le temps gagné sur le transfert avec gzip est compensé par le temps de compression coté serveur et décompression coté client.
Je pense qu’en fonction de l’application, ca peut être variable au final.
J’ai tendance à penser qu’il faudrait compresser les pages, mais pour les appels ajax je les laisserai en non compressé pour plus de réactivé personnelement (surtout si ce sont des requetes ajax très légère)

Après je ne sais pas si on peut fixer une limite de taille. Par exemple compresser tous les fichiers d’une taille supérieur à 100ko