Fasterize veut accélérer les sites web en modifiant / optimisant le code HTML

Fasterize veut accélérer les sites web en modifiant / optimisant le code HTML

La carte bleue va chauffer

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

17/09/2013 4 minutes
63

Fasterize veut accélérer les sites web en modifiant / optimisant le code HTML

Fasterize est un service qui permet de réduire instantanément le temps de chargement de vos pages HTML. La société annonce jusqu'à 50 % de mieux et, pour cela, modifie et adapte le code HTML à la volée, le tout misant sur la simplicité de mise en place puisqu'aucun changement n'est à effectuer côté serveur.

FasterizeFasterize

Sans Fasterize / Avec Fasterize

 

Depuis toujours, la rapidité de réponse d'un site web est un élément déterminant, c'est d'ailleurs un critère que Google ne prend pas à la légère, notamment lorsqu'il s'agit du référencement des pages. Pour les revendeurs, un temps de chargement qui augmente, même légèrement, signifie bien souvent des ventes qui diminuent. Fort de ce constat et après plusieurs mois de bêta test, Fasterize se lance aujourd'hui dans l'arène.

Fasterize veut réduire d'entre 30 et 50 % le temps de chargement des pages HTML 

Ce service se définit comme tel : « notre technologie permet de réduire instantanément de 30 à 50 % le temps de chargement de vos pages HTML. Nous ne modifions pas vos serveurs, vos réseaux ou vos bases de données, cela reste votre infrastructure. Nous modifions seulement les pages HTML en nous plaçant en amont de votre site ».

 

En effet, Fasterize est un service qui se place entre le serveur web et l'internaute, en interceptant les pages délivrées par le premier et les modifiant avant de les distribuer au second. Il s'agit donc bien de changer le code HTML afin de l'optimiser, mais aussi de l'adapter aux différentes machines. Sur les terminaux mobiles par exemple, les optimisations ne seront pas les mêmes que sur les ordinateurs. Dans tous les cas, il s'agit d'appliquer « les règles d'optimisation que nous connaissons depuis plusieurs années », que ce soit sur le code HTML, CSS, JS, les images, etc. Bien évidemment, les recettes internes ne sont pas dévoilées.

 

Dans sa FAQ, la société ne cache d'ailleurs pas qu'il est possible de faire ce genre de changements soi-même : « toutes ces règles, je peux les mettre en place moi-même, non ? Oui pourquoi pas. Cela prend du temps et demande de l'expertise ».

 

Un système de cache est également de la partie afin de réduire la consommation de la bande passante et vous pouvez également exploiter plusieurs CDN (Content Delivery Network). Fasterize précise s'être associée avec Amazon Cloudfront et SFR Business Team pour la gestion de ces derniers. Rappelons tout de même que le FAI s'est récemment fait prendre la main dans le sac à modifier des pages web... pour le bien de ses clients mobiles précisait-il à l'époque.

 

Fasterize

 

Notez ensuite que le SSL ne semble pas encore de la partie, « mais cela viendra dans quelques mois ». 

Côté tarif, l'addition peut rapidement devenir salée

Côté tarif, l'addition peut par contre rapidement être salée. En effet, si Fasterize est gratuit jusqu'à 1 000 pages vues par mois (soit à peine plus d'une trentaine par jour). Au-delà, le premier palier est à 10 000 pages par mois pour 9 € HT et jusqu'à 629 € HT pour 750 000 pages par mois, ce qui donne une moyenne de 25 000 pages par jours, un chiffre relativement élevé. Au-delà, votre site n'est pas inaccessible, mais les pages ne sont plus optimisées... à moins que vous ne passiez à la caisse.

 

Notez que les services associés ne sont pas les mêmes non plus : un CDN est offert à partir de 100 000 pages (100 € HT), le support par email n'arrive qu'à partir de 200 000 pages (189 € HT) et il faut monter à 750 000 pages pour avoir le support téléphonique. Dommage que tout le monde ne puisse pas profiter, a minima, d'un support par email.

 

Fasterize

 

Vu les tarifs proposés, certaines sociétés pourraient bien se tourner vers une alternative : embaucher un développeur qui s'occupera de l'optimisation des pages en amont, ce qui permettra de diminuer également la consommation de la bande passante tout en réduisant la charge des serveurs. Notez que d'autres sociétés comme CloudFlare proposent également ce genre de service, mais pour un tarif inférieur.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fasterize veut réduire d'entre 30 et 50 % le temps de chargement des pages HTML 

Côté tarif, l'addition peut rapidement devenir salée

Commentaires (63)


Déjà activer la compression, vous boosterez énormément votre site.. <img data-src=" />

Bon nombre de site ne l’active pas (mojitoring.com permet de détecter la compression et d’autres types d’infos utiles).



Rien en activant la compression, on gagne au moins 40% et ça coute peanut à le faire. <img data-src=" />








AlbertSY a écrit :



Déjà activer la compression, vous boosterez énormément votre site.. <img data-src=" />

Bon nombre de site ne l’active pas (mojitoring.com permet de détecter la compression et d’autres types d’infos utiles).



Rien en activant la compression, on gagne au moins 40% et ça coute peanut à le faire. <img data-src=" />







De quelle compression parles tu?









gazgaz78 a écrit :



De quelle compression parles tu?





Minification je pense



Vous croyez que elysee.fr utilise ce système ils vont peut-être nous faire un retour en open data sur le sujet :http://www.pcinpact.com/breve/82407-elysee-fr-s-ouvre-a-l-open-data.htm <img data-src=" />








Ewil a écrit :



Minification je pense







Ah mon avis c’est plus la compression gzip au niveau d’apache dont il parle.





Nous modifions seulement les pages HTML en nous plaçant en amont de votre site ».







En effet, Fasterize est un service qui se place entre le serveur web et l’internaute, en interceptant les pages délivrées par le premier et les modifiant avant de les distribuer au second.



du coup il est plutôt en aval du site non ? (et en amont du client)

/pinaillage



Opera turbo et un blocker de pub font aussi bien <img data-src=" />








gazgaz78 a écrit :



De quelle compression parles tu?







Compression Gzip entre serveur et client









gazgaz78 a écrit :



De quelle compression parles tu?







La compression serveur j’imagine, les fichiers passent par un algo de compression avant d’etre renvoyes sur le client.



Tiens c’est curieux, ça me fait penser à Peer CDN dont Korben a parlé il y a une dizaine de jours :

http://korben.info/peercdn.html


<img data-src=" /> C’est quoi ses tarifs, même un blog amateur peut avoir facilement plus de 1000 pages vues… surtout si on compte les bots (J’ai réussi à avoir 64 000 pages crawlées dans la journée, rien que chez Google. <img data-src=" />).








Ewil a écrit :



Minification je pense





Avec la compression Gzip la minification CSS et HTML ne sert quasiment à rien… On gagne 1% environ. Je crois que côté JS c’était un poil plus mais ça reste limité.



Waouh ! Leurs tarifs sont hyper compétitifs ! <img data-src=" />



Je pense qu’ils vont pas faire long feu <img data-src=" />


Sachant qu’il suffit d’un peu de bonne volonté et d’un peu de temps pour faire ça (à part le côté CDN qui peut être éventuellement intéressant), c’est clairement hors de prix.



Cloudflare à côté propose une couche pour la sécurité qui peut être pas mal si l’efficacité est là (je n’utilise pas donc j’en sais rien). Bref, je vois pas quel fou irait payer aussi cher pour ça. Je crois que même surdimensionner son serveur coûte moins cher.








gogo77 a écrit :



Je crois que même surdimensionner son serveur coûte moins cher.





Vu les tarifs, je préférerais encore prendre un serveur 2 gammes au dessus, ça me couterais moins cher.<img data-src=" />



À 629 € HT/mois t’as déjà un très bon serveur. Et mettre en œuvre SPDY est limite plus intéressant.





Vu les tarifs proposés, certaines sociétés pourraient bien se tourner vers une alternative : embaucher un développeur qui s’occupera de l’optimisation des pages en amont, ce qui permettra de diminuer également la consommation de la bande passante tout en réduisant la charge des serveurs.





Ou pas.

Un développeur de base en freelance, même pas expert dans le domaine (ou dans un autre d’ailleurs), il facture déjà 300 - 350 euros par journée de 8 heures.



Faire un audit de l’existant, proposer des pistes et les mettre en oeuvre, ce sont des dizaines d’homme jour grand minimum qui alourdiront d’autant la facture.



Donc si on compare le coût d’un développeur spécialisé là dedans à la solution proposée ici, c’est plutôt à l’avantage de leur solution.


Allez mes petits, laissez vos pages passer par nos services, promis, on regarde pas ce qu’il y a dedans… <img data-src=" />



  • Compression GZIP au niveau du serveur Web.





    • Activer le cache



    • Utilisation de sous-domaines pour tous les fichiers statiques (images, JS, CSS…; le nombre de connexion de l’explorateur à un domaine est limité, donc plus de sous-domaines = plus de connexions en parallèles)



    • Suppression de tous les commentaires en CSS, JS et HTML (octets inutiles)



    • Ne pas charger de fichiers (scripts, css…) qui ne sont pas utilisés



    • Fusion de tous les JS d’un côté et de tous les CSS de l’autres (1 fichier de 6ko est plus rapide à DL que 2 de 3ko)



    • Minification des fichiers JS et CSS (donc 2 fichiers en vertu du point précédent)



    • Tailler les images pour leur affichage (si elles s’affichent en 150*150px, avoir une miniature de cette taille et ne pas utiliser width/height)



    • Charger les images à posteriori en JS quand elles ne sont pas sur le premier écran



      Tout ça, c’est pas très compliqué ni dur…



      Après, y a l’optimisation du code côté serveur.

      Là, ça peut être plus compliqué si on code comme un porc…





Nous modifions seulement les pages HTML en nous plaçant en amont de votre site





Pour les sites qui ne font que de la consultation (ça existe encore?). Pour les sites dynamiques, je demande à voir…








kerrubin a écrit :





  • Compression GZIP au niveau du serveur Web.





    • Activer le cache



    • Utilisation de sous-domaines pour tous les fichiers statiques (images, JS, CSS…; le nombre de connexion de l’explorateur à un domaine est limité, donc plus de sous-domaines = plus de connexions en parallèles)



    • Suppression de tous les commentaires en CSS, JS et HTML (octets inutiles)



    • Ne pas charger de fichiers (scripts, css…) qui ne sont pas utilisés



    • Fusion de tous les JS d’un côté et de tous les CSS de l’autres (1 fichier de 6ko est plus rapide à DL que 2 de 3ko)



    • Minification des fichiers JS et CSS (donc 2 fichiers en vertu du point précédent)



    • Tailler les images pour leur affichage (si elles s’affichent en 150*150px, avoir une miniature de cette taille et ne pas utiliser width/height)



    • Charger les images à posteriori en JS quand elles ne sont pas sur le premier écran



      Tout ça, c’est pas très compliqué ni dur…



      Après, y a l’optimisation du code côté serveur.

      Là, ça peut être plus compliqué si on code comme un porc…







      +1

      Et proposer de modifier le poids des pages html/js/css, c’est comment dire…super novateur ?

      Ce qu’il faudrait c’est un nouveau format d’image. Je pense à webP de suite mais il y a sans doute plusieurs autres propositions.




Pour accélérer les choses, il faudrait arrêter de fragmenter le contenu d’une page en une myriade de fichiers éparses.



Sur un site bien fait, comme www.pcinpact.com, la récupération de la page d’accueil nécessite l’envoi d’une centaine de requêtes sur une vingtaine de domaines différents. <img data-src=" />


Je me pose la question du résultat pour les sites dynamiques bourrés d’AJAX si ils modifient le HTML ?



Je me demande aussi comment sont géré les certificats SSL du coup ?



Et si je comprend bien, toutes les données (login, password notamment) sont lu en clair chez Fasteriz ?



Au final, activer la compression GZIP + condenser tout le css / js et utiliser des CDN pour les librairies / framework css permet surement un gain de l’ordre de 2025% avec une ou deux journées de boulots grand max pour un développeur.


et pour ceux qui préfèrent mettre les mains dans le cambouis :http://developers.google.com/speed/pagespeed/insights/ peut les aider!!!


Oups’








kerrubin a écrit :





  • Compression GZIP au niveau du serveur Web.





    À part si on est sur un Atom, ça me semble être le minium.







    kerrubin a écrit :



  • Activer le cache





    Je dirais « quand c’est possible ». Le cache peut aussi être une source de problèmes. Exemple, j’ai pas une seule page identique à cause d’information dynamiques affichés sur la page : j’ai été obligé de forcer la non mis en cache.







    kerrubin a écrit :



  • Utilisation de sous-domaines pour tous les fichiers statiques (images, JS, CSS…; le nombre de connexion de l’explorateur à un domaine est limité, donc plus de sous-domaines = plus de connexions en parallèles)





    J’avais jamais fait attention à ça… pourtant ça pourrait me servir.







    kerrubin a écrit :



  • Ne pas charger de fichiers (scripts, css…) qui ne sont pas utilisés







    Ça dépends, si le CSS et les scripts ont déjà en cache, ça sera plus rapide d’aller le cacher (surtout s’il est déjà compilé). [/quote]

    L’utilisation de SPDY permet d’éviter de ce faire chier à faire ça.







    kerrubin a écrit :



  • Fusion de tous les JS d’un côté et de tous les CSS de l’autres (1 fichier de 6ko est plus rapide à DL que 2 de 3ko)



    [quote:4751047:kerrubin]- Suppression de tous les commentaires en CSS, JS et HTML (octets inutiles)



    • Minification des fichiers JS et CSS (donc 2 fichiers en vertu du point précédent)





      Le gain est négligeable. Ça reste plus souvent à rendre le code illisible qu’autre chose…







      kerrubin a écrit :




  • Tailler les images pour leur affichage (si elles s’affichent en 150*150px, avoir une miniature de cette taille et ne pas utiliser width/height)





    Ça c’est minimum de faire des miniatures d’images. Je vois encore de site qui mettent des photos telles-quelles en miniatures.







    kerrubin a écrit :



    Tout ça, c’est pas très compliqué ni dur…





    Ça dépends pour qui. Quelqu’un qui utilise un CMS est qui n’en a jamais vu le code, j’irais pas lui demander ça.









kerrubin a écrit :



Après, y a l’optimisation du code côté serveur.

Là, ça peut être plus compliqué si on code comme un porc…





Mais pour cette partie Fasterize n’y peux rien non plus.









Virtual_Spirit a écrit :



Je me demande aussi comment sont géré les certificats SSL du coup ?



Et si je comprend bien, toutes les données (login, password notamment) sont lu en clair chez Fasteriz ?







Tout simplement :





Currently, Fasterize doesn’t optimize the HTTPS traffic and it transfers it directly to the origin server. Optimizing SSL traffic is planned in the next months.



For that, you will need to send your SSL certificate and your private key to Fasterize and we encourage you to create a new ticket to our support team.



http://fasterize.uservoice.com/knowledgebase/articles/173810-do-i-need-to-setup-…



Wouhou! C’est la fête!









Khalev a écrit :



http://fasterize.uservoice.com/knowledgebase/articles/173810-do-i-need-to-setup-…



Wouhou! C’est la fête!









<img data-src=" />





<img data-src=" />







127.0.0.1 a écrit :



Pour accélérer les choses, il faudrait arrêter de fragmenter le contenu d’une page en une myriade de fichiers éparses.



Sur un site bien fait, comme www.pcinpact.com, la récupération de la page d’accueil nécessite l’envoi d’une centaine de requêtes sur une vingtaine de domaines différents. <img data-src=" />







En quoi c’est plus lent ? Chaque image, chaque ressource non textuelle, nécessite une requête séparée… vaut mieux ça que recevoir un énorme blob immonde qui va nécessiter un renvoi complet en cas de perte de corruption… et je te parle même pas des caches partiels <img data-src=" />



Après les appels analytics, xiti et autres trackers c’est un autre problème… mais il faut bien avouer que c’est super pratique !









zefling a écrit :



Le gain est négligeable. Ça reste plus souvent à rendre le code illisible qu’autre chose…









Si c’est fait par le serveur web, les code est “nettoyé” / minifié avant l’envoi au client, ça rend le code moins lisible pour le client, mais on s’en fout pas mal. Avec la compression Gzip activé, effectivement le gain se situe autour de 1% seulement. C’est toujours ça d’un côté.



Par contre regrouper tous les fichiers css / js en un seul ça apporte des gains de temps non négligeables.













zefling a écrit :



Ça dépends pour qui. Quelqu’un qui utilise un CMS est qui n’en a jamais vu le code, j’irais pas lui demander ça.







Pour moi, ces optimisations là doivent être faites par le CMS, par par l’utilisateur du CMS. Sauf en ce qui concerne la config serveur évidement, mais pour tout le nettoyage, regroupement des fichiers, utilisation de CDN, suppression des commentaires, utilisations de cache, miniatures / redimensionnement pour les images, …



Pour une début d’optimisation ne suffirait il pas de regarder le code du résultat de leur optimisation puis de modifier en conséquence ? Je sais ça parait simpliste comme ça, il faut que je teste ça <img data-src=" />








Khalev a écrit :



Tout simplement :





http://fasterize.uservoice.com/knowledgebase/articles/173810-do-i-need-to-setup-…



Wouhou! C’est la fête!









Ahah, je suis curieux de voir qui va utiliser ce service… <img data-src=" />







Fuinril a écrit :



En quoi c’est plus lent ? Chaque image, chaque ressource non textuelle, nécessite une requête séparée… vaut mieux ça que recevoir un énorme blob immonde qui va nécessiter un renvoi complet en cas de perte de corruption… et je te parle même pas des caches partiels <img data-src=" />







Pour chaque téléchargement de fichier il y’a un protocole de connexion au niveau TCP qui imposent plusieurs échangent juste pour établir la connexion ensuite seulement les données peuvent être transférés.



ça prend moins de temps d’établir la connexion une fois et d’envoyer ensuite plein de données plutôt que de diviser les données en pleins de petits fichiers en devant à chaque fois établir une nouvelle connexion.



Et je vois pas pourquoi une corruption obligerait le renvoi total du fichier, si un paquet est perdu, c’est juste ce paquet qui sera renvoyé, pas l’ensemble des données, c’est le principe même TCP…










Tirnon a écrit :



Pour une début d’optimisation ne suffirait il pas de regarder le code du résultat de leur optimisation puis de modifier en conséquence ? Je sais ça parait simpliste comme ça, il faut que je teste ça <img data-src=" />







C’est très probable qu’ils rajoutent une petite couche offuscation dans le résultat.









zefling a écrit :



Je dirais « quand c’est possible ». Le cache peut aussi être une source de problèmes. Exemple, j’ai pas une seule page identique à cause d’information dynamiques affichés sur la page : j’ai été obligé de forcer la non mis en cache.







Tout ne peut pas être mis en cache, je suis d’accord.

Mais les fichiers statiques (images, js et css par exemples) peuvent l’être.

Après, tout dépend du langage, mais en .Net (MVC/C#), il est possible de mettre en cache des parties de pages/contenu ou même de conditionner le cache en fonction d’un paramètre (par exemple un identifiant).







zefling a écrit :



J’avais jamais fait attention à ça… pourtant ça pourrait me servir.







Le coup de sous-domaines est réellement avantageux.

Mais il peut être contrebalancé par le nombre de fichiers.







zefling a écrit :



Le gain est négligeable. Ça reste plus souvent à rendre le code illisible qu’autre chose…







Tout dépend des commentaires en question <img data-src=" />

Et après, il y a le serveur qui peuvent le faire à la volée comme l’indique Virtual_Spirit.







zefling a écrit :



Ça dépends pour qui. Quelqu’un qui utilise un CMS est qui n’en a jamais vu le code, j’irais pas lui demander ça.











Khalev a écrit :



Mais pour cette partie Fasterize n’y peux rien non plus.







Y a les bons développeurs et les mauvais développeurs :P

Et aussi ceux qui ne le sont pas.



Après, c’est comme tout, il peut y avoir un très bon CMS qui fait les optimisations et un mauvais gestionnaire qui fait le goret…



Mais que ce soit pour les développeurs ou les gestionnaires, un brin de formation et tout rentre dans l’ordre.





Par contre, faut quand même reconnaître que les gars de chez Fasterize, ils sont pas mauvais. 85ms pour leur page principale et 45ms au refresh, c’est assez respectable (mais à temporiser par le fait que le contenu n’est pas complexe, plutôt statique).









Virtual_Spirit a écrit :



Pour chaque téléchargement de fichier il y’a un protocole de connexion au niveau TCP qui imposent plusieurs échangent juste pour établir la connexion ensuite seulement les données peuvent être transférés.



ça prend moins de temps d’établir la connexion une fois et d’envoyer ensuite plein de données plutôt que de diviser les données en pleins de petits fichiers en devant à chaque fois établir une nouvelle connexion.



Et je vois pas pourquoi une corruption obligerait le renvoi total du fichier, si un paquet est perdu, c’est juste ce paquet qui sera renvoyé, pas l’ensemble des données, c’est le principe même TCP…









Sauf que les fichiers en cache ne nécessitent pas de connexion TCP, c’est tout l’intérêt de la chose.



Sinon, je suis d’accord le terme perte est de trop, j’ai écrit trop vite. Corruption par contre non, et un problème de corruption va obliger à re-télécharger tout le blob (au lieu de seulement l’élément corrompu).



Ah, bien sûr on pourrait aussi parler du délai d’affichage des pages…. tente un ctrl+F5, tu verras que les données textuelles apparaissent bien après les textes (sauf si tu as la fibre éventuellement).









kerrubin a écrit :





  • Compression GZIP au niveau du serveur Web.





    • Activer le cache



    • Utilisation de sous-domaines pour tous les fichiers statiques (images, JS, CSS…; le nombre de connexion de l’explorateur à un domaine est limité, donc plus de sous-domaines = plus de connexions en parallèles)



    • Suppression de tous les commentaires en CSS, JS et HTML (octets inutiles)



    • Ne pas charger de fichiers (scripts, css…) qui ne sont pas utilisés



    • Fusion de tous les JS d’un côté et de tous les CSS de l’autres (1 fichier de 6ko est plus rapide à DL que 2 de 3ko)



    • Minification des fichiers JS et CSS (donc 2 fichiers en vertu du point précédent)



    • Tailler les images pour leur affichage (si elles s’affichent en 150*150px, avoir une miniature de cette taille et ne pas utiliser width/height)



    • Charger les images à posteriori en JS quand elles ne sont pas sur le premier écran



      Tout ça, c’est pas très compliqué ni dur…



      Après, y a l’optimisation du code côté serveur.

      Là, ça peut être plus compliqué si on code comme un porc…





      –&gt;http://browserdiet.com/fr/ <img data-src=" />










Virtual_Spirit a écrit :



Pour chaque téléchargement de fichier il y’a un protocole de connexion au niveau TCP qui imposent plusieurs échangent juste pour établir la connexion ensuite seulement les données peuvent être transférés.





Au niveau TCP, ça s’appelle un Three way handshake, et effectivement c’est source de ralentissement…



… sauf que ça fait des années que le protocole HTTP permet d’enchainer les requêtes dans une même connexion sans avoir à déconnecter et reconnecter pour chaque fichier.

Ca a un nom, c’est HTTP persistent connexion, et ça se matérialise avec le “Connection: Keep-Alive” qu’on peut voir en header d’une requête en HTTP 1.0. C’est devenu un comportement partie intégrante et utilisé par défaut en HTTP 1.1 (une tite RFC pour la route)



Donc sauf à avoir du client avec un WIN95 et du HTTP 1.0, et sauf votre ignorance manifeste sur la chose qui vous fait passer pour des rigolos, le gain réel est sûrement affreusement faible.










Spidard a écrit :



–&gt;http://browserdiet.com/fr/ <img data-src=" />







Ah, pas mal !!

Je garde sous le coude, merci.









Fuinril a écrit :



Sinon, je suis d’accord le terme perte est de trop, j’ai écrit trop vite. Corruption par contre non, et un problème de corruption va obliger à re-télécharger tout le blob (au lieu de seulement l’élément corrompu).





N’importe quoi. <img data-src=" />



Comme dit précédemment, la corruption d’un paquet se règle au niveau du TCP. Ca n’a rien à voir avec les couches supérieures.



Ca fait deux conneries affirmées d’affilées tendance “je fais le malin qui s’y connait”.

A la troisième, t’es d’office <img data-src=" />









zefling a écrit :



<img data-src=" /> C’est quoi ses tarifs, même un blog amateur peut avoir facilement plus de 1000 pages vues… surtout si on compte les bots (J’ai réussi à avoir 64 000 pages crawlées dans la journée, rien que chez Google. <img data-src=" />).





oui mais sachant que dans ce cas, les bots Google n’exécutent pas le javascript <img data-src=" />



C’est ce que fait déjà gratuitement Opera Turbo (sur PC), Opera Mini (sur portable) et ce que faisait Google Web Accelerator.








maxxyme a écrit :



oui mais sachant que dans ce cas, les bots Google n’exécutent pas le javascript <img data-src=" />





Il semblerait que si. J’ai des trucs chargé en JS que j’arrive à voir dans les résultats. <img data-src=" />









zefling a écrit :



Il semblerait que si. J’ai des trucs chargé en JS que j’arrive à voir dans les résultats. <img data-src=" />





aïe dans ce cas… :P

encore que, peut-être que les ressources .js sont chargées mais pas exécutées ?

faudrait savoir comment Fasterize comptabilise vraiment le nombre de pages vues…









Spidard a écrit :



–&gt;http://browserdiet.com/fr/ <img data-src=" />





un des outils qu’il préconisent pour tester les pages (http://www.webpagetest.org/ ) est justement fournis par fasterize !



déjà arrêter d’utiliser dreamweaver serait une bonne chose pour accélérer un site <img data-src=" />








maxxyme a écrit :



aïe dans ce cas… :P

encore que, peut-être que les ressources .js sont chargées mais pas exécutées ?

faudrait savoir comment Fasterize comptabilise vraiment le nombre de pages vues…







J’ai fait un test, j’ai une chatbox en AJAX sur mon site (le contenu n’existe pas en page statique). J’ai fait une recherche avec un truc que j’ai écris dedans : et je l’ai trouvé. Confirmation : Google Bot charge le JS.









127.0.0.1 a écrit :



Pour accélérer les choses, il faudrait arrêter de fragmenter le contenu d’une page en une myriade de fichiers éparses.



Sur un site bien fait, comme www.pcinpact.com, la récupération de la page d’accueil nécessite l’envoi d’une centaine de requêtes sur une vingtaine de domaines différents. <img data-src=" />



En réel, si la page est bien conçue, la plupart de ces requètes sont traitées par le cache du browser.



rien, lire les liens de la news <img data-src=" />








zefling a écrit :



J’ai fait un test, j’ai une chatbox en AJAX sur mon site (le contenu n’existe pas en page statique). J’ai fait une recherche avec un truc que j’ai écris dedans : et je l’ai trouvé. Confirmation : Google Bot charge le JS.





OK. donc conclusion, si on utilise un outil de ce genre, on peut se faire plomber direct à cause des Google bots… ça craint… <img data-src=" />









maxxyme a écrit :



OK. donc conclusion, si on utilise un outil de ce genre, on peut se faire plomber direct à cause des Google bots… ça craint… <img data-src=" />







En même temps, je m’en doutait un peu, le bot qui fait le rendu des pages m’affichait la chatbox dans le rendu de la page.



Donc, avec les quelques 1 000 000 de pages vues par les Google bot sur mon site le mois derniers (et je compte pas les autres), ça ferais mal. <img data-src=" />









psn00ps a écrit :



En réel, si la page est bien conçue, la plupart de ces requètes sont traitées par le cache du browser.







PCINpact étant bien fait, lors d’un refresh de la page d’acceuil il faut recharger… 25 fichiers sur 15 domaines différents, pour un total de 640 ko.



source: www.webpagetest.org









127.0.0.1 a écrit :



PCINpact étant bien fait, lors d’un refresh de la page d’acceuil il faut recharger… 25 fichiers sur 15 domaines différents, pour un total de 640 ko.



source: www.webpagetest.org





J’ai fait le test avec Firebug : 30 ko (875k / 845k de cache) et 14 requêtes - tout sur pcinpact + 1 pour les fontes google.









Virtual_Spirit a écrit :



Ahah, je suis curieux de voir qui va utiliser ce service… <img data-src=" />







Tout site voulant utiliser un CDN en SSL doit faire installer ses certificats sur l’infrastructure du CDN, et donc fournir à son CDN le certificat et la clé privée… rien de spécial de ce point de vue!



Bah j’ai déjà fait tout ça pour mon site, mais ce qui est décisif ça a été de passer a nginx en reverse proxy :-) le nombre de requetes secondes a été multiplié par 4 à ce aue je me souviens :-)








gounzor a écrit :



Bah j’ai déjà fait tout ça pour mon site, mais ce qui est décisif ça a été de passer a nginx en reverse proxy :-) le nombre de requetes secondes a été multiplié par 4 à ce aue je me souviens :-)







Avec nginx, gzip, SSI, php-fpm, memcached, le couple LUA / redis on peut avec un peu d’astuce atteindre les 15000 / 20000 requêtes dynamiques par seconde sur un quad-core. Mais bon ce service s’adresse probablement aux sociétés qui ont un historique et qui sont restées dans l’époque préhistorique.



Effectivement, nginx en reverse proxy pour le dynamique et en direct pour le statique ça fait une différence sensible mais quand on utilise toutes les subtilités ça déchire plus encore. Nginx : <img data-src=" />









francois-battail a écrit :



Avec nginx, gzip, SSI, php-fpm, memcached, le couple LUA / redis on peut avec un peu d’astuce atteindre les 15000 / 20000 requêtes dynamiques par seconde sur un quad-core.





Et dans un cadre pro, combien de dizaines (centaines) d’hommes jours, avec des compétences moins répandues (et donc plus chères) pour arriver à ce résultat ? Combien de k€ de surcoût ?



Souvent, quand on met ça avec dans la balance, il est plus aisé, plus rapide et moins coûteux de commander quelques serveurs en plus pour absorber la charge désirée.









brazomyna a écrit :



Souvent, quand on met ça avec dans la balance, il est plus aisé, plus rapide et moins coûteux de commander quelques serveurs en plus pour absorber la charge désirée.







Si l’architecture est bien conçue… ce qui est rarement le cas quand on se retrouve dans ce genre de situation d’où le recours à des bricolages ou à des services externes.

Passer d’Apache à nginx n’est pas très dur et on peut observer immédiatement un gain de performances spectaculaire, maintenant il y a aussi les contraintes imposées par l’entreprise qui entrent en compte.



Un informaticien peut en très peu de temps (mettons une journée de plate-forme de test) mettre en front-end nginx pour qu’il serve de reverse proxy sur un Apache pour le dynamique mais servir le contenu statique directement donc le coût est ridicule par rapport au gain sans compter qu’il est possible après d’élaborer de nouvelle pistes d’optimisations sur une base saine.



PS à l’équipe PCi : <img data-src=" /> l’autorefresh c’est très chiant surtout quand on essaye de taper un commentaire.



Y a que moi qui ai pensé « WTF » en regardant les deux premières images de la news (et [url=http://static.pcinpact.com/images/bd/news/138778.png]là) ?



Parce que bon, la légende « Site Web » pour la boîte contenant les utilisateurs du site, voilà quoi… Personnellement il m’a fallu un moment pour intégrer que la partie gauche c’était les utilisateurs (ma première analyse avait pris en compte avant tout les légendes textes, plus faciles à interpréter pour moi qu’une illustration pas forcément des plus parlantes en particulier avec le contraste pas terrible), et donc comprendre où se plaçait leur service dans le schéma (qui comme l’idnique la news est au final un équivalent de Cloudflare en bien plus cher).



Et les tarifs, c’est un WTF de plus ! Quand on voit le nombre de pages vues sur des petits sites peu fréquentés, c’est juste complètement aberrant… À part sur des marchés publics dans le cas où ils ont des copains dans les décideurs, je vois pas où ils pourraient trouver des clients à ce prix là.









francois-battail a écrit :



PS à l’équipe PCi : <img data-src=" /> l’autorefresh c’est très chiant surtout quand on essaye de taper un commentaire.





Tout à fait d’accord. J’en ai eu deux au final là sur la news : un pendant la lecture du sujet, et un lors de l’écriture de ce commentaire après lecture des 6 pages. C’est exaspérant, mais c’est aussi plus que surprenant de la part de PC INpact qui il n’y a encore pas si longtemps se vantait de ne pas avoir recours au rechargement automatique des pages pour « gruger » sur les visites et les affichages de pub, contrairement à nombre de leurs concurrents. J’espère que c’est plus un glitch lié à un bug ou une campagne de pub mal faite et ne correspondant pas à la charte de PC INpact qu’un changement volontaire et durable.









Gorkk a écrit :



C’est exaspérant, mais c’est aussi plus que surprenant de la part de PC INpact qui il n’y a encore pas si longtemps se vantait de ne pas avoir recours au rechargement automatique des pages pour « gruger » sur les visites et les affichages de pub, contrairement à nombre de leurs concurrents. J’espère que c’est plus un glitch lié à un bug ou une campagne de pub mal faite et ne correspondant pas à la charte de PC INpact qu’un changement volontaire et durable.





Ah bah non c’est un meta refresh (edit : grumpf, la balise [code] ne marche pas pour mettre le meta dans le comment, y a une balise sur PCI pour mettre du code à ne pas interpréter ?) dans la page…



PC INpact, pourquoi ce revirement tout d’un coup ? Vous aviez pourtant il me semble bien identifié que c’était avant tout extrêmement énervant pour vos lecteurs non ?









francois-battail a écrit :



PS à l’équipe PCi : <img data-src=" /> l’autorefresh c’est très chiant surtout quand on essaye de taper un commentaire.





+1.



C’est quoi cette (très mauvaise) blague <img data-src=" />









brazomyna a écrit :



+1.



C’est quoi cette (très mauvaise) blague <img data-src=" />





+1 (avec firefox) quelle est cette nouveauté pas cool?<img data-src=" />









Gorkk a écrit :



PC INpact, pourquoi ce revirement tout d’un coup ? Vous aviez pourtant il me semble bien identifié que c’était avant tout extrêmement énervant pour vos lecteurs non ?





On en reparlera bientôt, mais je ne peux rien dire de plus pour le moment. Rien de grave, quoi qu’il en soit (m’envoyer un mail si besoin) <img data-src=" />









geekounet85 a écrit :



et pour ceux qui préfèrent mettre les mains dans le cambouis :http://developers.google.com/speed/pagespeed/insights/ peut les aider!!!





Merci pour ce lien !



Je ne connaissais pas … honte à moi ! <img data-src=" />



nsahttps bonjiours