J'ai un travail intensif de la CPU à faire et je ne veux pas dégrader l'expérience utilisateur. Depuis que les travailleurs Web ( http://ejohn.org/blog/web-workers/ ) sont Une nouvelle fonctionnalité et ne sont pas pris en charge par tous les navigateurs, je pensais ouvrir un IFrame avec un JS HTML + qui fera tout le travail sale et en utilisant certaines communications croisées pour transmettre les résultats. Malheureusement, j'ai remarqué que le propriétaire de l'Iframe souffre du travail de la CPU de la fenêtre IFrame.
Ce comportement est-il tel que conçu? Y a-t-il un moyen de résoudre ce problème?
3 Réponses :
JavaScript est simple marre. Les onglets distincts ou les fenêtres peuvent s'exécuter dans des threads ou des processus séparés en fonction du navigateur, mais vous ne pouvez pas communiquer entre ces fenêtres, il n'est donc pas possible d'utiliser explicitement plusieurs threads ou processus en JavaScript.
S'il s'agit d'une question de réactivité de l'UI, Rushakoff a une bonne réponse. Alors que JavaScript est en cours d'exécution, aucun rendu HTML ne se produit et l'interface utilisateur n'est pas réactif. En utilisant des délais d'attente, le contrôle peut être libéré au rendu / fil de l'utilisateur périodiquement, donnant une sensation plus réactive, même si elle ne fonctionne toujours que sur un seul filetage.
> Cependant, vous ne pouvez pas communiquer entre ces fenêtres postmessage
Un moyen de définir simulez la multi-threadness serait d'avoir une fonction JavaScript pour faire un peu de travail, puis appelez entre les délais d'attente, JavaScript ne doit pas consommer de temps de processeur. Vous devrez peut-être jouer un peu pour voir combien de temps vos coups d'attente doivent être - 1ms est probablement trop court, mais 1s est vraiment trop long. Un autre facteur sera la vitesse du processeur de l'ordinateur exécutant le travail, de sorte que vous devrez peut-être faire du pseudo-benchmarking du côté du client via JavaScript avant de pouvoir déterminer combien de temps retarder chaque fois. Settimeout avec cette même fonction; Ensuite, la fonction fera un peu de travail et appelle Settimeout à nouveau et ce cycle continuera à jamais ou jusqu'à ce qu'ils ferment le cadre ou que vous signalez pour arrêter de fonctionner. MDN a un bon exemple de la manière de la configurer.
16ms est l'actualisation de l'écran, je recommande.
Au début de 2021, il y a maintenant le (bizarrement nommé) Origin-Agent-Cluster est un nouvel en-tête de réponse HTTP qui indique au navigateur d'empêcher l'accès des scripts synchronisés entre les pages d'origine croisée identique. Les navigateurs peuvent également utiliser l'agent d'origine-Agent-cluster comme indice que votre origine devrait obtenir ses propres ressources, telles qu'un processus dédié.
[...] par exemple, si Pour utiliser l'en-tête d'origine-Agent-cluster, configurez votre serveur Web pour envoyer l'en-tête de réponse HTTP suivant: Plus de détails ici: https://web.dev/origin-agent-cluster/ d'origine d'origine-agent-cluster qui vous permet de demander des ressources dédiées pour un iframe. Il est actuellement pris en charge sur Chrome (88+) avec une réception positive de Mozilla et de Safari.
https://customerservicewidget.example.com prévoit d'utiliser de nombreuses ressources pour le chat vidéo et sera intégrée à diverses origines tout au long HTTPS : //*.example.com , l'équipe qui maintient ce widget pourrait utiliser l'en-tête d'origine-Agent-Agent pour tenter de diminuer leur impact sur les performances sur les embeddeurs.
Origin-agent-cluster :? 1 la valeur du ? 1 est la syntaxe d'en-tête structurée pour une valeur réelle booléenne.