Quels sont les avantages et les inconvénients de l'utilisation d'un frontal personnalisé pour récupérer le contenu d'un back-end Wordpress?
Je construis des sites wordpress depuis quelques années maintenant et j'ai remarqué quelques petites choses qui me dérangent.
1. C'est assez lent (déclaration générale affreuse, je m'excuse)
Mon désir initial de créer un frontal personnalisé est né d'une observation. Les sites Wordpress que je construisais n’étaient pas aussi rapides que je le voulais (3-5 secondes, parfois plus).
@Kenrik - Ils ont certainement été déployés sur l'hébergement partagé survendu, mais ils ont obtenu de bons scores Yslow. J'ai essayé et constaté que les sites étaient environ trois fois plus rapides que lorsque je ne chargeais pas la surcharge WP. Même machine, même score Yslow, 3 fois plus rapide. Je ne suis pas un expert en matière d’utilisation du processeur Wordpress, mais j’ai lu que c’était assez intense et je n’étais donc pas surpris des gains de vitesse que j’ai réalisés.
2. C'est souvent trop complexe pour les besoins d'un site web simple
Juste une remarque: je construis principalement des sites pour les lignes de mode et la gestion de portefeuille, complexes en interaction front-end, mais avec relativement peu de données. Ces sites ne seront jamais gigantesques et ils nécessitent très peu de code pour récupérer le contenu nécessaire. Ma question est donc en grande partie théorique.
Je pense que Wordpress est une plate-forme fantastique et qu’elle a peu de limites à la croissance, mais je pense que le chargement de toutes ses ressources est excessif pour de nombreux projets plus petits, destinés à être servis à partir d’un hébergement mutualisé.
3. Il y a beaucoup de problèmes de sécurité (surtout lors de l'utilisation de plugins)
En ce qui concerne la sécurité, je peux voir en quoi ma question était ambiguë et contradictoire. Ce que je voulais dire, c’est que, d’après ma compréhension, un site Wordpress, au-delà de toute faille de sécurité réelle, est vulnérable car les attaquants savent qu’il s’agit d’un site Wordpress. Cela crée un défi (briser une plate-forme populaire) et une feuille de triche inhérente (les vulnérabilités de Wordpress sont bien documentées). Donc, bien sûr, une solution personnalisée pourrait comporter davantage de failles de sécurité, mais je me demande si cela ne serait pas contrebalancé par le fait qu’elle rend le fonctionnement interne anonyme. Comme @Kenrik l'a dit, "ils ne s'inquiéteront probablement pas, car qui se soucie de pirater un seul site avec un code personnalisé suspect?"
4. Il est difficile d'optimiser les temps de chargement des pages
Ce que je voulais dire par difficulté d'optimisation de chargement de page, c'est que si l'on obtient une fonctionnalité interactive via de nombreux plugins, de nombreux scripts sont chargés et il devient plus fastidieux de les combiner, de les modifier, de les personnaliser ou de les optimiser. Je trouve plus facile d'inclure des plugins jQuery en dehors de Wordpress et de ne pas avoir à gérer la manière dont ils sont connectés à wp_head.
Alors récemment, j'ai décidé de m'occuper de mon développement différemment et d'utiliser Wordpress comme un outil principal. J'utilise l'espace administrateur pour mettre à jour le contenu et remplir la base de données, mais j'utilise une couche d'accès aux données personnalisée et des fonctions personnalisées sur le serveur frontal pour récupérer et afficher le contenu. Pour les pages où la connexion est nécessaire, j'inclus le fichier d'en-tête de blog et utilise les fonctionnalités de gestion des informations d'identification de wordpress.
Selon moi, le principal avantage de cette solution frontale indépendante est qu'elle facilite le développement (vous écrivez seulement ce dont vous avez besoin, et c'est votre propre travail), il est plus facile d'optimiser les chargements de page (vous contrôlez mieux ce les scripts sont utilisés et comment les combiner de manière optimale), vous ne prévenez pas le monde entier du piratage de l'existence d'une installation WordPress (car les fichiers ne sont plus chargés depuis un thème) et plus.
Inconvénients: Sécurité, manque d’évolutivité, manque de soutien des développeurs pour les solutions personnalisées ... Autre chose?
J'aime beaucoup créer des sites en dehors des contraintes de wordpress, je crains simplement de ne pas tenir compte de certains problèmes majeurs liés à cette approche.
S'il vous plaît laissez-moi savoir si c'est le cas.
À votre santé
Pour conclure rétroactivement:
Je suis sûr à 100% que mes sites sont plus rapides dans le même environnement lorsque je n'utilise pas l'interface frontale native de Wordpress.
Je doute que mon code soit aussi sûr que Wordpress, mais je pense que je peux le verrouiller et le fait qu’il ait une interface anonyme peut en faire une cible moins intéressante.
Je suis certain de pouvoir coder les fonctionnalités beaucoup plus rapidement lorsque je déploie une solution frontale extrêmement simple et personnalisée.
Je me pose donc des questions, compte tenu de mon environnement et de mes contraintes, si cela reste une mauvaise idée. Et si oui, quelles sont les principales raisons.
Je suis sûr qu’il existe peut-être d’autres codeurs curieux, ambitieux et sous-instruits qui pourraient se demander la même chose. Ils bénéficieront probablement de tout ce que vous avez à dire sur le sujet.
Merci à tous
Vous citez une expérience avec WP remontant plus loin que la mienne ... Pourtant, je ne considère pas ces problèmes comme si importants. De quelle échelle de sites parle-t-on?
C'est assez lent
Je pense que c'est un peu trop de généralisation. Lent peut être placé dans un contexte de matériel spécifique, de tâches et de niveau de trafic. C'est une déclaration générale autrement.
C'est souvent trop complexe pour les besoins d'un site web simple
Complexe pour qui? Utilisateurs? Développeur? WP est facile à installer et à utiliser. Créez du contenu et vous avez ce site simple. Où est la complexité ici?
Il y a beaucoup de problèmes de sécurité (surtout lors de l'utilisation de plugins)
Encore une fois, un peu trop de déclaration générale. WP lui-même est relativement sécurisé et la plupart des problèmes de sécurité qui ont eu un impact majeur semblent provenir de versions très obsolètes de WP.
L'état des plugins et la sécurité sont loin d'être parfaits, mais rien n'empêche d'être très sélectif ou de développer des plugins sécurisés et fiables, non?
Il est difficile d'optimiser les temps de chargement des pages
Encore une fois, je ne suis pas sûr de quelle échelle parlons-nous. L’optimisation des sites de taille moyenne à moyenne semble triviale - installez un bon plug-in de cache statique, améliorez-le avec la mise en cache des opcode ... Ajoutez un serveur Web alternatif ou un proxy inverse si nécessaire.
J'aime beaucoup créer des sites en dehors des contraintes de wordpress, je crains simplement de ne pas tenir compte de certains problèmes majeurs liés à cette approche.
Je n’ai quasiment qu’une question à vous poser . Etes-vous absolument sûr de le faire mieux, plus rapidement et avec plus de sécurité que le système natif WP front-end?
Je ne pose pas cette question de façon sarcastique, je pense qu’il serait peut-être plausible que, pour une tâche très étroite, un système frontal fabriqué sur mesure et verrouillé soit raisonnable. Mais je remarque également que l'excès de confiance dans le fait que la solution personnalisée est "simplement meilleure" que le travail collectif de nombreux développeurs/entreprises n'est pas inhabituel dans le développement Web.
Mettre à jour
Mon désir initial de créer un frontal personnalisé est né d'une observation. Les sites Wordpress que je construisais n’étaient pas aussi rapides que je le voulais (3-5 secondes, parfois plus). [...] Ils ont certes été déployés sur l'hébergement partagé survendu, mais ils ont obtenu de bons scores Yslow.
YSlow (et PageSpeed) sont d'excellents outils, mais ils sont intrinsèquement limités. Ils peuvent uniquement analyser et donner des conseils sur les performances frontales et la manière dont le site est traité par un navigateur. Ils ne donnent aucune indication sur les performances de votre serveur et le fait de poursuivre aveuglément des scores élevés au front peut être néfaste pour la charge du serveur.
Vous devriez utiliser de tels outils, mais vous ne devriez jamais limiter votre vision de la performance du site.
Sur l'hébergement - tout site dynamique sur l'hébergement partagé s'étouffera sous une charge élevée. Encore une fois, s’il peut sembler facile de modifier et d’obtenir des scores élevés au front, l’hébergement partagé côté serveur est critique manque de flexibilité en termes de matériel et de pile Web nécessaire pour les sites à fort trafic et/ou pour des temps de chargement rapides.
Je pense que le chargement de toutes ses ressources est excessif pour de nombreux projets plus petits, destinés à être desservis par un hébergement partagé.
Aviez-vous essayé la mise en cache statique des pages? Il supprime efficacement le noyau de WP de la plupart des demandes et il est à peu près aussi rapide que vous pouvez obtenir sur un hébergement partagé. Si vous avez essayé et que vous n'êtes pas satisfait des pages, fournies à partir de cache statique, WordPress n’est pas votre problème, mais l’hébergement.
Ce que je voulais dire, c’est que, d’après ma compréhension, un site Wordpress, au-delà de toute faille de sécurité réelle, est vulnérable car les attaquants savent qu’il s’agit d’un site Wordpress. Cela crée un défi (briser une plate-forme populaire) et une feuille de triche inhérente (les vulnérabilités de Wordpress sont bien documentées).
Il n'existe aucune vulnérabilité de sécurité publique et connue dans la version stable de WordPress. Ceux qui surviennent sont fixés en quelques heures.
Une configuration de serveur médiocre (occurrence commune sur des hôtes peu coûteux) ou une version WP obsolète est ce qui vous motive, pas le simple fait d'utiliser WP.
Ce que je voulais dire par difficulté d'optimisation de chargement de page, c'est que si l'on obtient une fonctionnalité interactive via de nombreux plugins, de nombreux scripts sont chargés et il devient plus fastidieux de les combiner, de les modifier, de les personnaliser ou de les optimiser. Je trouve plus facile d'inclure des plugins jQuery en dehors de Wordpress et de ne pas avoir à gérer la manière dont ils sont connectés à wp_head.
Oui, certains plugins ne savent pas comment charger correctement les scripts. Ce sont vraiment des arguments pour choisir les plugins avec soin, pas contre le noyau WordPress.
Concaténer et optimiser les scripts est trivial avec un bon plugin de mise en cache.
Dans l’ensemble et après vos mises à jour, j’ai le sentiment que vous êtes trop impatient de vous défaire de WordPress pour les problèmes inhérents à tout système de gestion de contenu complexe et complet (vous avez besoin d’un hébergement décent pour le rendre instantané) et vous n’avez pas passé beaucoup de temps à chercher des solutions de cache. .
Cela pourrait ne pas convenir au type de sites que vous construisez et vous feriez mieux de chercher dans un CMS plus léger, plus simple et moins fonctionnel qui fonctionnera mieux avec vos contraintes d'hébergement.
Pour ajouter à ce que Rarst a dit, mais je pense que ce poste est une ligne de démarcation.
1.Il est assez lent Vous devez fournir plus de détails, un site avec des centaines de milliers de pages et 1 million de vues par mois n'est pas la même chose qu'un blog/portfolio régulier. Il est assez simple et très courant de charger un site WordPress en moins de 2 secondes en fonction de l'hébergement/plugins/média/optimisation. Ce n'est pas vraiment un problème spécifique à Wordpress, sauf si vous avez un très grand site. Votre compréhension de la vitesse de la page semble être faible, l'optimisation du site Web est beaucoup plus que Yslow ....
Par exemple, j'ai un site dynamique avec une bonne quantité d'images, de widgets, de 5 éléments de flux RSS distants et de 10 publications, le chargement initial est de 2,9 secondes sans cache, rechargé avec le cache, il est de 1,02 seconde. Je peux dire que cela est normal pour tous mes sites WordPress. (La plupart des 2,9 secondes de chargement initial sont des images que le cache utilise clairement lors du rechargement.)
2. C'est souvent trop complexe pour les besoins d'un simple site Web . WordPress est sans aucun doute l'un des CMS les plus simples qui conservent des fonctionnalités assez avancées. Si vous ne tirez pas parti de ces fonctionnalités, pourquoi utilisez-vous WordPress pour commencer? Si vous trouvez cela complexe, à quoi comparez-vous cela, .net, HTML statique, nodejs?
3. Il a beaucoup de problèmes de sécurité (en particulier lors de l'utilisation de plugins) WordPress lui-même est sécurisé, surtout l'année dernière +, il n'y a pas eu de problèmes majeurs. La plupart des problèmes de sécurité dans WordPress proviennent de la pure ignorance des utilisateurs téléchargeant des thèmes de programmes malveillants, des plugins mal écrits, ne mettant pas à jour leur site et un mauvais hébergement. De loin, la grande majorité des problèmes de sécurité ne sont pas du tout liés au cœur de WordPress. Je peux fournir des exemples très spécifiques si nécessaire.
4. Il est difficile d'optimiser les temps de chargement des pages . Je ne pense vraiment pas que ce soit exact. Il existe une poignée d'excellents plug-ins qui rendent l'optimisation de WordPress un jeu d'enfant par rapport à la réalisation manuelle de tout (ce qui était la norme). Ces plugins permettent littéralement d'économiser des jours de travail en mettant en cache, en minimisant, en utilisant, les CDN, etc., de manière optimale, avec littéralement le clic d'un bouton, comment trouvez-vous cela difficile? Avez-vous des données spécifiques réelles que nous pouvons examiner?
Martin: Après avoir lu cette question et les réponses qui l'accompagnent, voici mes deux sous sur votre question:
Avantages de l'utilisation d'un frontal personnalisé par rapport à WordPress
- Temps de chargement potentiellement plus rapides, car vous pourriez réduire le nombre de scripts, etc. chargés (mais voir ci-dessous)
- Plus de contrôle sur les requêtes de base de données, ce qui pourrait éventuellement raccourcir les temps de chargement des pages.
Contre l'utilisation d'un frontal personnalisé par rapport à WordPress
Vitesse: Une de vos préoccupations avec WP est la vitesse. D'après mon expérience, à moins que vous n'utilisiez des plug-ins insérant leur propre JS dans l'en-tête (via wp_head()), WordPress ne charge que ce que vous lui indiquez.
Omettre wp_head() de votre modèle d'en-tête empêchera, par exemple, WP de charger la nouvelle barre d'administration.
Ce que cela signifie, c’est qu’il n’ya aucun avantage à utiliser son propre frontal, puisque vous pouvez personnaliser ce qui est chargé dans votre en-tête.
Complexité: Votre souci de la complexité semble viser le back-end, pas le front-end. Bien que je pense que WP dispose d'une excellente interface utilisateur, je peux comprendre le souhait d'adapter ses fonctionnalités à des projets spécifiques. Dans de nombreux cas, vous pouvez modifier votre fichier functions.php et indiquer à WordPress ce qu'il doit afficher ( . Voir cet article pour quelques exemples).
Donc, si c'est le back-end qui est trop complexe, je suppose que vous pouvez toujours construire le vôtre. Si vous parlez de la complexité des requêtes de base de données ou de l'utilisation des ressources de WP, je m'en remettrai à une personne mieux informée sur son fonctionnement.
Sécurité: Je n'achète pas vraiment l'argument voulant que l'exécution d'un serveur frontal personnalisé soit plus sécurisée. Si vous utilisez un back-end WP, un pirate informatique pourrait tout aussi facilement le découvrir en consultant vos chemins d'URL (qui incluent/wp-content /, etc.).
Il existe de nombreux plugins qui suppriment le méta "généré par" du front-end et font toutes sortes de choses pour améliorer la sécurité ( Secure WordPress est un bon exemple). Je pense en réalité qu'il est moins sûr de pouvoir compter sur une solution personnalisée développée en interne. Ce n’est pas un commentaire sur vos compétences en matière de codage, mais ... il me semble que toute une équipe de développeurs qui gagnent leur vie en ne faisant que WordPress serait plus fiable qu’un gars.
Vous soulevez un bon point en ce que WP a en quelque sorte le blason d'un pirate informatique. Cependant ... je n'ai jamais été piraté que sur des versions obsolètes WP et sur l'hébergement partagé où l'hôte était en faute. Depuis la version 3.0, il n'y a eu aucun problème. Je pense que si vous restez à jour sur votre installation, vérifiez que les plug-ins que vous utilisez sont sécurisés et pris en charge, et utilisez le bon sens, vous n'aurez aucun problème de sécurité.
Temps de chargement des pages: Je suis tout à fait d'accord avec vous sur le fait qu'utiliser un tas de plugins (ou certains plugins) peut avoir un impact négatif sur les temps de chargement des pages. Cependant, cela bloque davantage les plugins et le choix du développeur de les utiliser que sur WP, n'est-ce pas? Vous pouvez utiliser straight jQuery avec ou sans votre interface frontale personnalisée. Par conséquent, je ne vois aucun avantage à devenir personnalisé ici lorsqu'un thème WP intelligemment conçu fera aussi bien l'affaire.
Portabilité: Ma plus grande préoccupation à propos de l'utilisation d'un frontal personnalisé est qu'il n'est pas aussi portable ni aussi évolutif que ceux gérés par la communauté. Ma société ne construit jamais des systèmes de gestion de contenu personnalisés pour les clients, car de nombreuses personnes sont venues nous voir et nous ont dit: "Notre vieil homme en ligne a construit ce logiciel, et maintenant il est en Grèce, et je Je ne trouve personne pour le mettre à jour. "
WordPress utilise des fonctions standard bien documentées que tout développeur WP expérimenté saura. Avec une grande plate-forme robuste et prospère telle que WordPress, un client peut très facilement trouver un autre développeur qui prendra en charge la maintenance si l'ancien disparaissait.
pensées finales
Tout ce qui précède étant dit, je pense que vous avez posé une bonne question qui soulève des préoccupations légitimes. Je peux voir la mise en œuvre d’un système frontal personnalisé pour un projet interne - mais c’est seulement si vous croyez que le temps de développement supplémentaire en vaut la peine.
Pour moi, les inconvénients de cette approche l'emportent sur les avantages.
Je ne sais vraiment pas si vous avez beaucoup utilisé Wordpress en fonction de ce que vous avez posté? Nous allons utiliser mon site comme exemple. Il obtient un score yslow de 90% et se charge en une fois et demie à plat pour un nouvel utilisateur. S'ils l'ont mis en cache dans leur navigateur, c'est instantané. Je n'utilise même pas de pages statiques.
Maintenant, je suis sur un serveur dédié .. donc je n'ai pas à faire face à l'hébergement mutualisé et je peux optimiser mon serveur (gzip etc.)
Ma meilleure hypothèse est que vous utilisiez un serveur d'hébergement partagé vendu à 120%. Ensuite, il s'agit d'une analyse.
Toute autre coutume va avoir beaucoup plus de vulnérabilités en matière de sécurité que quelque chose comme Wordpress qui se fait écraser tous les jours. Sauf qu'ils ne s'inquiéteront probablement pas, car qui se soucie de pirater un seul site avec un code personnalisé incertain?
METTRE À JOUR:
Je comprends un peu plus d'où vous venez. Cependant, une grande partie de ce qui rend WordPress "lent" sont des thèmes mal codés ou des serveurs non optimisés. Si votre fournisseur d’hébergement dispose de serveurs avec uniquement une installation de base Apache/php/mysql, il n’est probablement pas optimisé pour exécuter Wordpress. site.
Il s’agit toutefois d’un problème de "serveur", pas de Wordpress. J'ai un site qui se trouve sur mon serveur dédié (Mac Mini Server, 2.66 C2D, 4 Go) qui se charge en 1,5 seconde et SAME SITE se charge en 4sec sur InMotion, qui est l'un des meilleurs/meilleurs fournisseurs d'hébergement partagé.
Maintenant, mon "petit serveur" n’est nullement puissant et pourtant, il met en valeur tout hébergement partagé. L’optimisation des serveurs est tout aussi importante que l’optimisation du site.