Journal Autohébergement : mon retour d'expérience acte 2

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
10
23
jan.
2015

Dans mon dernier journal, je relatais mon retour d'expérience sur l'autohébergement et j'en avais conclu que c'était, pour moi, une solution idéale afin d'héberger des sites à faible coût tout en liberté. Depuis je n'ai pas remis en cause mon jugement, jusqu'au moment où j'ai décidé de programmer une nouvelle version de mon blog et je me suis intéressé de très près aux performances. Dans cette nouvelle version j'avais envie de proposer un contenu plus enrichi, plus de fonctionnalités notamment en utilisant du jquery de façon modéré en programmant mes propres plug-ins. Jusque là pas de problème, mais c'est en visitant l'application depuis mon smartphone ou en demandant à des amis de me donner un retour sur la vitesse de chargement que j'ai été confronté à ce problème si commun : le débit ascendant de l'ADSL.

Je le savais déjà, mon débit en upload est très faible (70 à 80 ko) mais je me suis persuadé qu'en activant la compression gzip et l'expiration des ressources, la vitesse de chargement devrait être correcte. Grosse erreur de ma part, car après quelques essais c'est tout simplement catastrophique au point de m'en déprimer sérieusement. Pourtant, il existe pas mal de petits blogs autohébergés et très agréables à visiter qui se chargent en moins de 3 secondes environ, mais ces derniers sont minimalistes, n'utilise pas jQuery et les articles ne contiennent aucune image. Du côté de mon blog, ce dernier totalise plus de 14 secondes puisque la page contient quelques images dont la plupart sont en 1920x1080 (oui se sont des captures d'écran de jeux vidéo :p).

Sur ma nouvelle version, je m'en suis résigné à compresser au maximum les images et même de les redimensionner en 1280x720, mais malgré tout les performances sont très mauvaises. J'ai donc décidé de n'insérer qu'une image, la vignette de l'article et là pareille, les performances ne sont pas terribles. J'obtiens un temps de chargement d'environ 6 secondes, et ce même lorsque je décide de ne charger aucune image. En fait, le problème n'est pas l'optimisation ou bien la taille des ressources, mais mon débit ascendant pitoyable. Je ne peux absolument rien faire, puisqu’une page sans image pèse environ 365ko. En ne gardant que jquery pour utiliser le plug-in debug de CakePHP, une page passe à 66ko et se charge en un peu plus d'une seconde !

Bref, alors soit je fais de l'autohébergement et je développe des applications ultras minimalistes pour ne pas maltraiter ma bande passante ou bien je dépose les armes. Bien évidemment, le problème c'est avant tout mon infrastructure et mes besoins qui ne correspondent pas avec l'autohébergement. Pour le moment, je n'ai pas encore pris de décision, mais je pense que je vais arrêter les frais, du moins tant que je ne disposerais pas d'une vraie connexion à Internet. Si je décide d'arrêter, honnêtement je ne prendrais rien d'autre qu'un serveur dédié, car j'ai pu remarquer que mon hébergement mutualisé rame encore plus que mon serveur. C'est pour dire, une simple requête ajax prend énormément de temps et bloque la page lorsque j'ai besoin faire un 'async : false'… En même temps, je trouve ironique de vouloir absolument autohéberger un blog à la maison quand celui-ci n'affiche rien d'autre que du texte avec un script css minimaliste. Bref, je suis blasé…

  • # Latence

    Posté par  . Évalué à 8. Dernière modification le 23 janvier 2015 à 13:21.

    Il y aussi la latence qui compte, c'est à dire le temps pour une requête de faire l'aller retour jusqu'au serveur. Les serveurs sont généralement hébergé proche des grands noeud d'interconnexion pour cette raison. Sur une page web avec les images, css et js il y a facilement une vingtaine de requête à faire. En faisant un ping sur ton serveur depuis l'extérieur vs un ping sur le serveur de google tu verras la différence.

  • # CDN ?

    Posté par  (site web personnel) . Évalué à 5.

    Alors, pour ce genre de problèmes, y a une solution assez universelle, qui est le CDN.
    Tu pourrais mettre tout ton site derrière un CDN, mais je suppose que dans le cadre de l'auto-hébergement, tu ne souhaites pas le faire.
    Tu peux au moins le faire pour certains morceaux.
    Tu dis que une page "sans rien" fait 66ko… Ça matche pas ma description de "rien".
    Si parmi ces 66ko, tu as des bibliothèques bien connues (entre autre tu mentionnes jquery), tu peux utiliser des CDNs publiques pour ces bibliothèques ! (cf https://code.jquery.com/ ou https://developers.google.com/speed/libraries/devguide )
    Tu pourrais aussi imaginer utiliser un CDN pour tes images (je crois que imageshack le fait ?)

    • [^] # Re: CDN ?

      Posté par  . Évalué à 3.

      Vas y envoies le CDN gratos stp.

    • [^] # Re: CDN ?

      Posté par  . Évalué à 2.

      L'utilisation de CDN pour jQuery permet aussi des économies pour le visiteur pour peu qu'il ait déjà visité un site utilisant le même jQuery.
      Je ne sais pas si profiter d'un hébergement externe pour les images est compatible avec l'esprit "autohébergement" mais pour les CSS ca ne doit pas choquer.

    • [^] # Re: CDN ?

      Posté par  (site web personnel) . Évalué à 1.

      Oui j'ai oublié de mentionner que j'ai fais un essaie en utilisant les CDN, bien que ça améliore la vitesse, il reste le problème de mes plugins js et des autres ressources comme ma webfont qui pèse 100ko environ…

    • [^] # Re: CDN ?

      Posté par  . Évalué à 9.

      CDN est un peu l'inverse de l'autohebergement… Tellement l'inverse que, pour moi, c'est la quintessence du concept du "Cloud" (au sens le plus large et le plus vague du terme - c'est dire). Avec un CDN, tu ne sais VRAIMENT pas ou se trouvent tes données et tu n'as absolument aucun controle dessus…

      Oui, un CDN est bourré d'avantages pour les perfs, la resilience, etc mais c'est carrement une autre facon de penser l'hebergement…

      • [^] # Re: CDN ?

        Posté par  (site web personnel, Mastodon) . Évalué à 0.

        Oui, c'est un peu de l'hébergement distribué en fin de compte.

        Un peu la philosophie du net quoi…

        • [^] # Re: CDN ?

          Posté par  . Évalué à 3.

          De l'hébergement distribué contrôlé par un fournisseur centralisé.
          Un peu la philosophie du net pour ceux qui ne l'ont pas comprise, quoi…

      • [^] # Re: CDN ?

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 27 janvier 2015 à 00:27.

        Est-ce que savoir où est stocké jquery est important ?
        (Ok on peut vouloir rajouter des signatures de sécurité.)
        Les vraies données, le contenu, restent chez toi.

  • # Rien que du texte

    Posté par  . Évalué à 10. Dernière modification le 23 janvier 2015 à 13:30.

    Ouais, c'est vrai, n'avoir que du texte et des petites images c'est tout nul. C'est comme les vieux trucs, vous savez, ça, les livres quoi. Que du texte, aucun intérêt.

    Et sinon à part ça, « une page sans image pèse environ 365ko », sérieux ? Tu crois pas que juste tu abuses avec des effets à la con qui ne servent à rien ? Même le site de cdiscount pèse moins lourd. Je suis généralement d'accord pour dire que c'est dommage qu'on ne puisse pas avoir mieux à la maison en ascendant, mais là je pense juste qu'il y a un problème avec ton site. Je ne tiens pas à devoir télécharger autant à chaque fois que je cherche une info sur un site random.

    Vendredi, quand tu nous tiens.

    • [^] # Re: Rien que du texte

      Posté par  (site web personnel) . Évalué à 3.

      Cela ne me dérange pas de mettre que du texte, mais le problème c'est qu'aujourd'hui très peu de personne aime lire sans illustrations. Si aujourd'hui, il était possible d'écrire des articles sans attacher la moindre photo, image ou vidéo, je le ferais. Je suis le premier à préférer un article contenant que du texte, car quand je lis un article je me concentre uniquement sur le texte pas les images.

      Par contre, www.cdiscount.com, rien que la page d'accueil c'est 3.3mo, ce qui donne 2,53 secondes…

      • [^] # Re: Rien que du texte

        Posté par  . Évalué à 7. Dernière modification le 23 janvier 2015 à 15:43.

        mais le problème c'est qu'aujourd'hui très peu de personne aime lire sans illustrations

        Ben, un article sur un jeu sans au moins un screenchot, c'est plutôt logique. Un article sur la photographie aussi. Je parle même pas des articles sur les films.
        Bref, un article sur du contenu multimédia, c'est sûr qu'une ou deux images, pas trop grosses (400x300 c'est déjà pas mal pour décorer un article, voire même trop gros. Si c'est trop petit, je pense que les miniatures sont la meilleure solution…).

        Par contre, je n'ai que rarement vu des docs/tutos/articles de qualité sur des sujets techniques avec des images autres que des schémas (oui, je considère les screenshot d'IDE comme une aberration, parce que perso, je m'en contre fout du thème windows/gnome/kde d'eclipse/VS/anjuta/blabla. En plus, on peut pas sélectionner de morceau de texte, ça pue). Hors, avec les schémas, le meilleur moyen de faire un truc à la fois propre léger, et portable, c'est le format SVG.

        Pour réduire la taille de tes fichiers JS, tu peux aussi les minifier. C'est à dire: virer les commentaires, transformer les noms de fonction et de variables en noms à 2 caractères (voire 1 seul, selon le nombre), virer les espaces et retours à la ligne… bref, rendre le JS encore plus illisible que nature, mais au moins plus léger.
        Pendant que j'en parle, si tes pages sont longues, tu peux aussi faire la même avec le contenu XML: virer tout caractère non signifiant.
        Certes, pour le débogage, c'est pénible, mais en même temps, quand je distribue un soft pour utilisation, j'y enlève les outils de débogage, même si je laisse le code source à côté… je vois pas ce qu'il y à de mal à faire pareil sur le web?

        Ah, et pour finir, si ce sont les images le problème, pourquoi ne pas les charger après le reste de la page? J'ai déjà vu plus d'un site le faire, ça doit donc être faisable…

      • [^] # Re: Rien que du texte

        Posté par  . Évalué à 1. Dernière modification le 23 janvier 2015 à 15:51.

        ouais le site cdiscount c'est vraiment une horreur en terme de chargement et de navigation.

        Ton site http://cobra-system.fr/ rend vraiment bien, je le trouve assez épuré et quand même bien plus joli que le site de Stallman. Par contre les images de chaque article sont énormes, il n'y a pas moyen d'avoir des vignettes plus petites et rééchantillonnées depuis la page d'accueil ?

        Je n'ai pas remarqué de latence en le visitant.

        (edit : je n'ai pas vu que tu parlais du nouveau site ici : http://cobra-system.genku.net/tests/5-risen-2-dark-waters, effectivement, ici c'est plus poussif. Ton serveur utilise systemd et pulseaudio non ? ;) )

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

  • # vant de tirer tes conclusions

    Posté par  . Évalué à 4.

    Tu ne voudrais pas nous laisser regarder ton site ?
    Ptet qu'à partir de cela on pourra te donner quelques idées supplémentaires.

    • [^] # Re: vant de tirer tes conclusions

      Posté par  (site web personnel) . Évalué à 1.

      Voici une page avec juste la vignette, c'est la nouvelle version que je développe :
      http://cobra-system.genku.net/tests/5-risen-2-dark-waters

      Cela donne 9 secondes 500ko…

      • [^] # Re: vant de tirer tes conclusions

        Posté par  (Mastodon) . Évalué à 4.

        http://cobra-system.genku.net/tests/5-risen-2-dark-waters

        $ lynx -dump http://cobra-system.genku.net/tests/5-risen-2-dark-waters | less

        C'est normal toutes les requêtes SQL en fin de page ?-)

        • [^] # Re: vant de tirer tes conclusions

          Posté par  (site web personnel) . Évalué à 1.

          Oui c'est le plugin de CakePHP me permettant de tout débuguer (sql, request etc.)

          • [^] # Re: vant de tirer tes conclusions

            Posté par  . Évalué à 5.

            Les infos de débogage, tu devrais mettre un flag quelque part à activer pour les avoir, et par défaut ne pas les mettre.

            • [^] # Re: vant de tirer tes conclusions

              Posté par  . Évalué à 8. Dernière modification le 23 janvier 2015 à 17:09.

              Avec le mode debug intégré dans cakephp, chaque modèle est regénéré à chaque accès.
              Je ne connais pas ton plugin de debug, mais il est possible que ton problème vienne de là.
              Si je regarde le temps de chargement de ta page avec l'outil de dev intégré dans FF, je vois que sur les 3s que met ta page à s'afficher chez moi (avec javascript désactivé !!), le point de contention sont les 2.4s d'attente pour le début de transfert de ta page de 101ko, le transfert en lui même prend 19ms. Le problème est donc bien à priori sur la génération du contenu par le serveur, pas en raison de ta bande passante.
              Plein de conseils de bon sens ici : http://www.sitepoint.com/speeding-up-your-cakephp-websites/

              Ensuite, il y a environ 10ms d'attente à chaque accès à une ressource hébergée chez toi, donc plus tu restreins le nombre d'accès, plus tu vas gagner en temps d'affichage sur le client. Là avec noscript d'activé, donc aucun javascript exécuté, j'ai déjà 8 accès. En activant Javascript, j'en suis à 6,12s au total avec 2x2.4s d'attente évitable (pour l'envoi de la police ttf).

              Pour tes images, comme indiqué dans plusieurs commentaires, créé des vignettes qui lorsqu'on clique dessus charge alors l'image dans la taille désirée. A titre perso j'utilise convert pour dimensionner et convertir les images en jpeg et jpegtran pour optimiser leur taille.

              Enfin, si comme moi tu n'es pas dans une zone fibrée, tu peux te lancer dans le dédié ou le virtuel mutualisé : j'ai un petit dédié avec un double coeur multithreadé, 2Go de RAM, 500Go de disque et 100Mb de bp non garantie pour quelques euros par mois.

      • [^] # Re: vant de tirer tes conclusions

        Posté par  . Évalué à 3.

        Désactives le tableau de bord, ou que sais je, mine de rien et amha, cela n'aide pas du tout.
        Si tu peux l'activer via une variable c'est encore mieux.

        En ce qui me concerne très particulièrement, avec ma connection internet atypique, ce qui me dérange le plus ce sont tes ressources sur cdn.
        grosse grosse latence, renvoies des 304, donc refetch, donc vieux sentiment de lenteur répété durant la navigation..

        Je ne trouve pas les content type gzip sur les fonts, et je constate que je charge deux fois opensans.ttf

        AMHA, cette grosse baleine de bootstrap css ne t'aides pas tellement dans ta démarche actuelle.
        Si tu as la possibilité de faire un split entre le css minimum et le reste cela te permettra de bouger un tas de css en bas de page, cela doit aider a présenter le contenu utile plus rapidement.

        Tu devrais certainement prendre avantage de l'attribut async sur les scripts, par contre il faut concaténer tous les js.
        Je crains que cela ne soit pas compatible avec ton dashboard.

        Tu pourrais mettre tes images au format jpeg progressif.
        Selon moi, ce serait bien de mettre les formats d'images dans les tags directement, sa éviterait ce désagréable effet d'escalier.
        N'oublies pas les attributs alts, c'est pratique de savoir ce qu'on charge quand c'est lent.

        Si possible, appliques un cache plus fort sur la réponse du html, par contre, cela nécessite un code qui prends compte de cette contrainte.

        Dans le détail, on peut regarder les response headers.
        Server, on s'en fou un peu quand même.
        Allow control origin, est ce bien utile ?
        etag + date + expires + last modified, alors que tu tu as cache control max-age=31536000. Je m'en remets à l'avis des autres, mais je pense que c'est doublon.

        Le probablement too much, tu utilises un second nom de domaine cookie less pour tes assets statiques.

        En fait tu as déjà réalisé un bon travail de fond, je crois qu'il faudrait désormais optimiser l'intégration.

        Dernière piste dans l'immédiat, je demanderais à tes testeurs de fournir le noms de leurs ISP.
        Peut être que les peerings sont de mauvaises qualités.
        Les gens qui connaissent le réseau français pourront peut être t'éclairer sur cet aspect.

  • # Optimisations et miniatures

    Posté par  . Évalué à 2.

    Bon, les libs super lourdes ont déjà été mentionnées. Tu pourrais essayer de minifier plus de fichiers, jouer sur l'ordre de tes requêtes (en chargeant les scripts vers la fin par exemple), etc.

    Il y a plein de possibilités d'optimisations même si je pense que tu as le choix entre un site plus minimaliste sans libs lourdes et te prendre un hébergement (ou les deux).

    Pour les images dans l'article, peut-être pourrais-tu mettre de miniatures de faible résolution pointant sur les images en haute résolution. Comme  ça, même si les images sont lentes à charger, elles chargent si le lecteur veut les voir et en tout cas, après l'article.

    • [^] # Re: Optimisations et miniatures

      Posté par  . Évalué à 4.

      Pour les images tu peux aussi utiliser du jpeg progressif.
      J'héberge des photos sur un raspberrypi derrière une connexion ADSL comme toi (80 à 100ko/s), et je peux afficher une photo de 2Mo en qualité raisonnable en moins de 2 secondes (bien sûr, télécharger l'image entière prend une vingtaine de secondes).
      Du coup tu as très rapidement une page lisible, qui s'améliore en quelques secondes, c'est l'idéal. Et si le visiteur ne reste pas longtemps sur la page, il ne chargera même pas entièrement les images.

    • [^] # Re: Optimisations et miniatures

      Posté par  . Évalué à 3.

      mince j'ai dit la meme chose (plus bas) sans avoir vu ce post.

      Je suis d'accord avec l'analyse,
      le premier plugin à coder, c'est un plugin qui genere une miniature quand on upload une image.
      ca evite de devoir reduire toutes les images avant le double upload vignette/normale.

      • [^] # Re: Optimisations et miniatures

        Posté par  (site web personnel) . Évalué à 1.

        Bah j'ai mon propre plugin, un gestionnaire d'images en jquery puis un component qui va s'occuper de générer différentes vignettes. Par exemple lorsque j'upload une image (généralement du 1920x1080), j'obtiens le format large (900x900), medium (400x400) et small (250x250). Alors si je dois faire des vignettes de vignettes ça va être chaud …

        • [^] # Re: Optimisations et miniatures

          Posté par  . Évalué à 3.

          alors si tu as deja ces images, il faut que tu affiches les mediums ou small dans l'article.
          et seulement quand la personne clic dessus, tu lui donnes l'"originale".

  • # Dédié

    Posté par  . Évalué à 2.

    Franchement, on trouve de vrais dédiés pour le prix d'un paquet de clope par mois.
    Quasiment tous les avantages de l'auto-hébergement, une vraie bande passante, une consommation électrique mutualisée donc plus écologique…
    Tu es locataire de la machine, tu y mets les services que tu veux, y'à pas à hésiter.

    • [^] # Re: Dédié

      Posté par  . Évalué à 6.

      une consommation électrique mutualisée donc plus écologique…

      Autant je suis d'accord sur les autres points, autant sur celui-ci je ne suis pas sûr : l'hébergement en DataCenter optimise probablement mieux l'utilisation des machines, mais il y a des coûts absents de l'auto-hébergement, notamment la clim. Si on considère par exemple cet article :

      http://www.greenit.fr/article/acteurs/hebergeur/253-pue-moyen-des-data-centers-europeens-4898

      En moyenne en Europe, avec un PUE de 2,53, un datacenter consomme plus en clim qu'en machine…

      Donc l'écart entre auto-hébergement et datacenter, d'un point de vue énergie, n'est probablement pas si flagrant, tout dépend des techniques utilisées de part et d'autre.

      • [^] # Re: Dédié

        Posté par  (site web personnel) . Évalué à 6.

        Je finis par être d'accord avec Zenitram: aucune raison valable d'héberger à domicile son propre serveur, sinon celle de se faire plaisir. C'est pour cela que je continue.

      • [^] # Re: Dédié

        Posté par  . Évalué à 3.

        Chez OVH, ils ont des VPS a 2€/mois qui sont tres adaptés pour les petits sites et comme les DC d'OVH sont ultra optimisés coté conso energetique, ils ont des PUE de l'ordre de 1,10 environ ( https://www.ovh.com/fr/apropos/green-it.xml )
        Y'en a pas beaucoup qui font mieux aujourd'hui…

        • [^] # Re: Dédié

          Posté par  (site web personnel) . Évalué à 2.

          Je viens de faire un petit devis et j'avoue que ça ferait seulement 30 euros l'année. C'est vraiment pas cher et on peut même louer sur une certaine période… Va falloir que j'étudie sérieusement la question d'autant plus que je serais amener à déployer une grosse application…

          • [^] # Re: Dédié

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 23 janvier 2015 à 20:12.

            Si tu veux aller encore plus loin, il y a des fournisseurs vraiment pas cher, comme celui-ci qui descend à 3 euros par an.

            Après si c'est que du statique, tu peux carrément t'orienter vers du stockage du type S3/runabove/Google cloud storage, tu auras l'avantage d'un débit plus que suffisant avec l'inconvénient d'un coût difficilement contrôlable.

            Les hébergements à bas prix c'est la spécialité de Low End Box, tu peux jeter un coup d’œil.

        • [^] # Re: Dédié

          Posté par  . Évalué à 3.

          J'ai décidé de m'auto héberger aussi depuis environ un an.

          Au final je me suis fixé sur :
          - VPS d'OVH à 2€/mois pour 10Go. C'est pas beaucoup mais amplement suffisant pour une base
          - certificat ssl Comodo acheté via namecheap (6€/an)
          - Debian 7 avec Yunohost.

          C'est que du bonheur, ça se configure presque tout seul et la maintenance est hyper simple.

          J'attends de voir dans la durée, mais pour l'instant je suis hyper convaincu !

          • [^] # Re: Dédié

            Posté par  (site web personnel) . Évalué à 1.

            J'avoue y a une différence de dingue ! Je viens de me prendre un VPS chez OVH et franchement y a pas photo. En faisant un test sur pingdom, j'obtiens à peine 1,38 secondes pour une page de 764 ko, le tout avec nginx et la compression gzip activé :)

            • [^] # Re: Dédié

              Posté par  . Évalué à 5.

              ben en meme temps tu es passé d'une laison à 640Kbps à une liaison à 100Mbps

    • [^] # Re: Dédié

      Posté par  (site web personnel) . Évalué à 3.

      Et si un jour ton site a du succès tu es sûr que derrière ta connexion ADSL ça ne tiendra pas. Autant l'auto hébergement me semble pertinent pour certains services qui n'ont pas de risque de nécessiter trop de bande passante et de disponibilité (mail, site web à accès limité, etc) les services qui ont potentiellement de forts besoins en bande-passante n'y sont pas forcément adaptés je trouve.

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Linuxfr /o\

      Posté par  . Évalué à 10. Dernière modification le 24 janvier 2015 à 01:12.

      C'est pas bientôt fini ces caricatures du prophète ?

      Tu veux que linuxfr se prenne une mise en bière ou quoi ? :o

      *splash!*

  • # Appel a un ami

    Posté par  . Évalué à 2.

    Ton site peut être divisé en deux partie, une partie avec le contenu (les articles, le texte etc..) tournant sous cakePHP (ou la techno que tu veux)et qui demande de la puissance de calcul et une seconde partie qui est très légère en terme de puissance de calcul, qui ne change jamais et qui pourrait être facilement mise ne cache ou hébergé par un CDN.

    Mon idée est de continuer à auto-héberger la logique et les pages et d'héberger les images chez un ami (qui donc te servirait de CDN). Cet ami peut être soit auto-hébergé avec de la fibre (ou n'importe quoi avec un gros débit en up et un bon ping) ou un serveur en salle serveur (a la limite du même du mutualisé si tu en trouve un avec peu de puissance mais suffisamment de bande passante).

    un serveur sans puissance de calcul mais un peu de bande passante ça coûte 5-6€/mois ht (chez kimsufi ou online) et pourrait faire CDN pour plusieurs sites comme le tien (avec un serveur nginx avec des paramètres pour économiser la bande passante)

    Bref si tu es prêt a quitter au moins partiellement l'auto-hébergement on peut trouver des solutions

  • # Mauvais FAI ?

    Posté par  . Évalué à 1. Dernière modification le 24 janvier 2015 à 08:38.

    Je le savais déjà, mon débit en upload est très faible (70 à 80 ko) mais je me suis persuadé qu'en activant la compression gzip et l'expiration des ressources, la vitesse de chargement devrait être correcte.

    En fonction de l'endroit géographique ou tu te situes, tu as peut être possibilité de changer de FAI, pour te permettre d'avoir un débit ascendant "utilisable".

    Tu as peut être déjà regardé ce genre de possibilités, mais comme ton journal ne l'indique pas, je me permet de te proposer quelques pistes :

    • Regarder si un opérateur propose un accès fibré au grand internet.
    • Jeter un œil sur des FAI moins "courants", je pense par exemple à OVH qui propose de plus en plus de VDSL, ou du SDSL 5Mbps pour le prix d'une connexion adsl classique.

    Si aucune de ces solutions n'est possible, tu as la possibilité de louer un p'tit dédié/vps. Si tu tiens au fait de pouvoir accéder physiquement à tes machines, t'as peut être un ami avec une connexion qui déboîte et que ça ne dérangerait pas d'héberger chez lui une machine ?

  • # utilisation de vignette dans l'article avec un lien vers l'image reelle pour affichage plein ecran

    Posté par  . Évalué à 6.

    ca me rappelle quand je donnais des cours de traitement de texte, ou les gens ne comprenaient pas comment avec les memes images je faisais une document qui pesait 3x moins que la leur en appliquant les memes effets.

    juste que je reduisais la taille de l'image source quand elle n'avait pas à etre affichée en plein ecran (vignette, illustation)
    meme si la page est presentée en plein ecran sur un ecran full HD, si l'image ne represente que ¼ de la page complete, elle n'a pas besoin d'etre en fullHD.

    je m'en suis résigné à compresser au maximum les images et même de les redimensionner en 1280x720,

    donc en gros, tu poses sur ton site des captures pratiquement plein ecran pour les afficher en vignette dans ton article ?

    mon ecran fait 1440x900, ton image remplit donc theoriquement tout mon ecran,
    mais j'imagine que dans ton article tu l'affiche en vignette, il n'empeche que tu telecharges l'image complete.

    perso je ferais deux images, une vignette en petite taille pour afficher dans l'article (de la meme taille que la zone image dans l'article)
    et une image taille reelle que la personne pourra afficher quand elle cliquera sur la vignette.

    regarde, sans changer la compression, tu verras qu'en passant de 1280x720 à 640x360 (reduction de surface par 4) tu vas deja enormement reduire le poids de l'image.

  • # gzip_static

    Posté par  (site web personnel) . Évalué à 2.

    Un module pas forcément connu : le module gzip_static de nginx. Si tu combines nginx + pages (HTML, CSS, JS) DÉJÀ compressées, tu peux gagner énormément de temps.

    Reste la taille des images, mais en affichage progressif c'est déjà pas mal. Étant donné que ton débit montant est faible, il faut aussi penser le site en fonction de cette limite (limiter au maximum les petites images, faire du HTML propre et léger), recours aux miniatures, quitte à être un peu moins joli.

    Pour un blog, ça ne sert à rien d'utiliser du PHP pour générer le rendu, ce qui n'empêche pas de faire des requêtes AJAX sur une partie PHP du blog. C'est la technique que j'utilise pour mon générateur : génération HTML pré compressée, mais la recherche est dynamique. On voit bien que cette dernière a du mal (Python + Django sur un SheevaPlug…), alors que l'affichage reste assez fluide.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.