comment identifier pourquoi un site Web est lent?
On m'a posé cette question une fois lors d'une interview:
"Supposons que vous possédiez un site Web sur lequel le serveur se trouve à un endroit éloigné. Un jour, certains utilisateurs vous appellent/vous disent que le site est abominablement lent. Comment identifieriez-vous pourquoi le site est lent? De plus, lorsque vous consultez le site Web vous-même comme n'importe quel utilisateur (à l'aide de votre navigateur), le site se comporte très bien. "
Je ne pouvais penser qu'à une seule chose (qui a été abattue):
- Vérifiez les journaux du serveur pour analyser le trafic entrant. Peut-être une attaque DoS ou un trafic exceptionnellement élevé. L'enquêteur m'a dit de supposer que le serveur avait un trafic normal et aucun DoS.
J'étais un peu perdu parce que je n'avais jamais pensé à ce problème. Je n'ai presque aucune idée du fonctionnement d'un serveur/site Web. Donc, si quelqu'un pouvait mettre en évidence quelques approches, ce serait bien.
En parcourant Google, j'ai pu trouver seulement cet article merveilleux et pertinent . Cet article est un peu trop technique pour moi maintenant, mais je le décompose lentement et le comprends.
Puisque vous avez déjà dit que lorsque vous consultez le site vous-même, la vitesse est bonne, cela signifie que (au moins pour les pages que vous avez consultées) il n'y a rien de mal avec le serveur et il peut servir ces pages à une bonne vitesse. Ce que vous devriez comprendre à ce stade, c'est quelle est la différence entre vous et l'utilisateur qui signale que votre site est lent. Ce pourrait être beaucoup de choses différentes:
- L'utilisateur utilise-t-il une connexion réseau lente (mobile par exemple)?
- L'utilisateur rencontre-t-il les mêmes problèmes avec d'autres sites Web hébergés chez le même hébergeur? Si c'est le cas, cela pourrait indiquer un problème de réseau. Normalement, cela pourrait également indiquer un problème de ressources sur le serveur Web, mais dans ce cas, le site serait également lent pour vous.
- Si aucune des réponses ci-dessus n'aboutit à une réponse, vous pouvez supposer que la connexion au serveur et au serveur lui-même sont corrects. Cela signifie que le problème doit être dans l'appareil des utilisateurs. Découvrez quel navigateur/système d'exploitation il utilise et essayez de reproduire le problème. Si cela échoue, découvrez s'il utilise un antivirus ou un logiciel similaire qui pourrait causer des problèmes.
Il s'agit d'un excellent outil pour trouver la vitesse des pages Web et vous explique ce qui la ralentit: https://developers.google.com/speed/pagespeed/insights
Je pense que l'une des choses importantes qui manque dans les réponses ci-dessus est l'emplacement du serveur, qui peut jouer un rôle essentiel dans les performances Web.
Quand quelqu'un dit qu'il faut plus de temps pour ouvrir une page Web, cela signifie une latence élevée. Une latence élevée peut être due à l'emplacement du serveur. Supposons que vous êtes le propriétaire de la page Web, le serveur et le client sont co-localisés, de sorte qu'il aura une faible latence.
Mais, maintenant, si le client traverse la frontière, le temps de latence augmentera considérablement. Et donc une lente performance.
Un autre facteur est la mise en cache qui affecte considérablement le temps de latence.
Prenant l'exemple de Facebook, ils ont un serveur partout dans le monde pour réduire le temps de latence (et aussi pour fournir plusieurs autres avantages) et ils utilisent un énorme système de mise en cache pour mettre en cache leurs données chaudes (sujets tendances) tandis que les données froides (anciennes données) sont stocké sur le disque dur, il faut donc plus de temps pour charger une photo ou un post plus ancien. Ainsi, un utilisateur aurait pu s'en plaindre alors qu'il essayait de charger des données froides.
Évidemment, un problème avec la connexion de la personne se connectant à votre site OR il est possible que ce soit un problème temporaire et au moment où vous avez vérifié votre site, tout était dandy. Vous pouvez vérifier vos journaux ou demander votre hôte en cas de problème au moment du ralentissement.
Normalement, l'utilisateur prend le temps de chargement de la page comme mesure pour découvrir que le site est lent. Mais si vous voulez vraiment savoir ce qui prend le temps maximum, vous pouvez ouvrir le débogueur du navigateur en appuyant sur f12. si votre navigateur est chrome cliquez sur le réseau et voyez quels appels votre application effectue et lesquels prennent le maximum de temps. Si vous utilisez Firefox, vous devez installer firebug. Si vous l'avez, puis appuyez à nouveau sur f12 et cliquez sur Net.
Une raison pourrait être que le rôle de l'utilisateur est différent de votre rôle. Vous pourriez avoir supposé un privilège d'administrateur (quelque chose comme le rôle de super utilisateur) et le code pourrait tout simplement permettre tout pour un tel rôle, ce qui signifie qu'il ne fait pas vraiment beaucoup de vérification conditionnelle pour voir ce qui est autorisé ou non. Parfois, il est très difficile d'obtenir tous les privilèges de l'utilisateur et de vérifier les conditions, la façon dont le cours dépend de la façon dont l'autorisation est mise en œuvre. Cela signifie que la page peut être très lente pour des rôles spécifiques. Par conséquent, vous devez découvrir les rôles de l'utilisateur et voir si c'est une raison.
Je peux penser à ces quelques raisons (les deux premières sont déjà mentionnées ci-dessus):
- Latence élevée due à l'emplacement du client
- Il peut être nécessaire d'augmenter la mémoire du serveur
- Nombre d'appels de service à partir de la page.
- Si un service pouvait être arrêté au moment de la réclamation, cela pourrait empêcher le chargement de la page.
- La charge du serveur peut être trop élevée au moment de la mauvaise expérience. Le serveur peut avoir besoin d'augmenter les ressources (par exemple, ajouter un autre serveur/serveur Web au cluster).
- Vérifiez si un travail d'arrière-plan était en cours d'exécution sur le serveur à ce moment-là.
Il est important de vérifier les journaux et les planifications des travaux par lots pour déterminer ce que tout était en cours d'exécution à ce moment-là.
J'espère que cette aide.
Bien que votre question soit assez claire, l'optimisation du site Web est un sujet très vaste.
La majorité des frameworks de développement Web populaires sont, pour une raison quelconque, extrêmement inefficaces sur les processeurs.
L'ancienne façon de développer des applications Web à n niveaux est toujours très pertinente et est toujours considérée comme la meilleure pratique selon le W3C. Si vous prenez un peu de temps pour lire la structure du code source des frameworks de développement Web les plus populaires, vous verrez qu'ils exécutent beaucoup plus de code sur le serveur que nécessaire.
Cela peut sembler un peu simple, mais moins vous exécutez de code sur le serveur et plus vous exécutez de code sur le client, plus vos serveurs fonctionneront rapidement. Parfois, opposer le code du cadre à l'ancienne est le meilleur moyen de comprendre cela. Voici un lien vers une mini application Web pleinement fonctionnelle qui représente les meilleures pratiques du W3C et exécute la quantité minimale de code sur le serveur et la quantité maximale de code sur le client: http://developersfound.com/W3C_MVC_EX. Zip cette base de code est également compatible MVC.
Cette base de code est livrée avec un vidage de base de données MySQL, un code PHP et côté client. Pour voir ce code en action, vous devrez restaurer le vidage SQL sur une instance MySQL (le vidage sql provenait de la communauté MySQL 8) et ajouter les autorisations d'utilisateur et de schéma qui se trouvent dans le fichier php (conn_include.php); définir l'utilisateur pour avoir des autorisations d'exécution sur le schéma.
Si vous comparez cette base de code avec tous les cadres Web les plus populaires, cela vous ouvrira vraiment les yeux sur l'inefficacité de ces cadres. Les frameworks PHP populaires qui prétendent être des frameworks MVC ne sont pas du tout conformes MVC. En effet, ils reposent sur l'intégration de balises PHP dans des balises HTML ou vice-versa (considéré comme une très mauvaise pratique selon le W3C). De plus, les frameworks de nœuds les plus populaires exécutent beaucoup plus de code sur le client qu'il n'est nécessaire. Les balises intégrées empêchent également les appels asynchrones de fonctionner correctement, sauf si la structure prend en charge les vidages AJAX tels que Yii 2.
Deux des règles les plus importantes à suivre pour la conformité MVC sont: ne jamais intégrer de balises côté serveur (telles que les balises PHP) dans les balises HTML ou vice-versa (sauf s'il existe une très bonne excuse comme le référencement) et religieusement, n'écrivez jamais de code à exécuter sur le serveur s'il peut être exécuté sur le client. Le vrai MVC est également basé sur la séparation des niveaux, alors que les cadres MVC sont basés sur la séparation du code. La véritable conformité MVC est très efficace pour les processeurs. Ne vous méprenez pas, les frameworks MVC sont très utiles pour beaucoup de choses, mais si vous développez un site qui va obtenir des millions de visites, ils sont tout à fait inutiles, ou du moins ils feront monter vos factures cloud si haut qu'il va vraiment ronger les bénéfices de votre entreprise.
En résumé, les frameworks ne donnent pas beaucoup de contrôle sur le code qui s'exécute sur le client ou le serveur et sont très inefficaces, mais vous pouvez obtenir des prototypes en cours d'exécution plus rapidement avec moins de code.
En revanche, l'ancienne méthode prend un peu plus d'huile de coude, mais vous avez un contrôle complet sur ce qui s'exécute sur le serveur et ce qui s'exécute sur le client.
Comme conseil supplémentaire pour l'optimisation, évitez d'utiliser des requêtes directes et des déclencheurs et optez plutôt pour des procédures stockées. Historiquement, les procédures stockées n’ont pas été inventées à l’époque où MVC était présent en tant que paradigme, mais cela augmente définitivement la séparation des préoccupations entre les niveaux et est beaucoup plus efficace pour les processeurs.
J'espère que ce conseil vous aidera.