développer un site de e-commerce

[lodan]

Bonjour,

Je veux développer un site de e-commerce et les performances d'affichage sont l'un des principaux critères.

Il n'est pas question d'utiliser un cms dont le résultat serait trop lourd et la souplesse d'adaptation inadéquate.

Pour résoudre en partie ce point, j'ai dans l'idée d'avoir une partie du site en statique et une autre en dynamique.

La partie statique serait générée chaque jour sur le serveur local avant mise en ligne dans la nuit sur le serveur web.

Dois-je générer des pages html ou des pages de cache ?

Pour les pages dynamiques, les données variables doivent-elles venir avec le formulaire ou être poussées en ajax depuis le serveur.

Je vous remercie pour votre retour d'expérience.

[jpvincent]

question stratégie globale, si tes pages sont majoritairement statiques, ça vaut effectivement le coup de mettre tout ou partie en cache. Vu que c'est du e-commerce, tu as peut être des stocks à gérer, donc je te conseillerais plutôt de gérer des mises en cache à la demande plutôt que de ne générer ton site qu'une fois par jour.
Exemple :
- le premier visiteur qui arrive sur une page génére la page dynamiquement, le cache est enregistré
- un second visiteur arrive, on lui sert le cache
- lorsqu'un client achète un produit, tu vérifies ton stock ou toute autre partie dynamique, et tu vas effacer le cache de la page produit si elle n'est plus valide
- à chaque mise à jour de ton site, tu revides tout ton cache

Concernant quoi mettre en cache, le plus simple et le plus efficace est de mettre la page entière en cache, mais le plus souple est de gérer tes pages par modules qui seraient chacun responsable de leur mise en cache. A toi de voir en fonction de comment tu organises ton code par ailleurs.

Pour gérer les les parties dynamiques qui n'ont généralement pas de contrainte en terme de référencement, tu peux charger en javascript les parties dynamiques comme le nombre d'articles dans le panier après que la page statique ait été envoyée. Tu casses cependant cette fonctionnalité pour 0.5% des gens qui n'ont pas javascript.
Pour les parties vraiment dynamiques comme l'inscription et le paiement, bien sur tu ne gères pas de cache au niveau de la page, ce ne sont de toute façon pas les pages qui sont beaucoup appelées

Maintenant dis toi bien que du point de vue de l'utilisateur, le temps passé à générer la page est généralement en dessous de la seconde, alors que la plupart des sites affichent leurs pages en plusieurs secondes : 80% du temps passé à afficher une page est généralement côté client

[lodan]

Les produits vendus sont fabriqués sur commande, donc pas de stock.

Si j'ai bien compris le cache ne me sera pas utiles sur les pages statiques et au cas par cas sur les pages dynamiques.

Il faut aussi alléger la partie client puisque c'est là que ce passe 80 % du temps de chargement. Donc pousser en ajax du serveur vers le sites des images est plus performant que de tout envoyer en chargement sur le poste client.

[svacher]

Bonjour,

je me permet de compléter un peu le problème, vu que j'ai exactement la même problématique que lodan.

Imaginons une partie du site qui contient les articles classés par catégories... Cette liste peut changer de temps en temps (ajout suppression d'article, modification de prix, ...), mais la mise à jour de ces informations n'est pas critique.
Ma question est la suivante :
mieux vaut-il gérer la cache avec une durée de vie assez courte et auto-gérer cette cache page par page (ce qui suppose que les fichiers de cache sont générés pas les visites) et avec quel type de cache
OU
mieux vaut-il avoir un générateur indépendant qui créer des pages HTML pures et qui sont recalculées 1 fois par jour ou à la demande et laisser le minimum de scripts en dynamique ?

En clair, mieux vaut des fichiers en cache ou générer du HTML par un processus externe (cache VS HTML généré) ?
La question de base de lodan étant "Dois-je générer des pages html ou des pages de cache ?".

En attendant vos éclaircissements et en espérant avoir été clair...
Merci de vos idées...

[jpvincent]

perso j'ai toujours préféré faire des pages qui se mettent en cache au fur et à mesure qu'elles sont découvertes :
- ça prend moins de place sur le disque, car certaines pages ne sont jamais appelées
- c'est très simple à mettre en oeuvre dans un premier temps (if file_exists print include)

Maintenant si tu veux vraiment faire de l'optimisation pointue, tu peux carrément supprimer apache / PHP des frontaux pour passer sur un serveur HTTP ultra light qui va distribuer des fichiers statiques. Auquel cas il faut effectivement générer dynamiquement toutes les pages en backend pour les pousser sur les serveurs frontaux.

si tu distribues des millions de vues de pages, ça vaut effectivement le coup d'investir dans la 2nde méthode, pour la plupart des sites je resterais sur la première.

Dans les deux cas, si il n'y a pas de contrainte de référencement, je passerais les petits bouts dynamiques (nombre d'élément dans le panier par exemple) en AJAX ou en iframe

[svacher]

Ce qui me gène avec les fichiers de cache, c'est qu'ils peuvent être définis à plusieurs niveaux et que l'on ne maitrise pas toujours tout.

Mais j'ai encore du mal à faire une comparaison entre les avantages et les inconvénients de chaque méthode...

[jpvincent]

Pour être clair il peuvent être créés de n'importe quel endroit du code. Et oui un cache mal maîtrise c'est des heures de debug en perspective
La seule solution c'est de bien organiser son code pour centraliser l'endroit où tu gères le cache et les exceptions

[djnos]

Le generation statique etait tres a la mode au debut des annees 2000, il est aujourd'hui plus souple de simuler ce statisme au moyen d'un reverse proxy