Recherchant un hébergeur pour un site composé essentiellement d'un forum
(actuellement 650 inscrits), je fais un peu le tour des offres et voici
ce que j'ai lu à propos des hits:
<quote>
Une requête web est un accès a un élément de votre site ("hit" en
anglais). Cette limite est très haute, et vous permet d'exploiter
sereinement votre site. Par exemple un site de 1500 visiteurs par jour,
programmé "normalement", ne consomme pas plus de 15000 requêtes web par
jour.
</quote>
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne
savent-ils pas que depuis quelques années un site se doit d'être un
minimum interactif?
Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en
imaginant un site en php, toutes les pages baties sur la même structure):
- Page PHP
- config.inc (pour connexion à la base + quelques fonctions)
- Header.inc (on va tacher de garder toujours le même haut de page)
- Footer.inc (idem pour les mentions inutiles ou obligatoires)
- style.css
- scripts.js
- banniere.jpg (un site à souvent une bannière)
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits.
Les visiteurs ne voyent donc même pas 2 pages en moyenne.
J'avoue avoir pris une situation extrème, il est possible d'inclure la
feuille de style et les javascripts dans le header, mais on passe à 5
hits, donc 2 pages par visiteur et par jour.
Conclusion: les hébergeurs suivent la méthode lycos/multimania et ne
veulent que des mini-sites inintéressants.
Si ça vous intéresse, l'auteur de la définition des hits est
http://www.easy-hebergement.com
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures
epiques avec un autre hébergeur... aventures qui méritent le détour :)
--
Tout sur les eggdrops
http://www.c-p-f.org
ML @ eggdrop_fr@yahoogroupes.fr
Recherchant un hébergeur pour un site composé essentiellement d'un forum (actuellement 650 inscrits), je fais un peu le tour des offres et voici ce que j'ai lu à propos des hits:
<quote> Une requête web est un accès a un élément de votre site ("hit" en anglais). Cette limite est très haute, et vous permet d'exploiter sereinement votre site. Par exemple un site de 1500 visiteurs par jour, programmé "normalement", ne consomme pas plus de 15000 requêtes web par jour. </quote>
Il est, en effet, difficile d'estimer le nombre de hits que produit un site "en moyenne" puisque tout dépend de ce qui est proposé au client (images, feuilles de style, etc.). Les estimations sont donc un peu faites à la légère.
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne savent-ils pas que depuis quelques années un site se doit d'être un minimum interactif? Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en imaginant un site en php, toutes les pages baties sur la même structure): - Page PHP - config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires)
.inc ? Dans le cas où le Add-Type serait mal renseigné, ce serait une énorme faille de sécurité. L'extension .inc.php ferait tout autant l'affaire.
- style.css - scripts.js - banniere.jpg (un site à souvent une bannière)
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits. Les visiteurs ne voyent donc même pas 2 pages en moyenne.
Donc non. Ici, il y a 4 hits. Ta page PHP qui a 3 includes, une feuille de style, un fichier contenant du Javascript ainsi qu'une image. Les inclusions faites en PHP par include(); ou require(); sont invisibles pour le visiteur car effectuées du côté du serveur.
J'avoue avoir pris une situation extrème, il est possible d'inclure la feuille de style et les javascripts dans le header, mais on passe à 5 hits, donc 2 pages par visiteur et par jour.
Non, plus que 2, donc 5 pages par visiteur par jour.
Conclusion: les hébergeurs suivent la méthode lycos/multimania et ne veulent que des mini-sites inintéressants.
Tout dépend des offres...
Si ça vous intéresse, l'auteur de la définition des hits est http://www.easy-hebergement.com
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :)
Bonne recherche.
-- Alexandre Havard In God we Trust -- all others must submit an X.509 certificate.
CrazyCat wrote:
Recherchant un hébergeur pour un site composé essentiellement d'un forum
(actuellement 650 inscrits), je fais un peu le tour des offres et voici
ce que j'ai lu à propos des hits:
<quote>
Une requête web est un accès a un élément de votre site ("hit" en
anglais). Cette limite est très haute, et vous permet d'exploiter
sereinement votre site. Par exemple un site de 1500 visiteurs par jour,
programmé "normalement", ne consomme pas plus de 15000 requêtes web par
jour.
</quote>
Il est, en effet, difficile d'estimer le nombre de hits que produit un
site "en moyenne" puisque tout dépend de ce qui est proposé au client
(images, feuilles de style, etc.). Les estimations sont donc un peu
faites à la légère.
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne
savent-ils pas que depuis quelques années un site se doit d'être un
minimum interactif?
Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en
imaginant un site en php, toutes les pages baties sur la même structure):
- Page PHP
- config.inc (pour connexion à la base + quelques fonctions)
- Header.inc (on va tacher de garder toujours le même haut de page)
- Footer.inc (idem pour les mentions inutiles ou obligatoires)
.inc ? Dans le cas où le Add-Type serait mal renseigné, ce serait une
énorme faille de sécurité. L'extension .inc.php ferait tout autant
l'affaire.
- style.css
- scripts.js
- banniere.jpg (un site à souvent une bannière)
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits.
Les visiteurs ne voyent donc même pas 2 pages en moyenne.
Donc non. Ici, il y a 4 hits. Ta page PHP qui a 3 includes, une feuille
de style, un fichier contenant du Javascript ainsi qu'une image. Les
inclusions faites en PHP par include(); ou require(); sont invisibles
pour le visiteur car effectuées du côté du serveur.
J'avoue avoir pris une situation extrème, il est possible d'inclure la
feuille de style et les javascripts dans le header, mais on passe à 5
hits, donc 2 pages par visiteur et par jour.
Non, plus que 2, donc 5 pages par visiteur par jour.
Conclusion: les hébergeurs suivent la méthode lycos/multimania et ne
veulent que des mini-sites inintéressants.
Tout dépend des offres...
Si ça vous intéresse, l'auteur de la définition des hits est
http://www.easy-hebergement.com
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures
epiques avec un autre hébergeur... aventures qui méritent le détour :)
Bonne recherche.
--
Alexandre Havard
In God we Trust -- all others must submit an X.509 certificate.
Recherchant un hébergeur pour un site composé essentiellement d'un forum (actuellement 650 inscrits), je fais un peu le tour des offres et voici ce que j'ai lu à propos des hits:
<quote> Une requête web est un accès a un élément de votre site ("hit" en anglais). Cette limite est très haute, et vous permet d'exploiter sereinement votre site. Par exemple un site de 1500 visiteurs par jour, programmé "normalement", ne consomme pas plus de 15000 requêtes web par jour. </quote>
Il est, en effet, difficile d'estimer le nombre de hits que produit un site "en moyenne" puisque tout dépend de ce qui est proposé au client (images, feuilles de style, etc.). Les estimations sont donc un peu faites à la légère.
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne savent-ils pas que depuis quelques années un site se doit d'être un minimum interactif? Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en imaginant un site en php, toutes les pages baties sur la même structure): - Page PHP - config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires)
.inc ? Dans le cas où le Add-Type serait mal renseigné, ce serait une énorme faille de sécurité. L'extension .inc.php ferait tout autant l'affaire.
- style.css - scripts.js - banniere.jpg (un site à souvent une bannière)
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits. Les visiteurs ne voyent donc même pas 2 pages en moyenne.
Donc non. Ici, il y a 4 hits. Ta page PHP qui a 3 includes, une feuille de style, un fichier contenant du Javascript ainsi qu'une image. Les inclusions faites en PHP par include(); ou require(); sont invisibles pour le visiteur car effectuées du côté du serveur.
J'avoue avoir pris une situation extrème, il est possible d'inclure la feuille de style et les javascripts dans le header, mais on passe à 5 hits, donc 2 pages par visiteur et par jour.
Non, plus que 2, donc 5 pages par visiteur par jour.
Conclusion: les hébergeurs suivent la méthode lycos/multimania et ne veulent que des mini-sites inintéressants.
Tout dépend des offres...
Si ça vous intéresse, l'auteur de la définition des hits est http://www.easy-hebergement.com
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :)
Bonne recherche.
-- Alexandre Havard In God we Trust -- all others must submit an X.509 certificate.
Olivier Miakinen
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne savent-ils pas que depuis quelques années un site se doit d'être un minimum interactif? Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en imaginant un site en php, toutes les pages baties sur la même structure): - Page PHP
Ok.
- config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires)
Non, ces fichiers sont appelés directement par ta page PHP, sans faire de nouvelle requête HTTP.
- style.css - scripts.js
Ok pour la première page vue par le visiteur. Pour les autres pages, ces fichiers sont en principe dans son cache (d'où l'intérêt d'en faire des fichiers externes, mais communs à toutes les pages du site).
- banniere.jpg (un site à souvent une bannière)
Oui pour toutes les images, bannière ou autres. Mais là encore ils seront souvent mis en cache.
Mais bon, même en supposant que rien n'est dans le cache, quand tu as compté l'accès à la page elle-même, et aussi aux deux fichiers CSS et JS, il te reste encore à rajouter 7 images pour arriver aux 10 hits par page.
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits. Les visiteurs ne voyent donc même pas 2 pages en moyenne.
Dans l'exemple que tu as donné, les visiteurs qui ne voient qu'une seule page avant de partir (écurés ? :-)) n'ont fait que 4 hits. En supposant des fichiers CSS et JS communs mais une nouvelle image à chaque page web, il leur faut voir 4 pages différentes pour faire 10 hits.
Enfin, si sur 100 visiteurs il y en a 50 qui ne voient qu'une page (50x4 0) et 49 qui en voient 4 (49x10I0), cela laisse 310 hits pour le 100e visiteur, qui peut ainsi visiter 154 pages.
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :)
Je sens que je n'ai pas été sage, et que je serai privé d'histoire. Ouin ! ;-)
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne
savent-ils pas que depuis quelques années un site se doit d'être un
minimum interactif?
Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en
imaginant un site en php, toutes les pages baties sur la même structure):
- Page PHP
Ok.
- config.inc (pour connexion à la base + quelques fonctions)
- Header.inc (on va tacher de garder toujours le même haut de page)
- Footer.inc (idem pour les mentions inutiles ou obligatoires)
Non, ces fichiers sont appelés directement par ta page PHP, sans faire
de nouvelle requête HTTP.
- style.css
- scripts.js
Ok pour la première page vue par le visiteur. Pour les autres pages, ces
fichiers sont en principe dans son cache (d'où l'intérêt d'en faire des
fichiers externes, mais communs à toutes les pages du site).
- banniere.jpg (un site à souvent une bannière)
Oui pour toutes les images, bannière ou autres. Mais là encore ils
seront souvent mis en cache.
Mais bon, même en supposant que rien n'est dans le cache, quand tu as
compté l'accès à la page elle-même, et aussi aux deux fichiers CSS et
JS, il te reste encore à rajouter 7 images pour arriver aux 10 hits par
page.
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits.
Les visiteurs ne voyent donc même pas 2 pages en moyenne.
Dans l'exemple que tu as donné, les visiteurs qui ne voient qu'une seule
page avant de partir (écurés ? :-)) n'ont fait que 4 hits. En supposant
des fichiers CSS et JS communs mais une nouvelle image à chaque page
web, il leur faut voir 4 pages différentes pour faire 10 hits.
Enfin, si sur 100 visiteurs il y en a 50 qui ne voient qu'une page
(50x4 0) et 49 qui en voient 4 (49x10I0), cela laisse 310 hits pour
le 100e visiteur, qui peut ainsi visiter 154 pages.
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures
epiques avec un autre hébergeur... aventures qui méritent le détour :)
Je sens que je n'ai pas été sage, et que je serai privé d'histoire.
Ouin ! ;-)
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne savent-ils pas que depuis quelques années un site se doit d'être un minimum interactif? Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en imaginant un site en php, toutes les pages baties sur la même structure): - Page PHP
Ok.
- config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires)
Non, ces fichiers sont appelés directement par ta page PHP, sans faire de nouvelle requête HTTP.
- style.css - scripts.js
Ok pour la première page vue par le visiteur. Pour les autres pages, ces fichiers sont en principe dans son cache (d'où l'intérêt d'en faire des fichiers externes, mais communs à toutes les pages du site).
- banniere.jpg (un site à souvent une bannière)
Oui pour toutes les images, bannière ou autres. Mais là encore ils seront souvent mis en cache.
Mais bon, même en supposant que rien n'est dans le cache, quand tu as compté l'accès à la page elle-même, et aussi aux deux fichiers CSS et JS, il te reste encore à rajouter 7 images pour arriver aux 10 hits par page.
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits. Les visiteurs ne voyent donc même pas 2 pages en moyenne.
Dans l'exemple que tu as donné, les visiteurs qui ne voient qu'une seule page avant de partir (écurés ? :-)) n'ont fait que 4 hits. En supposant des fichiers CSS et JS communs mais une nouvelle image à chaque page web, il leur faut voir 4 pages différentes pour faire 10 hits.
Enfin, si sur 100 visiteurs il y en a 50 qui ne voient qu'une page (50x4 0) et 49 qui en voient 4 (49x10I0), cela laisse 310 hits pour le 100e visiteur, qui peut ainsi visiter 154 pages.
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :)
Je sens que je n'ai pas été sage, et que je serai privé d'histoire. Ouin ! ;-)
CrazyCat
Olivier Miakinen wrote:
- config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires) Non, ces fichiers sont appelés directement par ta page PHP, sans faire
de nouvelle requête HTTP.
J'en apprends une bonne! Donc on peut faire autant d'includes qu'on veut sans que ce soit compté en hit?
- banniere.jpg (un site à souvent une bannière) Oui pour toutes les images, bannière ou autres. Mais là encore ils
seront souvent mis en cache.
C'est tout de même la première page qui compte :)
Mais bon, même en supposant que rien n'est dans le cache, quand tu as compté l'accès à la page elle-même, et aussi aux deux fichiers CSS et JS, il te reste encore à rajouter 7 images pour arriver aux 10 hits par page. Dans l'exemple que tu as donné, les visiteurs qui ne voient qu'une seule page avant de partir (écurés ? :-)) n'ont fait que 4 hits. En supposant des fichiers CSS et JS communs mais une nouvelle image à chaque page web, il leur faut voir 4 pages différentes pour faire 10 hits.
OK, je suis entièrement d'accord avec ça, mais si j'ajoute (pour le plaisir de te contredire) qu'une page ne contient que très rarement 1 seule image mais en moyenne 5 (banniere, menu on/off, puce, spacer), on remonte à 8 hits pour la première page.
Même si mon calcul était faux, tu avoueras que leur estimation de 10hits par visiteur et par jours est légère.
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :) Je sens que je n'ai pas été sage, et que je serai privé d'histoire.
Ouin ! ;-)
Au contraire, je suis pour le fait de récompenser les bonnes interventions et la tienne m'a appris au moins une chose importante.
Si mon hébergeur actuel persiste, tu auras la primeur de ma petite histoire :)
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Olivier Miakinen wrote:
- config.inc (pour connexion à la base + quelques fonctions)
- Header.inc (on va tacher de garder toujours le même haut de page)
- Footer.inc (idem pour les mentions inutiles ou obligatoires)
Non, ces fichiers sont appelés directement par ta page PHP, sans faire
de nouvelle requête HTTP.
J'en apprends une bonne! Donc on peut faire autant d'includes qu'on veut
sans que ce soit compté en hit?
- banniere.jpg (un site à souvent une bannière)
Oui pour toutes les images, bannière ou autres. Mais là encore ils
seront souvent mis en cache.
C'est tout de même la première page qui compte :)
Mais bon, même en supposant que rien n'est dans le cache, quand tu as
compté l'accès à la page elle-même, et aussi aux deux fichiers CSS et
JS, il te reste encore à rajouter 7 images pour arriver aux 10 hits par
page.
Dans l'exemple que tu as donné, les visiteurs qui ne voient qu'une seule
page avant de partir (écurés ? :-)) n'ont fait que 4 hits. En supposant
des fichiers CSS et JS communs mais une nouvelle image à chaque page
web, il leur faut voir 4 pages différentes pour faire 10 hits.
OK, je suis entièrement d'accord avec ça, mais si j'ajoute (pour le
plaisir de te contredire) qu'une page ne contient que très rarement 1
seule image mais en moyenne 5 (banniere, menu on/off, puce, spacer), on
remonte à 8 hits pour la première page.
Même si mon calcul était faux, tu avoueras que leur estimation de 10hits
par visiteur et par jours est légère.
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures
epiques avec un autre hébergeur... aventures qui méritent le détour :)
Je sens que je n'ai pas été sage, et que je serai privé d'histoire.
Ouin ! ;-)
Au contraire, je suis pour le fait de récompenser les bonnes
interventions et la tienne m'a appris au moins une chose importante.
Si mon hébergeur actuel persiste, tu auras la primeur de ma petite
histoire :)
--
Tout sur les eggdrops
http://www.c-p-f.org
ML @ eggdrop_fr@yahoogroupes.fr
- config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires) Non, ces fichiers sont appelés directement par ta page PHP, sans faire
de nouvelle requête HTTP.
J'en apprends une bonne! Donc on peut faire autant d'includes qu'on veut sans que ce soit compté en hit?
- banniere.jpg (un site à souvent une bannière) Oui pour toutes les images, bannière ou autres. Mais là encore ils
seront souvent mis en cache.
C'est tout de même la première page qui compte :)
Mais bon, même en supposant que rien n'est dans le cache, quand tu as compté l'accès à la page elle-même, et aussi aux deux fichiers CSS et JS, il te reste encore à rajouter 7 images pour arriver aux 10 hits par page. Dans l'exemple que tu as donné, les visiteurs qui ne voient qu'une seule page avant de partir (écurés ? :-)) n'ont fait que 4 hits. En supposant des fichiers CSS et JS communs mais une nouvelle image à chaque page web, il leur faut voir 4 pages différentes pour faire 10 hits.
OK, je suis entièrement d'accord avec ça, mais si j'ajoute (pour le plaisir de te contredire) qu'une page ne contient que très rarement 1 seule image mais en moyenne 5 (banniere, menu on/off, puce, spacer), on remonte à 8 hits pour la première page.
Même si mon calcul était faux, tu avoueras que leur estimation de 10hits par visiteur et par jours est légère.
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :) Je sens que je n'ai pas été sage, et que je serai privé d'histoire.
Ouin ! ;-)
Au contraire, je suis pour le fait de récompenser les bonnes interventions et la tienne m'a appris au moins une chose importante.
Si mon hébergeur actuel persiste, tu auras la primeur de ma petite histoire :)
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Patrick
Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en imaginant un site en php, toutes les pages baties sur la même structure): - Page PHP - config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires)
Les .inc ne sont pas vus par le client, donc pas de hit. D'autre part, mieux vaut éviter .inc comme extension, suffit d'un oubli pour que ca soit potentiellement lisible de l'extérieur. Mieux vaut garder .php, ainsi le code source n'est jamais vu. Encore mieux: mettre les bibliothèques _hors_ de l'arborescence web.
- style.css - scripts.js - banniere.jpg (un site à souvent une bannière)
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits. Les visiteurs ne voyent donc même pas 2 pages en moyenne.
Suffit d'utiliser les mécanismes de cache dans HTTP, et faire le nécessaire pour que les .CSS, .JS, .JPEG et consoeurs ne soient pas redemandés à chaque page web.
J'avoue avoir pris une situation extrème, il est possible d'inclure la feuille de style et les javascripts dans le header,
Mauvaise idée question cache et optimisation bande passante.
Patrick.
Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en
imaginant un site en php, toutes les pages baties sur la même
structure):
- Page PHP
- config.inc (pour connexion à la base + quelques fonctions) -
Header.inc (on va tacher de garder toujours le même haut de page) -
Footer.inc (idem pour les mentions inutiles ou obligatoires)
Les .inc ne sont pas vus par le client, donc pas de hit.
D'autre part, mieux vaut éviter .inc comme extension, suffit d'un oubli
pour que ca soit potentiellement lisible de l'extérieur. Mieux vaut
garder .php, ainsi le code source n'est jamais vu.
Encore mieux: mettre les bibliothèques _hors_ de l'arborescence web.
- style.css
- scripts.js
- banniere.jpg (un site à souvent une bannière)
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits. Les visiteurs
ne voyent donc même pas 2 pages en moyenne.
Suffit d'utiliser les mécanismes de cache dans HTTP, et faire le
nécessaire pour que les .CSS, .JS, .JPEG et consoeurs ne soient pas
redemandés à chaque page web.
J'avoue avoir pris une situation extrème, il est possible d'inclure la
feuille de style et les javascripts dans le header,
Mauvaise idée question cache et optimisation bande passante.
Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en imaginant un site en php, toutes les pages baties sur la même structure): - Page PHP - config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires)
Les .inc ne sont pas vus par le client, donc pas de hit. D'autre part, mieux vaut éviter .inc comme extension, suffit d'un oubli pour que ca soit potentiellement lisible de l'extérieur. Mieux vaut garder .php, ainsi le code source n'est jamais vu. Encore mieux: mettre les bibliothèques _hors_ de l'arborescence web.
- style.css - scripts.js - banniere.jpg (un site à souvent une bannière)
Ce qui nous donne, pour 1 page vue, un minimum de 7 hits. Les visiteurs ne voyent donc même pas 2 pages en moyenne.
Suffit d'utiliser les mécanismes de cache dans HTTP, et faire le nécessaire pour que les .CSS, .JS, .JPEG et consoeurs ne soient pas redemandés à chaque page web.
J'avoue avoir pris une situation extrème, il est possible d'inclure la feuille de style et les javascripts dans le header,
Mauvaise idée question cache et optimisation bande passante.
Patrick.
CrazyCat
Alexandre Havard wrote:
- config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires) .inc ? Dans le cas où le Add-Type serait mal renseigné, ce serait une
énorme faille de sécurité. L'extension .inc.php ferait tout autant l'affaire.
C'était un exemple, bien sur que je ne fais jamais de .inc tout seul :)
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Alexandre Havard wrote:
- config.inc (pour connexion à la base + quelques fonctions)
- Header.inc (on va tacher de garder toujours le même haut de page)
- Footer.inc (idem pour les mentions inutiles ou obligatoires)
.inc ? Dans le cas où le Add-Type serait mal renseigné, ce serait une
énorme faille de sécurité. L'extension .inc.php ferait tout autant
l'affaire.
C'était un exemple, bien sur que je ne fais jamais de .inc tout seul :)
--
Tout sur les eggdrops
http://www.c-p-f.org
ML @ eggdrop_fr@yahoogroupes.fr
- config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires) .inc ? Dans le cas où le Add-Type serait mal renseigné, ce serait une
énorme faille de sécurité. L'extension .inc.php ferait tout autant l'affaire.
C'était un exemple, bien sur que je ne fais jamais de .inc tout seul :)
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Olivier Miakinen
- config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires) Non, ces fichiers sont appelés directement par ta page PHP, sans faire
de nouvelle requête HTTP.
J'en apprends une bonne! Donc on peut faire autant d'includes qu'on veut sans que ce soit compté en hit?
Oui, bien sûr. Ces fichiers peuvent même se trouver dans une partie de ton arborescence inaccessible aux requêtes HTTP (c'est d'ailleurs recommandé). Voir également les réponses de Patrick et Alexandre.
- config.inc (pour connexion à la base + quelques fonctions)
- Header.inc (on va tacher de garder toujours le même haut de page)
- Footer.inc (idem pour les mentions inutiles ou obligatoires)
Non, ces fichiers sont appelés directement par ta page PHP, sans faire
de nouvelle requête HTTP.
J'en apprends une bonne! Donc on peut faire autant d'includes qu'on veut
sans que ce soit compté en hit?
Oui, bien sûr. Ces fichiers peuvent même se trouver dans une partie de
ton arborescence inaccessible aux requêtes HTTP (c'est d'ailleurs
recommandé). Voir également les réponses de Patrick et Alexandre.
- config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires) Non, ces fichiers sont appelés directement par ta page PHP, sans faire
de nouvelle requête HTTP.
J'en apprends une bonne! Donc on peut faire autant d'includes qu'on veut sans que ce soit compté en hit?
Oui, bien sûr. Ces fichiers peuvent même se trouver dans une partie de ton arborescence inaccessible aux requêtes HTTP (c'est d'ailleurs recommandé). Voir également les réponses de Patrick et Alexandre.
Xaero
CrazyCat wrote:
Si ça vous intéresse, l'auteur de la définition des hits est http://www.easy-hebergement.com
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :)
c'est à dire qu'en fait ( j'etais client chez cet hebergeur ) , la bas on voit un peu de tout et souvent des sites portails mal codés avec plein de choses inutiles , je suppose donc que cette limite est la pour leur garantir une certaine sécu par rapport à d'eventuelles attaques ( le micro paiement permet quand meme de conserver un certains anonymat qui n'existe pas quand on paye par cb ou cheque )
bon aprés cette limite n'as pas empéché des attaques sur leurs installations donc bon aprés on peut eventuellement s'interroger sur le bien fondé d'une telle limite ... je pense tout de meme qu'il y a moyen de s'arranger avec eux pour relever un peu cette limite qui il est vrai est un peu faiblarde :/
-- Xaero, Jeu en ligne Xm-jdr http://www.xaero-method.com/jdr
CrazyCat wrote:
Si ça vous intéresse, l'auteur de la définition des hits est
http://www.easy-hebergement.com
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures
epiques avec un autre hébergeur... aventures qui méritent le détour :)
c'est à dire qu'en fait ( j'etais client chez cet hebergeur ) , la bas on
voit un peu de tout et souvent des sites portails mal codés avec plein de
choses inutiles , je suppose donc que cette limite est la pour leur garantir
une certaine sécu par rapport à d'eventuelles attaques ( le micro paiement
permet quand meme de conserver un certains anonymat qui n'existe pas quand
on paye par cb ou cheque )
bon aprés cette limite n'as pas empéché des attaques sur leurs installations
donc bon aprés on peut eventuellement s'interroger sur le bien fondé d'une
telle limite ... je pense tout de meme qu'il y a moyen de s'arranger avec
eux pour relever un peu cette limite qui il est vrai est un peu faiblarde :/
--
Xaero,
Jeu en ligne Xm-jdr
http://www.xaero-method.com/jdr
Si ça vous intéresse, l'auteur de la définition des hits est http://www.easy-hebergement.com
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :)
c'est à dire qu'en fait ( j'etais client chez cet hebergeur ) , la bas on voit un peu de tout et souvent des sites portails mal codés avec plein de choses inutiles , je suppose donc que cette limite est la pour leur garantir une certaine sécu par rapport à d'eventuelles attaques ( le micro paiement permet quand meme de conserver un certains anonymat qui n'existe pas quand on paye par cb ou cheque )
bon aprés cette limite n'as pas empéché des attaques sur leurs installations donc bon aprés on peut eventuellement s'interroger sur le bien fondé d'une telle limite ... je pense tout de meme qu'il y a moyen de s'arranger avec eux pour relever un peu cette limite qui il est vrai est un peu faiblarde :/
-- Xaero, Jeu en ligne Xm-jdr http://www.xaero-method.com/jdr
André Acetoi
Recherchant un hébergeur pour un site composé essentiellement d'un forum [...]
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :)
Peut-être que ton message aurait eu sa place sur : fr.reseaux.internet.hebergement ??? -- Tonton Dédé
Le chemin qui va de l'humanité vers la bestialité, passe toujours par la nationalité et la religion...
(Ne mettez pas de "mot" pour me répondre)
Recherchant un hébergeur pour un site composé essentiellement d'un forum
[...]
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures
epiques avec un autre hébergeur... aventures qui méritent le détour :)
Peut-être que ton message aurait eu sa place sur :
fr.reseaux.internet.hebergement
???
--
Tonton Dédé
Le chemin qui va de l'humanité vers la bestialité,
passe toujours par la nationalité et la religion...
Recherchant un hébergeur pour un site composé essentiellement d'un forum [...]
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour :)
Peut-être que ton message aurait eu sa place sur : fr.reseaux.internet.hebergement ??? -- Tonton Dédé
Le chemin qui va de l'humanité vers la bestialité, passe toujours par la nationalité et la religion...
(Ne mettez pas de "mot" pour me répondre)
vero
Promue marginale calée en ordinatique, je décrypte le msg de *CrazyCat* <c82h9u$vv0$ relayé par les serveurs le 14/05/2004
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour )
je suis très (trop ?) sage, j'attends avec impatience, je trépigne même !
-- http://perso.wanadoo.fr/cv.vfr/ & http://perso.wanadoo.fr/rustines/ La force des forums c'est que chacun peut profiter pleinement des trouvailles, des défauts et du recul d'autrui. Unix is user friendly. He's just very picky about who his friends are.
Promue marginale calée en ordinatique, je décrypte le msg de *CrazyCat*
<c82h9u$vv0$1@s1.read.news.oleane.net> relayé par les serveurs le
14/05/2004
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques
avec un autre hébergeur... aventures qui méritent le détour )
je suis très (trop ?) sage, j'attends avec impatience, je trépigne même
!
--
http://perso.wanadoo.fr/cv.vfr/ & http://perso.wanadoo.fr/rustines/
La force des forums c'est que chacun peut profiter pleinement
des trouvailles, des défauts et du recul d'autrui.
Unix is user friendly. He's just very picky about who his friends are.
Promue marginale calée en ordinatique, je décrypte le msg de *CrazyCat* <c82h9u$vv0$ relayé par les serveurs le 14/05/2004
Et si vous êtes sages, vous aurez bientôt le récit de mes aventures epiques avec un autre hébergeur... aventures qui méritent le détour )
je suis très (trop ?) sage, j'attends avec impatience, je trépigne même !
-- http://perso.wanadoo.fr/cv.vfr/ & http://perso.wanadoo.fr/rustines/ La force des forums c'est que chacun peut profiter pleinement des trouvailles, des défauts et du recul d'autrui. Unix is user friendly. He's just very picky about who his friends are.
bru
CrazyCat wrote:
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne savent-ils pas que depuis quelques années un site se doit d'être un minimum interactif? Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en imaginant un site en php, toutes les pages baties sur la même structure): - Page PHP - config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires) - style.css - scripts.js - banniere.jpg (un site à souvent une bannière)
hello
les .inc sont du php ? si oui, alors, tu peux les exclures de la liste. *par contre*, il me semble que chaque image soit un hit.
à plux
CrazyCat wrote:
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne
savent-ils pas que depuis quelques années un site se doit d'être un
minimum interactif?
Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en
imaginant un site en php, toutes les pages baties sur la même structure):
- Page PHP
- config.inc (pour connexion à la base + quelques fonctions)
- Header.inc (on va tacher de garder toujours le même haut de page)
- Footer.inc (idem pour les mentions inutiles ou obligatoires)
- style.css
- scripts.js
- banniere.jpg (un site à souvent une bannière)
hello
les .inc sont du php ?
si oui, alors, tu peux les exclures de la liste.
*par contre*, il me semble que chaque image soit un hit.
Les hébergeurs seraient-ils à 20.000 lieues de l'internet réel? Ne savent-ils pas que depuis quelques années un site se doit d'être un minimum interactif? Ils parlent de 10 hits/jour par visiteur, ce qui veut donc dire (en imaginant un site en php, toutes les pages baties sur la même structure): - Page PHP - config.inc (pour connexion à la base + quelques fonctions) - Header.inc (on va tacher de garder toujours le même haut de page) - Footer.inc (idem pour les mentions inutiles ou obligatoires) - style.css - scripts.js - banniere.jpg (un site à souvent une bannière)
hello
les .inc sont du php ? si oui, alors, tu peux les exclures de la liste. *par contre*, il me semble que chaque image soit un hit.
