Dev Faq
10
votes

Qu'est-ce qui est plus rapide? AJAX Chargement JSON ou AJAX Chargement de la sortie complète

Je voulais voir différentes opinions / opinions à ce sujet.

J'ai JQuery invoquant une fonction à travers Ajax. Il charge des données de deux manières:

  1. Le script Ajax charge les données JSON du même serveur, puis utilise JS pour l'analyser et l'ajouter à HTML.

  2. Le script AJAX chargée du script complet HTML / Script Configurez directement via ce script PHP appelé puis JS l'appendez à HTML DIV.

    Je suppose que n ° 1 est plus rapide puisqu'il chargera une matrice JSON de base, utilise ensuite JS pour l'analyser et ajouter au HTML.

    opinions?

    merci!

1 commentaires

Quel type de données est-ce et quel est le ratio de données / marquage?

6 Réponses :

3
votes

Dire que l'une de ces deux solutions est plus rapide n'est pas possible: tout dépend de ce que vous faites, que ce soit sur le côté PHP ou sur le côté JS.


Ce que vous devriez considérer, principalement, c'est la difficulté de développer ces solutions - et si cela signifie dupliquer certains efforts:

  • PHP fonctionne sur votre serveur; vous contrôlez l'environnement; et ne pas avoir à adapter votre code pour chaque type de navigateur, il y a
  • Si vous affichez des objets à l'aide d'Ajax, des chances que vous souhaitiez afficher celles-ci à l'aide de non-Ajax, également, ce qui signifie que vous pourriez déjà avoir du code PHP pour rendre cela; Si tel est le cas, la duplication dans JS peut nécessiter davantage de travaux qui ne sont que réutiliser.


    Faire des choses sur votre serveur signifie:

    • Probablement un peu plus d'utilisation de réseau: l'envoi de HTML au lieu de données peut signifier une charge utile plus importante - mais en utilisant la compression, cela ne devrait pas faire une telle différence.
    • Un peu plus de charge sur votre serveur (vous pouvez mettre en cache des éléments de choses, cependant) - mais le rendu est généralement moins consommant de ressources que d'obtenir les données de votre base de données


      En fin de compte, si je peux vous indiquer à la réponse que j'ai donnée sur cette question: Pourquoi est-ce une mauvaise pratique de retourner HTML généré au lieu de JSON? Ou est-ce?

0 commentaires
1
votes

La réponse à cette question dépend de nombreux facteurs, notamment:

  • La vitesse d'ordinateur client (anciennes machines s'étouffera généralement sur une analyse et des calculs complexes JS)
  • La vitesse du réseau et la taille du contenu généré (cela s'appliquerait principalement aux grands ensembles de données qui se transforment en HTML résultant beaucoup plus grand)
  • La nature de la manipulation de données La fonction fait
2 commentaires

Généralement, sur une sortie de données de base, recommanderiez-vous simplement un rendu PHP régulier? La sortie que j'ai maintenant est très basique; Pas plus de 10 lignes de données, chaque ne pas plus de 128 caractères par valeur.

@Michael: Cela dépend vraiment. La séparation du marquage et des données est généralement une bonne idée, tant que les inconvénients ne l'emportent pas sur les avantages (voir quelques problèmes potentiels ci-dessus). À en juger par votre commentaire, vous faites quelque chose de assez trivial, alors cela ne devrait donc pas nuire à renforcer les bonnes pratiques tôt et séparer les données du balisage. Juste mon 2c :)

12
votes

Il y a beaucoup de variables. # 1 mai em> être plus rapide, à condition que votre JavaScript ne assemble pas le résultat au fragmenté et en supposant que les données soient nettement em> plus petites que le marquage équivalent. Si vous assemblez le résultat à la pièce, ou si les données ne sont pas beaucoup plus petites que le balisage, il pourrait bien être plus lent. Cela dépend également de la vitesse de la connexion réseau de l'utilisateur par rapport à la vitesse de leur processeur et de leur navigateur (chrome est assez rapide, c'est-à-dire assez lent), etc.

sur le truc par coup: par exemple, si vous chargez une table de 200 lignes et vous construisez les rangées comme ceci: p> xxx pré>

... alors cela va probablement être assez lent par rapport à la façon dont le navigateur fleurirait à travers le marquillage équivalent. p>

Si, cependant, vous le faites plus comme ceci: p> 

markup = [];
for (index = 0; index < stuff.length; ++index) {
    markup.push("<tr>");
    markup.push("<td>" + stuff[i].a + "</td>");
    markup.push("<td>" + stuff[i].b + "</td>");
    markup.push("<td>" + stuff[i].c + "</td>");
    markup.push("</tr>");
}
tableBody.append(markup.join(""));

8 commentaires

C'est une sortie de 10 lignes. Donc c'est très basique. En fait, j'avais initialement organisé la deuxième façon dont vous fournissez, mais j'ai changé en premier, pensant que c'était plus rapide. Je suppose que je devrai expérimenter; Si la différence est <100ms, alors aucun besoin de gâcher avec elle.

@Michael: S'il s'agit de 10 rangées, disons simplement qu'il devrait être un Lot de colonnes ou de structures très compliquées très compliquées impliquées pour vous remarquer une différence. :-)

Comment cela se compare-t-il à la construction de l'objet exact DOM en mémoire? Markup = $ ("

"); avec .append () à "Markup" puis appendez-vous au DOM actuel?

@Ilivel: Je suis désolé, je ne comprends pas les choses que vous me demandez de comparer.

@ T.J. - Je me demande s'il existe une différence de performance notable dans la poussée d'une chaîne dans un tableau, vs construire un objet DOM en mémoire. Je vais devoir Jsfiddle quelque chose quand je aurai du temps si vous n'avez pas testé cela.

@TJ - a fait un couple de viols. La concantatance de chaîne apparaît plus rapidement que la jQuery natif dans des objets de mémoire. A besoin de plus de tests, je pense, mais j'étais surpris. Méfiez-vous, il faut quelques secondes pour chaque exécution (des lignes de 10 000 nécessaires pour trouver une différence notable) jsfiddle.net/ iivel / j8uqu jsfiddle.net/iivel/vngfj valant sans suite une uppote!

@Ilivel: Comme je l'ai dit ci-dessus, je avait testé , il y a quelques années, et a constaté qu'il était nettement plus rapide (en particulier sur IE) pour construire la chaîne puis la remettre. Il y a en fait quatre choses à comparer, je le ferai quand j'aurai une chance: en utilisant un tableau, mais faisons un peu de cordes de cordes afin que vous ne poussez pas constamment à pousser des cordes minuscules sur le tableau; en utilisant un tableau mais ne faites jamais de cordes concessues (beaucoup de petites chaînes); Utilisation de l'API DOM, construisez les trucs dans un mode de documentation, puis l'ajoutez (pour éviter les références répétées); en utilisant l'API DOM sans fragment.

@ T.J. --- Merci pour l'entrée. J'ai exécuté un certain nombre de tests et la cordon Concat dans le tableau (à l'aide de la jointure) est définitivement le plus rapide. En tant que note, il est un peu plus rapide, mais si vous enveloppez tout dans un élément parent. Dernier violon: jsfiddle.net/iivel/rujgr

1
votes

Ma propre expérience il y a quelque temps constatée que l'utilisation de innerhtml pour de gros morceaux de HTML est significativement plus rapide que la construction avec document.Createeelement () . C'est tellement plus rapide que je ne parle même pas d'écrire des tests de vitesse. La différence de vitesse est négligeable pour les petites structures peu profondes et pour eux, je le ferai toujours avec CreeeeEeElement () mais tout ce qui est plus complexe se fait larguer en tant que chaîne.

Auparavant, j'étais assez sceptique de innerhtml , il est donc surprenant quand je me suis assis et écrit mes tests.

Je vous recommanderais de l'essayer vous-même et d'écrire vos propres tests de vitesse.

0 commentaires
1
votes

Benchmarking vous dira ce qui est le plus rapide.

0 commentaires
2
votes

Vous devez utiliser document.createDocumentFragment entraînera une meilleure performance. Ajout à ce fragment utilise uniquement la mémoire et ne modifie pas le DOM lui-même jusqu'à ce que vous soyez prêt. Je crois que le document.Createeelement est toujours supérieur à innerhtml car il contourne l'analyse des chaînes. Vous pouvez toujours exécuter un tas de référence pour voir les résultats.

Benchmark: http://jsperf.com/innertext-vs-fragment Source: https://developer.mozilla.org/en-us /docs/web/api/document.createDocumentFragment

0 commentaires

Articles qui pourrait vous intéresser :

Pourquoi est-ce que j'obtiens une erreur laravel lors de la création d'un nouveau projet?
Select2 ne s'affiche pas correctement dans le mode bootstrap
Laravel Echo n'écoute pas
La validation de la demande de formulaire ne fonctionne pas. Il charge juste la page d'accueil dans Postman