Analyse de qualité et performance web
https://internethistory.yahoo.co.jpRapport généré le 29 mai 2017 19:35:09
Requêtes
Poids
Technologies :
Partagez ce rapport par email
N'hésitez pas à diffuser ce rapport auprès de vos collaborateurs,
soit en copiant son URL depuis la barre d'adresse, soit en cliquant ci-dessous :
Partager le rapport par e-mail
Bonnes pratiques et conseils :
jQuery
Ce que vous pouvez améliorer
Certaines ressources sont très lourdes
Les fichiers trop lourds sont à proscrire sur une page web. Assurez vous que tous les éléments du fichier sont nécessaires au chargement de la page. Vous pouvez mettre en oeuvre plusieurs types d'actions :
- 10 de ces fichiers utilisent le format PNG. Il est très certainement préférable de les exporter au format JPEG
- s'assurer que les images sont délivrées aux dimensions d'affichage utilisées sur votre site
- compresser la ressource
- fragmenter la ressource et la répartir sur plusieurs requêtes
Cette page contient 10 fichiers dont la taille est supérieure à 1Mo :
Cette page charge 34,93 Mo de données, diminuez ce poids
Le poids de votre page est important, ce qui ralentit sa vitesse d’affichage, d’autant plus sur les connexions bas débit. Cela peut également générer de la frustration pour vos internautes qui sont limités par des forfaits data (voir whatdoesmysitecost.com).
Situer le poids de ma page web
En février 2016, le poids moyen des 100 pages les plus visitées dans le monde était de 1,38Mo.
Comment réduire le poids de ma page ?
Vous pouvez vous reporter à notre catégorie "Volume de données" pour voir quelles sont les optimisations possibles dans votre cas. De manière générale, les images sont souvent à pointer du doigt.
Veillez aussi à construire vos pages web de manière à charger d’abord ce qui est essentiel à l’internaute en priorité (optimisation du chemin critique de rendu).
Pour tout autre contenu (plugins de réseaux sociaux, publicités, contenus situés en bas de page...), il est préférable de différer le chargement (asynchrone, lazy-loading...), pour ne pas pénaliser les contenus prioritaires.
Nous vous conseillons par ailleurs fortement de définir des budgets de performance pour mener à bien vos projets web. Ces budgets sont paramétrables grâce à la fonctionnalité de monitoring de DareBoost.
Afin de vous aider à établir vos priorités d'optimisation, voici la répartition du poids de la page par type de ressources :
- Images : 97,76% du poids total
- JavaScript : 1,38% du poids total
- JSON : 0,59% du poids total
- Textes : 0,18% du poids total
- Polices de caractères : 0,04% du poids total
- CSS : 0,04% du poids total
Par ailleurs, voici les 10 ressources les plus lourdes qui sont téléchargées lors du chargement de votre page :
- history.c.yimg.jp//common/background[...]g/bg_pc_mid5.png (3547 ko)
- history.c.yimg.jp//common/background[...]g/bg_pc_mid3.png (3384 ko)
- history.c.yimg.jp//common/background[...]g/bg_pc_mid0.png (3383 ko)
- history.c.yimg.jp//common/background[...]g/bg_pc_mid1.png (3311 ko)
- history.c.yimg.jp//common/background[...]g/bg_pc_mid4.png (3120 ko)
- history.c.yimg.jp//common/background[...]g/bg_pc_mid2.png (2933 ko)
- history.c.yimg.jp//common/background[...]g/bg_pc_mid6.png (1602 ko)
- history.c.yimg.jp//common/animation/[...]t/animation4.png (1480 ko)
- history.c.yimg.jp//common/animation/[...]t/animation3.png (1172 ko)
- https://history.c.yimg.jp//common/mother/mi_body/mi2.png (1057 ko)
Le format PNG n'est pas le plus adapté pour 1 de vos images
Le choix d'un format adapté pour une image permet de réduire son poids.
Le format PNG
Le format d'images PNG est destiné aux images nécessitant la fonctionnalité de transparence, ou encore aux petites images, disposant de peu de détails et de couleurs.
Préférez le format JPEG...
Le principal défaut du format PNG est de ne pas supporter la perte de qualité. En effet, un format tel que JPEG propose de "dégrader" la qualité de l'image sans que cela ne soit perceptible par l'utilisateur. Vous pouvez ainsi diminuer la qualité de l'image d'environ 25% sans que vos utilisateur ne s'en rendent compte.
Une image avec un poids important sera donc sans doute mieux compressée en utilisant le format JPEG.
...ou PNG-8
Dans le cas ou votre image nécessite obligatoirement d'utiliser le mécanisme de transparence, non supporté par le format JPEG, vous devriez convertir votre image PNG "classique", en PNG-8. Ce format, basé sur une palette de 256 couleurs maximum permet de diminuer le poids de l'image sans altérer significativement sa qualité en général. Des outils tels pngquant ou encore tinypng vous aideront dans cette démarche.
Enfin, si la qualité proposée par le format PNG-8 n'est pas satisfaisante pour votre image, vous pouvez vous renseigner sur les techniques avancées possibles (EN) pour obtenir ce comportement sans délivrer une image au format PNG. Par exemple, il est possible de séparer votre image en 2 images JPEG, l'une contenant les données de transparences et l'autre contenant les données liées aux couleurs, et de regrouper l'image côté client à l'aide d'un élément CANVAS.
Pour en savoir plus, n'hésitez pas à consulter cet article sur la compression des images (EN).
Il semble que le format JPEG soit plus adapté pour les images suivantes :
Différez l'utilisation du code JavaScript
Lorsque le navigateur web rencontre du code JavaScript en interprétant le code source d’une page web, cela peut ralentir considérablement l’affichage de la page, surtout s’il est nécessaire de télécharger un script externe.
Différez au maximum l’utilisation du Javascript pour assurer un début rapide de l’affichage de la page.
Que faire ?
Utilisez si possible l'une des techniques suivantes pour des appels à des fichiers externes :
- utilisation de l'attribut async
- utilisation de l'attribut defer
- ajout du script dans le DOM en JavaScript, lors de l'évènement onload
- placer les scripts à la fin de votre code source (idéalement à la fin du <body>)
1005.1 Ko du code JavaScript sont analysés lors du chargement initial de la page. Différez l'analyse de ce code pour éviter de bloquer l'affichage de la page.
- s.yimg.jp/images/e[...]s.js (519.6 Ko)
- s.yimg.jp/images/e[...]p.js (442.3 Ko)
- staticxx.facebook.[...]n=42 (36.0 Ko de code JavaScript intégré)
- www.facebook.com/v[...]mall (6.2 Ko de code JavaScript intégré)
- internethistory.ya[...].jp/ (508 o de code JavaScript intégré)
- cdn.api.b.hatena.n[...]nter (444 o de code JavaScript intégré)
Définissez au moins des balises <h1> et <h2>
Il est recommandé de placer vos mots clés dans les balises de titres (h1 et h2 au minimum). Les moteurs de recherche utilisent les balises h1, h2 et h3 pour le référencement (SEO).
Aucune balise h1, h2 ou h3 n'a été détectée sur cette page.
Il manque une politique de sécurité sur la provenance de vos ressources
Il est primordial de restreindre la provenance des contenus d'une page en vous prémunissant d'attaques de type XSS (Cross-Site Scripting).
Les attaques XSS
Une attaque de type XSS (Cross-Site scripting) a pour objectif d'injecter un contenu sur la page.
Pour accroître votre protection contre ces attaques, mettez en place une politique de sécurité qui va expliciter au navigateur web les serveurs qui sont autorisés à délivrer des ressources pour former la page. Si le navigateur effectue une requête vers un serveur non autorisé, il doit en informer l'internaute.
La solution : configurer un en-tête HTTP "Content-Security-Policy" (CSP)
Pour spécifier une politique de sécurité sur la provenance de vos ressources, vous devez configurer votre serveur afin que la réponse de la ressource principale contienne l'en-tête HTTP "Content-Security-Policy".
Voici un exemple d'utilisation de cet en-tête :
Content-Security-Policy: script-src 'self' https://apis.google.com
Dans ce cas, la page se charge correctement à condition que tous les scripts proviennent de l'hôte courant ou de https://apis.google.com.
Le lien suivant vous aidera à en savoir plus sur cet en-tête HTTP. Vous serez alors ammené à utiliser les directives exposées sur ce lien.
Soyez vigilant, si l'en-tête est mal configuré, certains de vos contenus, scripts, ou encore styles pourront être bloqués, ce qui pourrait engendrer des effets de bords non souhaités. De plus, les restrictions s'appliquent à toutes les pages du site. Nous vous conseillons de tester les différentes pages de votre site avant de déployer l'instruction dans votre environnement de production.
Aucune CSP n'a été détectée sur cette page : elle est plus facilement exposée à des attaques de type XSS.
Saviez-vous que ?
Les ressources les plus lentes de la page
Le temps total de chargement de la page est de 46.2 secondes. Voici les requêtes les plus lentes provenant du nom de domaine de la page, et qui constituent des points de vigilance :
- b3.yahoo.co.jp/b?P=fo3KnjEyNC6.zzWiB86o[...]0.5908221535926836 (1563ms)
- https://internethistory.yahoo.co.jp/ (1023ms)
- https://internethistory.yahoo.co.jp/ (328ms)
- history.c.yimg.jp//common/animation/spr[...]eet/animation5.png (32267ms)
- history.c.yimg.jp//common/background/bg[...]png/bg_pc_mid6.png (24172ms)
- history.c.yimg.jp//common/background/bg[...]png/bg_pc_mid2.png (20487ms)
- https://history.c.yimg.jp//common/mother/mi_body/mi0.png (18017ms)
- https://history.c.yimg.jp//common/mother/mi_body/mi2.png (15533ms)
- history.c.yimg.jp//common/background/bg[...]png/bg_pc_mid3.png (14424ms)
- history.c.yimg.jp//common/background/bg[...]png/bg_pc_mid1.png (14420ms)
- history.c.yimg.jp//common/background/bg[...]png/bg_pc_mid0.png (14262ms)
- https://history.c.yimg.jp//common/mother/mi_body/mi3.png (11898ms)
- https://history.c.yimg.jp//common/mother/mi_body/mi1.png (11149ms)
Un temps de réponse excessif peut indiquer un traitement important demandé au serveur destinataire de la requête, une ressource trop lourde, ou bien un problème réseau temporaire.
Pour plus d'informations sur le détail du chargement de la page, consultez la timeline.
Attention aux commentaires au sein du code source
Ne transmettez à vos internautes que les données dont ils ont besoin.
Pages web et commentaires dans le code source
Les commentaires dans le code source sont indispensables aux développeurs : ils permettent de détailler une portion de code complexe, et aident à naviguer plus efficacement dans le DOM. Cependant, il n'y a aucun intérêt à communiquer ces informations à vos utilisateurs. Les seuls commentaires dont la présence est justifiée sur le navigateur de l'internaute sont ceux permettant la compatibilité de votre site sur toutes les plateformes (exemple : rendre le site compatible avec Internet Explorer 8).
Veillez donc à ne pas y exposer des données sensibles pouvant permettre à une personne malveillante de corrompre votre système. Par ailleurs, rien ne justifie que des blocs de code soient transmis à vos visiteurs.
En savoir plus sur la performance avec jQuery
jQuery est la librairie JavaScript la plus utilisée aujourd'hui. Rendez votre site plus performant en respectant ses bonnes pratiques. Pour connaître les fondamentaux de la performance jQuery, nous vous conseillons de lire le lien suivant: http://learn.jquery.com/performance/.
Cette page comporte 8 liens
Il existe 2 grands types de liens :
- les liens internes, qui font référence aux pages du même nom de domaine
- les liens externes, qui pointent vers d'autres sites (doivent être pertinents et pointer vers des contenus de qualité)
Si vous faites référence à de nombreux liens, vous pouvez demander aux algorithmes de référencement de ne s'intéresser qu'à certains d'entre eux, en ajoutant un attribut rel=nofollow sur ceux qui ne sont pas pertinents (ex: publicités).
Voici la répartition des 8 liens contenus dans la page :
- 6 liens internes (75,00%)
- 2 liens externes "follow" (25,00%)
- Aucun lien externe "nofollow" (0,00%)
Votre serveur ne devrait pas pouvoir communiquer en HTTP alors qu'il dispose d'une connexion HTTPS
Prémunissez vous d'attaques du type "man in the middle" en vous assurant de communiquer uniquement en HTTPS avec le serveur.
L'en-tête HTTP Strict Transport Security (HSTS)
Lorsque vous communiquez avec un serveur via une connexion sécurisée, il est recommandé que toutes les requêtes envoyées vers ce serveur utilisent le protocole HTTPS. L'en-tête HTTP HSTS permet d'indiquer au navigateur que toutes les requêtes envoyées vers le domaine concerné doivent se faire via HTTPS. Ainsi si l'URL est présentée sous la forme "http://...", le navigateur web va automatiquement la remplacer par "https://...".
Nous vous conseillons cependant de ne mettre en place cet en-tête à l'unique condition que votre site entier desserve ses ressources en HTTPS.
Aucun en-tête HSTS n'a été détecté sur cette page.
4 ressources de cette page sont destinées à une utilisation publique
Par défaut, le navigateur n'accepte d'effectuer des requêtes AJAX, ou encore de récupérer des polices web, que sur le nom de domaine de la page. Une police de caractère définie sur toto.com ne pourra donc être utilisée que par les pages de toto.com. Cela évite une mauvaise utilisation de vos ressources par n'importe quel site.
Certaines ressources sont publiques, et veulent explicitement être mise à disposition de chacun (ex: les Google Fonts). Dans ce cas, l'en-tête HTTP Access-Control-Allow-Origin peut-être utilisé, avec la valeur "*". Vous ne devez cependant utiliser cette propriété que si votre ressource a bien pour objectif d'être utilisée par le plus grand nombre. Sinon, nous vous conseillons de garder la valeur par défaut, ou de définir un nom de domaine spécifique dans l'en-tête Access-Control-Allow-Origin.
Vous devriez porter votre vigilence sur les ressources suivantes, qui utilisent un en-tête HTTP Access-Control-Allow-Origin:*. Assurez vous qu'elles sont effectivement destinées à être utilisées par des pages de tous horizons :
Les ressources suivantes sont hébergées par un parti tiers, il se peut donc qu'elles ne soient pas sous votre responsabilité. Vous devriez cependant considérer toute alternative possible à ces fichiers pour rester en accord avec la bonne pratique.
Bravo ! Vous respectez les bonnes pratiques suivantes
Cette page ne contient pas de scripts inline trop longs
Vous devriez permettre la mise en cache de tout script ayant une taille non négligeable, afin de réduire le temps de chargement de vos pages.
Scripts inline / mise en cache
Les scripts dits "inline" permettent d'intégrer facilement de petites portions de scripts directement dans le code HTML. Exemple :
<script type="text/javascript">
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']...,'/analytics.js','ga');
ga('create', 'UA-11111111-1', 'monsite.com');
</script>
En procédant ainsi, vous évitez d'effectuer une requête vers le serveur pour récupérer la ressource. Les scripts inline représentent alors un gain de performance pour intégrer de petits scripts.
Dès lors qu'un script dispose d'une taille assez conséquente, nous vous conseillons de l'externaliser et d'effectuer une requête pour le récupérer. Cela vous permettra de bénéficier des mécanisme de cache sur la ressource.
Que faire ?
Externalisez vos scripts de plus de 1 500 caractères dans un ou des fichiers distincts.
Vous n'avez pas de script inline trop long sur cette page.
La balise <noscript> est définie
Cette page utilise la balise noscript. Celle-ci permet d'afficher un message lorsque le JavaScript est désactivé par l'utilisateur.
Une description est définie sur cette page
La page doit disposer d'une description unique.
Utilisation de la description par les moteurs de recherche
Lorsqu'elle est bien configurée, la description de la page se retrouve directement dans les résultats de recherche:
Cette description vous permet de maîtriser au maximum l'affichage sur les résultats des moteurs de recherche, et d'améliorer le taux de clics vers votre page. En savoir plus.
Comment définir la description d'une page ?
La description de la page est renseignée grâce à la balise <meta name="description" content="description de la page">, qui doit être placée dans la balise <head>, au début du code.
Cette page définit une <meta> description :
さあ、インターネットの軌跡を旅しよう。 - Yahoo! JAPAN #インターネットの歴史
Cette page utilise uniquement des formats d'images standards
Les images au format non standard risquent de ne pas être indexées par les moteurs de recherche.
Seuls certains formats d'images sont considérés comme standards sur le web : jpeg, jpg, png, gif, svg, ico, webp. Vous devriez considérer une alternative à tout autre format.
Par ailleurs, pensez à soigner le texte entourant vos images: certains moteurs de recherche analysent les 10 mots (environ) précédents et suivants l'image, pour restituer son contexte.
Aucune balise frameset, frame ou noframes détectée
Ces balises sont aujourd'hui à proscrire, car elles présentent des problèmes pour la cohérence de navigation, le référencement, ou encore la sauvegarde de pages dans les favoris d'un navigateur.
Aucune de ces balises n'est détectée sur cette page.
L'utilisation de la balise iframe est préférée.
Un titre est défini sur cette page
La page doit disposer d'un titre unique.
Utilisation du titre par les moteurs de recherche
Lorsqu'il est bien configuré, le titre de la page se retrouve directement dans les résultats de recherche :
L'utilisation d'un titre adapté est un critère important pour le référencement. De plus, il vous permet de maîtriser au maximum l'affichage sur les pages de résultats, et d'intégrer les mots clés sur lesquels vous souhaitez que votre site ressorte.
Comment définir le titre d'une page ?
Le titre de la page est renseigné grâce à la balise <title>, qui doit être placée dans la balise <head>, au début du code.
Cette page définit bien un titre via la balise title.
Voici le titre défini :
The Mother of Internet インターネットの歴史 - Yahoo! JAPAN