Bonjour à tous,

je cherche un code me permettant d'afficher deux images d'arrière plan différentes selon le moment de la journée (le jour et la nuit, donc selon l'heure). Dans l'attente... je vous remercie.

Pour ça, il vaudrait mieux que tu aies un site en PHP (par exemple).
Dans ce cas, à chaque affichage, tu testes l'heure. En fonction de l'heure, tu attribues une classe différente au conteneur qui doit afficher l'image de fond; il ne te reste plus qu'à bidouiller en CSS pour que chaque classe soit associée à son fond.

Ah? Il n'y a vraiment aucun moyen de contourner le PHP via un script javascript par exemple?

C'est possible aussi, mais un peu plus galère.
Je regarde ce que je peux faire.
Tu n'as rien contre l'utilisation de jQuery ?
Tu pourrais me copier/coller le bout de HTML qui affiche ton background ?

Il est possible de faire cela sous Apache si tu utilises ce serveur web et que tu as accès à mod_rewrite.



Dans ton code tu ne fais référence qu'à image.jpeg ... qui selon l'heure sera réécrite par apache en image.jour.jpeg ou image.nuit.jpeg selon que l'heure soit entre 8H00 et 20H ou non. Dans l'exemple, de 08:00:00 à 19:59:59

Dans ce cas tu n'as même pas besoin de Php

La claaaaasse Dan !
J'aurais même pas imaginé que c'était possible

Et oui, beaucoup ne connaissent pas toutes les possibilités de mod_rewrite. Moi c'est "ma tasse de thé"

Cela permet très souvent de simplifier le code source.

D'une simplicité (presqu') enfantine !

Je me la garde sous le coude, celle-là...

xpatval

Par contre je serais curieux de voir l'impact sur le cache du navigateur : l'image est re-téléchargée par tout le monde toutes les heures non ? Entre l'ETag et la date de modification, je ne sais pas si tous les navigateurs vont gérer correctement ce genre de contenu récurent.

Afin d'utiliser au mieux le cache du navigateur, j'opterais pour la solution JS pour ma part. A moins que les pages PHP n'aient aucun cache et dans ce cas le changement de classe via PHP semble le plus simple.

ouahh, châpeau
c'est très malin
que proposer de mieux derrière...

L'image n'est téléchargée que deux fois par jour (jour/nuit), c'est à dire que lorsqu'elle diffère de la précédente et non pas toutes les heures.
Si le serveur Apache est correctement paramétré, il devrait renvoyer une entête 304 la plupart du temps.

En tout cas sur le serveur du Hub cela fonctionne correctement sous Firefox et IE7

Dan

Super interessant comme idée. T'as des lien ou des books pour en lire plus sur le sujet ?

A part l'article des publications ( Mod_rewrite, ou la réécriture des URL "à la volée" ) et la doc sur le site apache.org, je ne vois pas.

Justement, pour le coup on ne peut pas utiliser mod_expires donc on augmente de manière démesurée le nombre de hits, et on prend le risque que le navigateur ne gère pas le "double ETag". A ma connaissance firefox le gère bien, mais si ce n'est pas le cas sous IE cela veut dire que 2 fois par jour 60% des visiteurs re-téléchargent l'image en question.
Pour ma part je trouve ça complètement contre productif.

C'est sûre ! Mieux vaut utiliser les ressources pc avec du js que de d'exploiter les ressources serveur... ... Allons allons... faut rester un minimum logique ! Si tu as une smart et un Q7, tu prends pas la smart pour partir en vacances...

Perso, je trouve cette technique très interéssante !
Je me demande même : sachant que l'on traite au niveau inferieur, et que php est parsé, les ressources sont peut-être mieux optimisées qu'avec un if en php...
Cela dit, en hébergement mutualisé... pas sûre...

Dans tous les cas, c'est à retenir ! Bravo Dan !

Alipp : et à ton avis, qu'est ce qui consomme le plus de ressources pour le navigateurs : ré-interroger à chaque page le serveur et retélécharger puis décompresser l'image toutes les 12 heures, ou bien simplement exécuter une ligne de JS ce qui déclenchera... absolument rien de plus ?

Faire sauter une partie de la chaîne de mise en cache à la fois coté serveur et coté client, juste pour une bidouille graphique, tu penses vraiment que ça consomme moins de ressources que le script JS qui maintient cette chaîne intacte ?
Je suis loin d'être un défenseur du JS, mais je maintiens qu'il s'agit très probablement de la meilleure solution ici ; encore plus si le site fait déjà appel à un script JS.

Quand à la solution du mod_rewrite en elle même, elle est effectivement très intéressante, mais pour moi elle n'est pas adaptée à ce cas ci.

Bien ! Ne nous emballons pas et tentons d'éviter le concour c'est moi le meilleur...

Pour ce qui est de la "réinterrogation à chaque page" : A la base, ce n'est pas le fait de faire RewriteCond et RewriteRule qui conditionne le fait que le navigateur effectue une interrogation.

exécuter une ligne de JS ce qui déclenchera... absolument rien de plus ? : phrase quelque peu contradictoire... car il y a bien exécution côté client comme tu l'as dis... donc utilisation de ressource.

tu penses vraiment que ça consomme moins de ressources que le script JS qui maintient cette chaîne intacte ? : Le fait est (et c'est ce que j'ai voulu dire dans mon précédent poste) que la plupart des internautes sont équipés de config en général issus de la grande distribution, donc aux paramètrages système et logiciels pour le moins pourris, et aux performances très rapidement proches de la nullité. Jusqu'à preuve du contraire, le fait de rajouter l'exécution d'un js n'allège pas la chose.
Et de l'autre côté, il est question de serveurs, dédiés et prévus pour de l'hébérgement web, aux capacités prévues à cet effet, pour lesquelles ce genre de calcul n'utilise quasiment rien en ressource.
Ce n'est donc pas à toi, professionnel du web et de l'hébérgement haute disponibilité ( Pub !), qu'il faut démontrer l'intérêt de favoriser l'exécution de processus et l'utilisation mémoire côté serveur.

le navigateur ne gère pas le "double ETag" : 1 requête -> 1 Etag http -> 2 hash MD5 (1 pour le cache client, 1 pour le fichier sur le serveur) -> 1 réponse serveur : je renvois ou pas.

Pour ma part je trouve ça complètement contre productif : D'un point de vue hébérgeur, développeur, ou visiteur ? Je crois avoir la réponse...

ERRATUM :

Je viens de comprendre ta position... en allant voir daevel.net... qui redirige sur www.daevel.fr... qui boucle sur une autre redirection... qui... enfin bref...

Un soucis avec les RewriteCond ? Un coup de main ? *

(*)N'étant plus dans le cadre xhtml et css... je propose la suite dans une rubrique plus appropriée...

Soit, je vais tenter d'expliquer en détail dans ce cas.

Cas n°1 : on a la page "index.php", qui gère correctement le cache navigateur (via ETag uniquement, cas le plus simple). Elle utilise une feuille de style "versionnée à la volée" (cas le plus simple encore), et donc chargée par exemple via "toto.121212.css" (121212 étant le timestamp de la feuille de style). Cette feuille de style étant "versionnée", je peux évidement y coller un "expires" assez long, du genre 6 mois.
J'ajoute à cela mon énorme JS (en supposant que le site n'en ai pas déjà un). Comme la feuille de style : j'inclus le timestamp dans le nom, et j'y colle un long temps d'expiration.
Le système reposant sur le JS, j'ai donc deux versions de l'images : test1.png et test2.png ; chacune ayant un expires de 48 heures.

Au premier accès j'ai donc 4 hits HTTP, avec des transferts complets. Lors du deuxième accès à la page 2 heures après, je n'aurais qu'un 1 seul hit HTTP (index.php) qui retournera simplement un 304. 10 heures après, je ré-accède à ma page, j'ai toujours le hit pour la page "index.php" mais cette fois mon script JS "déclenche" le téléchargement de test2.png. Lors du quatrième accès, 1 seul hit (index.php) sera à nouveau effectué.
Désormais le navigateur ne demandera confirmation que pour la page "index.php", et ne demandera les versions des images que toutes les 48 heures. La CSS tout comme le script JS ne seront retéléchargés qu'en cas de modification.

===

Cas n°2 : meme page "index.php", CSS sur le même principe et pas de script JS. Par contre cette fois nos deux images ont une URL commune, donc impossible d'utiliser "Expires".
Au premier accès j'ai donc 3 hits HTTP, avec des transferts complets. Lors du deuxième accès à la page 2 heures après, j'aurais 2 hits HTTP (index.php + image) qui retourneront tout deux un 304. 10 heures après je ré-accède à ma page, cette fois l'image change : on a le hit pour index.php, ainsi que le téléchargement de l'image.
Au quatrième hit ça se complique : le navigateur va faire deux requetes, pour index.php il aura toujours son 304 ; mais pour l'image difficile à prévoir : si le navigateur a remplacé l'ETag par la nouvelle version, alors toutes les 12 heures il retélécharge l'image. Mais s'il conserve plusieurs versions (cas de Firefox à priori), effectivement il y aura à nouveau un 304.

===

Dans le premier cas on a donc une diminution du nombre de requêtes faites par le navigateur, avec le surcout de l'exécution du JS (qui peut également être en cache sous Firefox d'ailleurs). Et pour un serveur dédié "classique" avec du Apache prefork + PHP en front, un gain d'autant plus interessant.
Sans oublier que si le site utilisait déjà un script JS pour son interface, le surcout ci dessus devient quasi nul.

Dans le deuxième cas on a le double de hits HTTP, en permanence sur toutes les pages utilisant cette image de fond. Un "hit HTTP", et ce hit HTTP consomme évidement des ressources coté client comme serveur. Pour peu que le navigateur ne gère pas les ETag multiples pour une même URL, on a même un retéléchargement régulier de la dite image.

===

Pour répondre à :
Je ne pense pas avoir dit le contraire ; mais comme expliqué ci dessus s'en servir pour servir du contenu "dynamique" via les méthodes "statiques" d'Apache cela empèche l'utilisation d'un délai d'expiration adéquate, et peu fosser la gestion du cache selon les navigateurs.

Quand au fait que les serveurs dédiés sont plus puissant que les machines du grand commerce, j'aurais tendance à être d'accord même si ce n'est pas forcément le cas des Dedibox et autres machines d'entrée de gamme. Et c'est bien pour ça que j'évite le plus possible au client de refaire des hits qu'on pourrait facilement éviter.

Je ne pense pas pouvoir faire plus clair ici. Mais si tu vois une erreur dans mon raisonnement, n'hésites pas. Etant tous deux sur Lyon, on peut même voir ça autour d'un verre si tu veux.


PS : merci d'éviter les mini attaques personnelles, à priori tu n'en sais pas plus sur moi que j'en sais sur toi.

Et si je vous disais que sur le Hub environ 30% des visiteurs n'ont pas JavaScript activé, cela mettrait les pendules à l'heure pour tout le monde

Absolument pas Dan : il s'agit d'une bidouille graphique, cela me semble non essentiel. Donc que cela ne fonctionne pas chez certains, ça ne me dérange absolument pas. Mais que cela implique 1 hit supplémentaire chez tous les visiteurs, juste pour ce "petit plus", ça me gène beaucoup plus.

Alors moi je vais remettre les pendules à l'heure !

Si la majorité de tes posts ne sert qu'à critiquer les solutions qui ne sortent pas de TON chapeau, tu ferais mieux de t'abstenir.
Et ce que tu qualifies de "bidouille graphique non essentielle" est peut-être considéré comme indispensable par l'auteur de ce post.

Lancer une polémique sur ce sujet, alors que tu n'es pas certain de ce que tu avances est totalement stérile.

Sur le Hub, ce type de réécriture ne génère que quelques hits supplémentaires pour les clients qui utilisent IE6 ou IE5. Et je trouve personnellement beaucoup plus élégante une solution orientée serveur que toute solution basée sur l'assomption que le poste client a (ou n'a pas) JavaScript activé.

Si tu en es à comptabiliser les hits à ce point sur ton serveur, tu ferais mieux d'en prendre un plus gros.

Pour moi, la discussion est close !

Dan

Oulah, grand dieu non. J'accepte volontiers tous les arguments pertinents ; et je ne pense pas m'être "venté" d'être l'auteur de la moindre solution évoquée ci dessus.

Cette fonctionnalité est peut être essentiel pour l'auteur de ce post, tu as raison. Mais sans plus d'info, je reste sur la "dégradation propre" comme pour les CSS. Mais ce sera effectivement au client de choisir.




Aucune polémique : explication de procédés. Et je suis certain de moi oui.




Là je demande à voir alors : comment, sans le moindre entête "expires" envoyé le navigateur procède t-il ? A moins de fixer arbitrairement une valeur fixe de quelques heures, ce qui pour le coup décale dans le temps le changement d'image.
Pour ce qui est du "plus propre", je suppose qu'il s'agit d'un problème de point de vue. Je ne suis pas fan du JS, mais faire reposer une technique d'affichage sur une technologie du serveur web ne me semble pas plus propre non plus.



La consommation des ressources fait parti de mon boulot, et le nombre de hits HTTP joue un assez grand role dans les sensations de vitesse des internautes.

S'il s'agit d'une fonction primordiale, bien, on fait avec, on prévoit éventuellement une machine plus puissante (bien que la machine plus puissante n'apportera pas grand chose coté client).

D'ailleurs, ce n'est certes pas la même échelle, mais ça va plutôt dans le sens des recommandations de Yahoo.

Mais si tu y tiens, j'en reste là.

Je ne veux pas non plus polémiquer sur ce sujet.

Pour info toutefois, c'est la technique recommandée par Apache dans son URL Rewriting Guide (voir le paragraphe "Time-Dependent Rewriting")
Et j'aurais plus tendance à faire confiance à Apache qu'à ta solution basée sur JS, désolé !

Eux ajoutent les minutes... et traitent des fichiers HTML, c'est la seule différence.
Mais fais comme bon te semble, je n'ai pas envie de jouer au plus fin.

Dan

PS: la lecture attentive de ce guide permettrait d'éviter ce type de page
Cliquez pour voir le fichier joint

Bonjour,

Je pars du principe qu'un serveur web doit prendre en charge un maximum de choses pour décharger au maximum le poste client.
C'est le but d'un serveur dédié... On lui dédié tout ce qui est en rapport avec l'hébergement (stockage des pages web, redirections des pages, réécriture d'url, interprétation du php ou Asp, gestion des domaines etc etc) d'ou le nom "serveur dédié".
Après on choisi son serveur dédié en fonction des ressources nécessaires et en prévoyant une marge de sécurité.

Partant de ce principe et dans le cas précis d'une utilisation apache ou JS je préfère et de loin la solution Apache qui m'assurera en tant que webmaster un contrôle total de ce que j'affiche (que l'affichage a bien lieu sans plantage, un temps d'exécution raisonnable, ...).

Il faut garder à l'esprit que les internautes ont souvent des machines bureautiques qui ne sont pas des "foudres de guerre" et qu'ils ne la changeront pas d'aussitôt car ça leur suffit amplement pour afficher la plupart des sites web. Ils ne vont pas changer de machine, même si les prix d'une machine de nos jours est plus qu'abordable, juste pour une minorité de sites qui monopolisent trop de ressources sur la machine "cliente".

Il y a certains sites qui arrivent à mettre mon dual core 2Go Ram à genoux à cause d'une utilisation abusive de scripts exécutés coté client. Il faut le faire quand même...!! bien sûr c'est une minorité !

Il faut que le webmaster fasse en sorte que son site s'affiche rapidement et correctement quelque soit la configuration de la machine des internautes. Bien sur il y a des limites on peut pas faire un site pour qu'il fonctionne aussi sur un celeron 333 mhz avec 64 Mo ram et IE4. Mais il faut que cela fonctionne sur des machines qui ont 3 ou 4 ans voir plus si possible.

Je suis pour l'optimisation des serveurs lorsque cela est possible et nécessaire; je ne suis pas contre le JS non plus ca peut etre utile voir indispensable dans certains cas mais ce n'est pas une requête apache de ce type qui va mettre un genoux un serveur même si elle multipliée par xxxxx visiteurs / jour. Lorsqu'on voit le prix des machines dédiées et la puissance qu'elles offrent on ne va pas pleurer pour un hit supplémentaire ;-)

Pour finir je pense que ce n'est pas vraiment une solution de vouloir diminuer légèrement l'utilisation des ressources de son serveur en les déplaçant sur les machines des internautes sachant que ca peut dans certains cas leur poser des problèmes.

Dan, je n'ai pas accès à la pièce jointe

C'est bon là ?
Faut vraiment que je regarde de plus près les permissions pour les pièces jointes dans TOUS les forums

Ouaip c'est bon la

Yep Nicolas pour moi faire attention à l'internaute tiens aussi compte de sa connexion : un PDA avec un CPU très limité et une connexion Edge par exemple, je préfère qu'il ait une image fixe (s'il n'a pas de JS actif) et qu'il fasse moins d'accès réseau.

Tout est question de compromis : généralement on compresse les pages web pour en accélérer le transfert. Mais cela consomme évidement plus de ressources CPU coté serveur et client.

Pour ce qui est du client, j'ai tendance à pencher sur l'économie des accès et transferts réseaux, qui me semblent de loin les plus pénalisants. Question de point de point vue on va dire ; le "débat" est clos.

Pour ce qui est de mon domaine "daevel", bien que je ne vois pas le rapport, oui il est en carafe, comme probablement la plupart des domaines "non utilisés" que je possède. C'est si grave que ça ? En tous cas si ça peut vous rassurer, il n'y a pas la moindre règle de rewriting sur ces domaines.

Grave ? Non, pas du tout. Si tu savais à quel point je m'en fiche tu ne poserais même pas la question.

Le domaine www.daevel.fr redirige sur lui-même à l'infini (ou jusqu'au moment où Apache renonce) ... C'est donc soit une redirection, soit une réécriture qui n'est pas faite correctement. Donc pour quelqu'un qui vend de l'hébergement et/ou de l'infogérance (j'ai compris cela récemment) ce n'est pas terrible comme carte de visite.

Voici ce que donne le domaine, pour prouver ce que je t'annonce :


Bon, j'arrête là.

Oui oui, j'ai bien vu que ça "bouclait à l'infini". Pour ma carte de visite, bah de toutes façons il n'y a jamais eu de site à cette adresse.
Je ne fonctionne que sur le bouche à oreille, avec des clients assez "spécifiques" qui sont heureusement contents du service. Tout comme les clients du Hub à priori.