Quelques outils en ligne

Je vous avais présenté quelques outils, aujourd’hui en voilà trois autres, en ligne.

Le concept de ces outils est le même : on prend une URL, on lance la page, et on trace la cascade des requêtes HTTP avec quelques statistiques. C’est là qu’on voit le temps pris par chaque composant, par la somme des composants, et les éventuels problèmes de performance comme les scripts bloquants.

Pingdom : simple et clair

Le plus simple, et peut être le plus joli, c’est Pingdom. Il se contente de tracer la cascade, en précisant les temps de connexion TCP, d’envoi et de réception, ainsi que les poids des divers composants. Il n’y a pas de paramétrage, et il semble que le moteur se permette de lancer presque 10 connexions simultanées. Bref, n’en faites pas des analyses trop poussées. Par contre pour montrer l’aperçu de la cascade ou un problème significatif au détour d’une conversation, c’est clairement un des outils à retenir. L’interface est en effet suffisamment jolie pour attirer le non-spécialiste.

Site-perf : paramétrable jusqu’au bout

Le deuxième outil en ligne est site-perf. Le site se veut regrouper des informations sur la performance des sites web, mais c’est surtout pour son test de performance en ligne qu’il est intéressant. Il offre plusieurs sources géographiques pour lancer le test et un paramétrage complet : nombre de connexions simultanées, bande passante, latence, qualité de la ligne (% de perte de paquets), compression, keep-alive, login, adresse IP… tout y est. Je n’ai pas fait suffisamment de test pour m’assurer que le résultat est précis ou cohérent avec les outils « de confiance » comme IBM Page Detailer, mais le résultat est sans appel : une cascade précise avec six états, dont le temps de résolution DNS, le détail des informations de cache HTTP, et un résumé cohérent.

Les deux seuls défauts sont la largeur de la cascade, qui mériterait de pouvoir prendre plus de place pour une meilleure lecture, et le manque d’un résumé par type de composant (combien m’ont coûté les images au total ?).

Web Page Test : aussi complet que la version bureau

Le dernier outil c’est webpagetest, la version en ligne de AOL Page Test. La cascade est précise et on peut avoir confiance dans l’outil si c’est juste une automatisation de la version bureau du logiciel. Moins joli que pingdom (en fait même carrément moche), webpagetest est aussi légèrement moins paramétrable que site-perf.

On a accès à trois sources géographiques avec leurs spécificités, et un choix du nombre de requêtes simultanées. Pour rattraper le tout il est possible de scripter le test. On peut aller réaliser un parcours sur le site, envoyer un formulaire ou accéder une page protégée par authentification. Il manque malheureusement la possibilité de modifier finement la bande passante ou de modifier la latence artificiellement. Vu l’importance de la latence dans les tests, c’est dommage.

L’intérêt de webpagetest c’est surtout le résultat. On y retrouve une cascade précise et très claire (en grande largeur), qui comprend aussi les temps de début de rendu et de fin de rendu de la page : indispensable si on veut jouer sur le ressenti utilisateur et pas uniquement sur les chiffres bruts.  Derrière cette cascade on a un résumé ressource par ressource des différents temps et poids, avec toutes les entêtes HTTP. Bref, tout ce qui est nécessaire pour travailler. Il y a même un tableau avec des recommandations pour vérifier des critères comme le cache, gzip, la concaténation css/js, le keep-alive, la minimisation ou le keep-alive.

Le double effet kisskool de webpagetest c’est que ces informations sont fournies en double : une fois pour le premier accès avec un cache vide, et une seconde fois, pour simuler un cache correctement initialisé. Indispensable là aussi. Mieux, cascade et résumés sont disponibles sous forme d’image et peuvent donc facilement être sauvegardés pour un rapport ou pour comparaison entre deux dates.

Publié par edaspet

Plus d'informations sur mon profil en ligne

5 réponses sur « Quelques outils en ligne »

  1. Je suis un fidèle utilisateur de Web Page Test. Vraiment utile et très précis. L’avantage de l’outil c’est qu’on peut l’installer sur des postes à l’étranger pour faire des tests avec des configurations réelles.

  2. Je suis un peu surpris par les résultats du dernier outil cité : je viens de le tester sur un site utilisant des bibliothèques js yui sur le site yahoo via l’api et le rapport me dit qu’elle ne sont pas aussi compressées qu’elles pourraient l’être et que le site hote n’utilise pas de CDN ??
    Use one CDN for all static assets:
    FAILED – http://yui.yahooapis.com/2.5.1/build/history/history-min.js
    FAILED – http://yui.yahooapis.com/2.5.1/build/utilities/utilities.js
    Minify JS:
    WARNING (31.3 KB, minified = 30.2 KB – savings of 1.1 KB) – http://yui.yahooapis.com/2.5.1/build/utilities/utilities.js
    Minify score : 97
    50.7 KB total in minifiable text, target size = 49.6 KB – potential savings = 1.1 KB

    J’ai raté un truc ?

  3. Il te dit que ce n’est pas dans un CDN parce qu’il ne peut pas le deviner. Il tente une heuristique dont les règles sont définies juste plus bas :
    «  » »Checked to see if it is served from a host with « *cdn.* » or « *.yimg.* » domain or if it is being sent as HTTP 1.0 with keep-alive headers (a common Akamai configuration) » » »

    Le CDN Yahoo! en question n’utilise pas Akamai, répond en HTTP 1.1, et est sur un domaine sans *cdn* ni *yimg*. Bref, ces outils sont là pour vous aider, pas plus. Après c’est à vous de trier les warning en fonction de votre connaissance (pour les urls de vos sites, vous savez forcément si votre domaine X ou Y est un CDN).

    Pour la minification (et non la compression), l’algo utilisé peut être plus ou moins radical. Visiblement le leur arrive à gagner 1ko sur 30 et sur 50. Au total 2ko sur 80ko. Pas sûr que la différence soit vraiment importante. Ca peut se résumer à quelques fins de ligne, ou quelques points virgule gardés par un algo moins agressif.

    Bref, tu n’as rien raté, mais pas de quoi s’alarmer ou même de quoi remonter un bug à Yahoo!

  4. Ok, merci pour toutes ces précisions. En regardant le fichier js en question on s’aperçoit qu’il reste un certain nombre de commentaires liés au « copyright », c’est sans doute ça qui fait la différence.

    Merci pour la qualité de ton site 🙂

Les commentaires sont fermés.