Petite

introduction

(pour ceux qui vivraient encore dans des datacenters)

Performance perçue : afficher quelque chose d'utile le plus rapidement possible

backend/frontend

On peut agir à deux niveaux : backend et frontend

Je parlerai essentiellement de frontend

Sinon vous savez tous ce qu'est un waterfall ?

mais sinon ...

et donc ça a un impact sur le business

Y'a beaucoup d'études dont le fameux 100ms d'amazon qui montrent qu'il y a un impact négatif sur le business quand on ralentit un site web

De notre côté, nous on a montré l'inverse : qu'il y avait un impact positif quand on accélérait un site !

Par exemple, on voit la corrélation chez un client dans le secteur de la mode.

distribution des temps de chargement vs le taux de conversion et on voit donc clairement qu'un internaute qui charge le site rapidement transforme mieux.

A noter que cette distribution n'est pas une gaussienne et donc mesurer des moyennes de temps de chargement n'est pas très pertinent dans notre métier (=>percentile)

A noter aussi que la courbe du taux de conversion redescend vers les valeurs proches de zero car ça correspond à des bots et aussi qu'il y a interpolation

src : webperf.io + Fasterize cusotmer

src : Cedexis Impact

ça montre l'évolution du poids et de la complexité des pages depuis environ 4 ans

on est passé de 700ko a 2Mo

src : httparchive

Les limites des règles actuelles

quand la webperf va à l'encontre de la webperf

• Make Fewer HTTP Requests
• Use a Content Delivery Network
• Add an Expires Header
• Gzip Components
• Put Stylesheets at the Top
• Put Scripts at the Bottom
• Avoid CSS Expressions
• Make JavaScript and CSS External
• Reduce DNS Lookups
• Minify JavaScript
• Avoid Redirects
• Remove Duplicate Scripts
• Configure ETags
• Make AJAX Cacheable

• Ajax
• Responsive Web
• Split initial payload
• Defer JS (non blocking, async)
• Inline scripts position
• Minify HTML
• Optimize images
• Sharding
• Flush the document early
• Use iFrame sparingly
• Simplify CSS selectors

Mais pourquoi ces règles existent, d'où elles sortent ?

• latence
• TCP (handshake, slow start)
• limites des navigateurs
• HTTP1.1
• im-mobile

• la latence, schématiquement c'est la longueur du tuyau, le fait qu'on doive forcément parcourir une distance pour transporter une informtation
• le protocole TCP, c'est la couche de transport de nos réseaux, celle qui s'assure qu'on reçoit bien ce qui a été envoyé
• les navigateurs, ben si vous avez connu un monde avec IE5.5, vous savez qu'il y en a des limites
• le protocole HTTP1.1 a des limitations sur la façon de se connecter, on peut dire qu'il est pas très connecté et en plus il est sujet a mille interprétations
• enfin tout ça a été rédigé en 2006, lancement du premier iphone : 2007

mais en fait, aujourd'hui

• les navigateurs ont évolué en 10 ans (Firefox 49, Chrome 53, Edge)
• les terminaux ont changé
• les protocoles sont en train de changer (SPDY/HTTP2)
• même les couches réseaux sont remises en cause (QUIC)

• la manière de coder des sites a changé : SPA, RWD
• les widgets ont explosé à cause des tags managers

RFC 7540 de HTTP2 c'est mai 2015

le nombre de requêtes a aussi explosé à cause du business de la pub et des trackers

Mobile-First

Aujourd'hui, le mobile représente 50% du surf ou plus : on rigolait encore y'a 3 ans quand tous les ans le gartner prévoyait que 50% du surf serait sur mobile mais on y est

Les ventes de smartphones c'est 350 millions par trimestre !

src : https://aasaindustryanalysis.wordpress.com/2015/08/04/smartphone-market-continues-upswing-in-q2/

Apple a annoncé qu'ils avaient vendus leur milliardième appareil sous iOS

src : Keynote Apple sept 2016 + http://www.siliconbeat.com/2016/04/01/apple-40-emerging-markets-may-provide-youthful-spark/

Et en terme de moyen d'accès à l'internet, les 15-34 ans utilisent majoritairement le mobile (les autres sont en train d'y venir)

Etude faite sur un ensemble de magasins en ligne US pour la rentrée 2015

src : www.soasta.com/blog/back-to-school-website-performance-monitoring/

Dans certains pays (ici le Japon), 80% du surf se fait sur mobile (données réelles d'un acteur de la cosmétique)

src : private access to Google Analytics

Mobile - Only

Et aujourd'hui, dans certains cas, c'est pas mobile-first mais mobile-only !

Par exemple en Afrique, sans faire trop de généralités, les réseaux sont majoritairement mobiles (ils vont prendre le raccourci sans passer par la case ADSL ou même fibre)

Certains foyers ne prennent que des abonnements mobiles pour économiser

src : http://www.pewinternet.org/2015/12/21/home-broadband-2015/

Et puis récemment (début sept 2016), une étude faite par Doubleclick (qui appartient à Google) a encore sorti des chiffres intéressants

https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/

Et là il faut bien comprendre que les utilisateurs sur mobile sont plus exigeants car ils sont en situation de mobilité, entre deux métros, etc ...

Eh bien d'abord c'est loin d'être le cas pour tout le monde (et rappelez vous que quand on construit une autoroute, elles sont vite remplies = quand on agrandit les tuyaux, les sites prennent tous rapidement du poids)

Facebook a même instauré un jour où les connexions mobiles se font en 2G pour que les ingénieurs se rendent compte

Et il faut savoir qu'il y a plus de personnes qui accèdent à Facebook en 2G qu'en 4G

src : http://uk.businessinsider.com/facebook-2g-tuesdays-to-slow-employee-internet-speeds-down-2015-10 + https://twitter.com/BenedictEvans/status/513017790920290304

src : http://www.pewinternet.org/2015/04/01/us-smartphone-use-in-2015/

Qui dit mobile, dit mobilité et donc perte de connexion

Etude sur un trajet en train (Amtrak) avec un accès Wifi. au final, mauvaise connexion mesurée quasiment tout le long du trajet

src : https://consumerist.com/2015/04/23/amtrak-wifi-so-slow-it-might-as-well-not-exist/

Preloader / speculative parser / Lookahead downloader

src: http://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/

src : https://cloudfour.com/thinks/the-real-conflict-behind-picture-and-srcset/

Les règles actuelles

et donc ça conduit à une situation où les règles classiques de la webperf, celles que tout le monde connait, sont devenues dans certains cas contre productives !

Alors .... petit tour de ces fameuses règles

Concatenation

JS / CSS, Images

• un seul gros fichier peut ralentir la page

Concatenation

JS / CSS, Images

• un seul gros fichier peut ralentir la page
• limites d'IE9
• impossible d'établir une priorité dans le code téléchargé
• ça casse le cache (et le flush est plus contraignant)
• maintenabilité

ça concerne les JS et les CSS mais aussi les images avec la technique du spriting

La concaténation vient de deux choses : nb de requêtes possibles en parallèle, latence, connexion TCP

1. surtout le cas pour les ressrouces bloquantes. J'ai déjà croisé des CSS de 1Mo, à cause des fonts inlinées

Le plus énervant c'est quand GTMetrix ou WPT vous dit que vous n'avez pas combiné vos CSS/JS : mais c'est ça que je veux faire !

limites IE9 : 4096 sélecteurs/fichiers, max 278ko, max 31 @import dans un CSS, @import nesting supports up to 4 levels deep

Concatenation

JS / CSS, Images

Trouver un intermédiaire en fonction de la taille et de la composition du site.

Et aussi avoir un bon process de build

ça concerne les JS et les CSS mais aussi les images avec la technique du spriting

La concaténation vient de deux choses : nb de requêtes possibles en parallèle, latence, connexion TCP

1. surtout le cas pour les ressrouces bloquantes. J'ai déjà croisé des CSS de 1Mo, à cause des fonts inlinées

Le plus énervant c'est quand GTMetrix ou WPT vous dit que vous n'avez pas combiné vos CSS/JS : mais c'est ça que je veux faire !

Sharding / Cookieless domain

• introduit de nouvelles résolutions DNS, en général dans le <head>
• "low" vs high latency network

Vaut mieux éviter, surtout pour les ressources bloquantes

Définition du sharding/cookieless domain

ça vient de deux choses : nb de requêtes possibles en parallèle, upload limité, pas de compression des headers

mais aujourd'hui les navigateurs sont passés de 2 à 6 requêtes en // par domaine

low : mobile ou Chine

deja vu : 4 ou 5 domaines statiques différents (cf. https://www.fasterize.com/en/website_configs/1998/hosts_mapping) => unsharding

heureusement, surtout en HTTP2, certains navigateurs détectent que c'est le même serveur derrière et ne refont pas de connexion TCP (mais ils ne font pas tous la détection avec le même algorithme)

Lazyloading

• Lazyloader les premières images est une mauvaise idée !
• A réserver aux images en dessous de la ligne de flottaison

en faisant du lazyloading, on masque les images à ce preloader et on délègue le chargement à un script qui peut s'exécuter assez tard

JS at the bottom

c'est assez amusant de voir le JS tout en bas de page sortir en seconde requête :-)

en fait vaut mieux mettre les scripts en async/defer qu'en bas

Minification

• gain minime
• sauf si on minifie de façon agressive
• mais peu de personnes le font parce que ça peut être dangereux

et si on allait plus loin ?

cache cache

eh ben oui, exactement

c'est pas la technique du futur c'est vrai mais ça a tellement d'avantage ...

D'abord, cacher ce qui est cachable, ça semble évident mais bon ...

ensuite

Cookieless cache

Cacher les pages dynamiques pour les nouveaux utilisateurs ou les utilisateurs anonymes

a noter que ça fonctionne aussi pour les bots ... je dis ça comme ça ...

ESI/Ajax

Cacher les pages HTML et ajouter les parties dynamiques en Ajax

Facebook en 2010 avait "industrialisé" ça avec une technique appelée BigPipe (qui a été reprise par Drupal au début de l'année) en fait ça revient à utiliser une technique plus générale, le chargement progressif

Chargement progressif

ça consiste à charger la page avec des fonctionnalités minimales, un rendu suffisant pour tout ce qui est au dessus de la ligne de flottaison et ensuite de charger petit à petit le reste : les CSS manquants (pour les popups par ex), le JS pour l'interaction, les widgets, les CSS pour les autres pages, etc ...

Attention ce sont des techniques de sioux mais ce sont surement celles qui donnent le plus de résultat aujourd'hui

Techniques de (petit) sioux

• JS async/defer/iframe
• Lazyloading image/iframe

Y'a celles qu'on connait déjà defer vs async:

Techniques de (grand) sioux

• Async font loading
  • Chargement des fonts via loadCSS + preload
  • Application quand les fonts sont disponibles (font event / polyfill fontFaceObserver)
  • tradeoff (FOUT, FOIT, FOFT vs maintenance)

src: https://www.zachleat.com/web/comprehensive-webfonts/

Techniques de (grand) sioux

• Inline critical CSS/JS + async loading
  • Séparer ce qui est critique pour le rendu ATF
  • Inliner ce qui est critique
  • Charger le reste en asynchrone
  • Charger la totale ensuite pour remplir le cache
• Inline first view

src: https://jakearchibald.com/2016/link-in-body/

Mobile-first => Mobile-only => Offline-first

Pré-

plusieurs types

preconnect, prefetch, prerender, preload, dns-prefetch

• pas supporté par tous
• accessible en <link> ou en header HTTP Link:
• certaines fois accessible via JS

gros potentiel mais quelques de difficultés à surmonter

utile pour des pages connues à l'avance : soit par analyse statistiques, soit sur des tunnels

le dns-prefetch ne sert pas à grand chose si le preparser peut les découvrir tout seul ou si les domaines arrivent tôt dans la page

HTTP2 est arrrrivééé

"we’re not replacing all of HTTP — the methods, status codes, and most of the headers you use today will be the same. Instead, we’re re-defining how it gets used “on the wire” so it’s more efficient, and so that it is more gentle to the Internet itself ...." — @mnot

• New binary framing
• One connection (session)
• Many parallel requests (streams)
• Header compression
• Stream prioritization
• Server push

qu'est-ce que ça veut dire du coup ?

S'appuie sur TCP

binary => plus de de Telnet direct sur le port 80

une requête n'est pas obligé d'attendre une réponse pour se lancer

le serveur (donc l'application) peut décider quelles resources sont prioritaires et les prioriser dans le flux (mais concrètement très peu de navigateurs l'utilisent)

le serveur peut envoyer des resources qui n'ont pas encore été requêtées (avec un mécanisme d'annulation possible si le navigateur l'a dans le cache

au niveau des règles ça veut dire quoi ?

Impact sur le waterfall

Impacts sur les règles

• suppression de la concaténation
  • démarrage du parsing et de l'exécution plus tôt
  • optimisation du cache entre les pages
• suppression/limitation du sharding
  • limite le nb de résolutions DNS
  • limite le slow start des nouvelles connexions

sauf si vous avez besoin d'un domain statique

Server Push

• implémentations limitées (h2o, nghttp2, apache, nginx)
• utilise Link: rel="preload"
• attention au cache
• attention à la bande passante disponible
• attention à l'ordre
• attention au domaine

en fait les cas d'utilisations efficaces du push sont aujourd'hui restreints !

• les mécanismes de cancel ne sont pas efficaces (doit traiter PUSH_PROMISE même s'il a envoyé RST_STREAM)
• ne pas balancer bêtement des objets statiques
• en gros "Push is only useful to fill idle network time"

src : https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0/preview

Server Push

Server Push

QUIC

apparu en 2012/2013, utilisé aujourd'hui sur Chrome + serveurs Google

UDP-based : pas TCP avec ces RTT SYN, SYN/ACK, ACK , fire and forget (utilisé pour logguer) mais avec des améliorations

finalement le vrai problème c'est TCP et on peut pas le changer car les piles TCP sont dans les OS et personne, autant utiliser quelque chose de connu

bandwidth estimation in each direction to avoid congestion.

src: http://devsisters.github.io/goquic/, http://blog.davidsingleton.org/mobiletcp/ https://hpbn.co/

QUIC

• UDP = perte de paquets
  • FEC (Forward Erroc Correction)
  • Packet Pacing

QUIC

• multiplexing

QUIC

• Particulièrement important en mobile
• Connection ID

QUIC

Service workers

• Sorte de proxy in-page
• Repose sur la nouvelle API Fetch et les Promises
• Arrive sur les navigateurs doucement
• Contraintes : HTTPS-only & CORS
• Usage : gestion fine du cache, offline, timeout, redirects, inspection, modification, prefetch

thread séparé / peut vivre en background et après le chargement de la page

phase de register puis chargement du script

gestion fine du cache : par exemple, servir un objet "dépassé" du cache plutôt qu'une erreur

if (navigator.offline)

sw-removecookies

sw-delta (envoie la différence entre la version en cache et la version requêtée par le navigateur et présente sur le serveur)

Timeout sync scripts

• Certains scripts sont bloquants (A/B test)
• Possibilité de les timeboxer (<250ms)
• Prévus par certains fournisseurs (Kameleoon, Optimizely)
• Autre solution : Promise.race()

Optimisations TLS

• TLS False Start
• Session Resume
• OCSP Stapling
• TLS1.2 (1.3) + Forward Secrecy

session resume : plus d'échanges de clé pour les sessions en cache

src: https://hpbn.co/transport-layer-security-tls/#certificate-revocation

Et les images ?

Nouveaux formats

JPG 2000, JPG-XR, WebP

WTF ???

en fait, assez facile à comprendre, les imges ce n'est pas que pour le web.

Si certains n'ont pas les outils mour les lire aucun intérêt (l'expérience de FB sur le WebP est significative)

Du coup il reste les anciens formats

Mais ayé Firefox a implémenté WebP !!! (https://bugzilla.mozilla.org/show_bug.cgi?id=1294490)

JPG

• MozJPEG
• Compression avancée
• Meilleure qualité sur les dessins et les images Retina

notamment avec MozJpg

PNG

JPG standard 1

JPG standard 2

MozJPEG

JPG "intelligent"

• DSSIM
• Trouve la meilleure qualité JPG en comparant à l'original
• cjpeg-dssim = jpegoptim + mozjpeg + dssim

notamment avec MozJpg

src: https://github.com/pornel/dssim

GIF

• Possibilité de les transformer en PNG s'ils ne sont pas animés
• Possibilité de les optimiser fortement sinon

J'en ai même vu une de 13Mo sur le site d'Ikea il y a quelques semaines ...

même pas obligé de changer les extension, c'est comme pour les WebP, il suffit de renvoyer le bon content-type en fonction du Accept envoyé par le navigateur

Client Hints

• Prendre en compte le vrai contexte
• Moins de code pour les images responsive

src: http://httpwg.org/http-extensions/client-hints.html

src: https://developers.google.com/web/updates/2015/09/automating-resource-selection-with-client-hints

Client Hints

Client Hints

Client Hints

AMP

• Accelerated Mobile Pages
• Composants HTML sous forte contrainte webperf
• D'abord pour les sites de contenu et premières initiatives pour les sites ecommerce
• Pages AMP mises en avant dans les SERP

je préfère les quelque chose de plus ouvert et générique (CPP)

src: https://amphtml.wordpress.com/2016/08/22/getting-started-with-amp-for-e-commerce/

Nouvelles métriques

Le load time c'est mort

• Speed Index
• Start Render
• Disponible en RUM !

Speed Index

Speed Index

Speed Index

Conclusion

ce qui est toujours d'actualité

• compression des pages : gzip, images
• cache (expires, etags si bien configuré)
• CDN
• CSS on top / deferJS

ce qui est à mettre en place

• chargement progressif (voire offline)
• asynchrone
• avec le moins de requetes DNS possible
• et avec un budget webperf

A prévoir

• suppression sharding
• quasi suppression concaténation
• critical push / inlining / preload
• priorisation des éléments ATF

• in-page perf (rendering, layout, JS, requestAnimationFrame, web workers, memory)
• backend
• outils de mesure, resources timing, navigation timing
• TLS (session reuse, cache, tls record, certificate size)
• TCP (slow start, tcp window scaling, disable slow start after idle)
• WebRTC
• Impact third parties
• AMP
• Content Performance Policy