Pourquoi un simple site Web se bloque-t-il sur le mobile (iOS Safari et Chrome, au moins)?
J'ai un site Web très simple, mais très long - beaucoup de texte que l'on peut faire défiler. Il s’agit d’un site de documentation. Compte tenu de la nature du contenu (de nombreuses entrées similaires), j’ai décidé de tout afficher en même temps, afin que l’utilisateur puisse faire défiler d’une entrée à l’autre ou naviguer dans un index. C'est un modèle de documentation commun que j'aime bien (par exemple, Underscore , Backbone , et LoDash ).
Le site est ici: http://davidtheclark.github.io/scut/ . Vous pouvez consulter le code de pré-production ici: https://github.com/davidtheclark/scut/tree/master/docs/dev .
Et voici le problème: Pour un certain nombre d’utilisateurs, ce site bloque régulièrement les navigateurs iOS. Pas tous les utilisateurs (pas moi); mais pour ceux qui font l'expérience du crash, il semble se reproduire de manière constante. (Le site peut également bloquer les téléphones Android de certaines personnes, je ne sais pas. Je n'ai entendu aucun utilisateur Android.) J'espère que quelqu'un pourra m'aider à diagnostiquer et éventuellement résoudre ce problème.
Une partie de ma difficulté est que je ne peux pas reproduire le crash moi-même - pas sur mes propres appareils iOS, ni sur les simulateurs Xcode. Parce que le site n'a pas beaucoup de ressources (environ 70 Ko de charge) et implique très peu de JavaScript, et à cause des effets de quelques tentatives précédentes pour résoudre ce problème, je suppose que le problème implique l'utilisation de la mémoire - - que les navigateurs iOS se bloquent car le site exige trop de mémoire. Mais je ne suis pas sûr que ce soit le problème, et si c'est le cas, je ne suis pas sûr de pouvoir le résoudre.
Je ne suis pas sûr de ce qu'il faut essayer ensuite et j'espère que quelques astuces judicieuses de StackOverflow auront des conseils. En quoi ce site, qui semble si simple et fondamental à mes yeux, le rend-il si gourmand en mémoire qu'il bloque les navigateurs?
Est-ce juste trop long? Existe-t-il des CSS trop difficiles à restituer? Existe-t-il des fuites de mémoire JavaScript?
Je m'intéresse à la fois pour l'intérêt de ce site en particulier et pour pouvoir apprendre à anticiper et à prévenir et/ou à diagnostiquer et à résoudre des problèmes similaires sur d'autres sites à l'avenir.
N'hésitez pas à regarder ou à contribuer au [numéro de Github] ( dans ce numéro de Github } également.
Addenda
Voici quelques informations utiles sur le site qui pourraient être pertinentes:
- Le document HTML est large par rapport aux documents HTML d'autres sites. Non miné, il semble être ~ 225KB. (Je remarque que les documents LoDash sont encore plus volumineux - ce site plante-t-il les téléphones des gens?)
- Le document HTML servi est minifié.
- CSS servis et JS sont également minifiés.
- Le site utilise Prism.js pour la coloration syntaxique.
- Le site utilise Overthrow _ pour faire en sorte que la mise en page à 2 colonnes défilantes fonctionne sur les tablettes.
<aside id="help-content">est corrigé et traduit hors écran; il glisse lorsque vous cliquez sur un [?] comme celui de "nom d'utilisateur" de n'importe quel utilitaire.
Un journal de crash iOS
Celles-ci me paraissent être les lignes potentiellement pertinentes d'un rapport d'incident d'un iPhone fonctionnant sous Chrome et se plantant sur le site (je ne sais pas si elles sont réellement pertinentes ou non, car je n'ai pas développé d'applications iOS et je ne le sais pas. les tenants et aboutissants de ces rapports):
Free pages: 5674
Active pages: 117674
Inactive pages: 55121
Speculative pages: 3429
Throttled pages: 0
Purgeable pages: 0
Wired pages: 60906
File-backed pages: 23821
Anonymous pages: 152403
Compressions: 356216
Decompressions: 121241
Compressor Size: 16403
Uncompressed Pages in Compressor: 49228
Largest process: Chrome
[...]
Chrome <2a759438c2253e3baededaa0d13feb56> 166479 166479 200 [per-process-limit] (frontmost) (resume)
Je pense que je l'ai réparé!
Comme on le soupçonnait, le problème était le rendu/la peinture causé par la mise en page CSS. À la taille d'un téléphone, j'avais caché le contenu de chaque entrée jusqu'à ce qu'elle soit sélectionnée; et la méthode que j'avais utilisée pour les masquer et supprimer toute trace d'entre eux de la mise en page, inclus position: absolute. Au début, je n’utilisais pas display: none pour éviter de voir le contenu, mais de le garder là, pour différents lecteurs et raisons. J'ai jeté ces problèmes de côté et modifié la présentation de manière à ce que les entrées soient masquées avec display: none et affichées avec display: block - et cela semble avoir résolu le problème.
Je pense que le positionnement absolu accumulait une énorme quantité de contenu dans le coin de l'écran. Même s'il n'était pas visible, il exigeait de la mémoire.
Ce qui m'a permis d'essayer c'est une réponse à une autre question connexe, reliée à @tea_totaler ci-dessus: https://stackoverflow.com/a/14866503/2284669 . Ça dit:
Ce qui m'aide beaucoup, c’est de garder tout ce qui n’est pas visible à l’heure actuelle: aucun. Cela peut sembler primitif, mais fait vraiment l'affaire. C'est un moyen simple de dire au moteur de rendu du navigateur que vous n'avez pas besoin de cet élément pour le moment et libère donc de la mémoire. Cela vous permet de créer des défileurs verticaux longs avec de nombreux effets 3D à condition de masquer les éléments que vous n'utilisez pas pour le moment.
Je pense que mon autre méthode de dissimulation consistait à not libérer de la mémoire, malgré ses autres avantages (qui n’étaient peut-être pas pertinents pour ce site particulier). Je suis sûr que cela est devenu un problème uniquement parce que le site était si long.
C'est quelque chose à considérer, cependant, lorsque vous voulez masquer un élément: rendering/memory demandes.
Sur mon site, cela a été causé par des éléments avec la propriété css -webkit-backface-visibility: hidden
supprimer cette propriété a corrigé tous les plantages!
voir iOS: Divs multiples avec -webkit-backface-visibilité: navigateur crash bloqué lors du zoom
Désolé de faire juste des suppositions, mais je vois deux causes potentielles dans votre feuille de style qui pourraient provoquer un crash.
1.) Utiliser data-url pour le rendu de l’image d’arrière-plan comme ici
.github,.source {
background-image: url("data:image/svg+xml;charset=US-ASCII,%3Csvg%20width%3D%22100%22%20height%3D%22100%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Cpath%20d%3D%22M85.714%2050q0%2014.007-8.175%2025.195t-21.122%2015.485q-1.507.279-2.204-.391t-.698-1.674v-11.775q0-5.413-2.902-7.924%203.181-.335%205.72-1.004t5.246-2.176%204.52-3.711%202.958-5.859%201.144-8.398q0-6.752-4.408-11.496%202.065-5.078-.446-11.384-1.563-.502-4.52.614t-5.134%202.455l-2.121%201.339q-5.19-1.451-10.714-1.451t-10.714%201.451q-.893-.614-2.372-1.507t-4.66-2.148-4.799-.753q-2.455%206.306-.391%2011.384-4.408%204.743-4.408%2011.496%200%204.743%201.144%208.371t2.93%205.859%204.492%203.739%205.246%202.176%205.72%201.004q-2.232%202.009-2.734%205.748-1.172.558-2.511.837t-3.181.279-3.655-1.2-3.097-3.488q-1.06-1.786-2.706-2.902t-2.762-1.339l-1.116-.167q-1.172%200-1.618.251t-.279.642.502.781.725.67l.391.279q1.228.558%202.427%202.121t1.758%202.846l.558%201.283q.725%202.121%202.455%203.432t3.739%201.674%203.878.391%203.097-.195l1.283-.223q0%202.121.028%204.967t.028%203.013q0%201.004-.725%201.674t-2.232.391q-12.946-4.297-21.122-15.485t-8.175-25.195q0-11.663%205.748-21.512t15.597-15.597%2021.512-5.748%2021.512%205.748%2015.597%2015.597%205.748%2021.512z%22%2F%3E%3C%2Fsvg%3E");
background-repeat: no-repeat;
}
2.) -webkit-transition pourrait également être le coupable. Lire ici pour plus https://stackoverflow.com/a/11833285/900132
J'ai effectué un audit avec Chrome sur le site. Il a suggéré ceci:
Supprimer les règles CSS inutilisées (44)
44 règles (10%) de CSS non utilisées par la page en cours.
css-built.min.css: 10% n’est pas utilisé par la page en cours.
audio, toile, vidéo audio: pas ([contrôles]) [caché] abbr [titre] dfn hr marque q sub, sup sup sub svg: not (: root) figure fieldset Légende bouton [désactivé], entrée html [désactivé] entrée [type = case à cocher], entrée [type = radio] input [type = search] entrée [type = recherche] :: - bouton webkit-recherche-annulation, entrée [type = recherche] :: - webkit-recherche-décoration textarea table .older-docs .older-docs> li .older-docs> li: not (: last-child): après *, :avant après fieldset textarea : not (pre)> code [class * = language-], pre [class * = language-] : not (pre)> code [class * = language-] .namespace .token.regex, .token.important .token.important .older-docs .changelog dt .changelog> dt .changelog> dt: après .changelog> dd .changelog-i-list : cible> .entry-body .sub - h .example - css.is-active .preload .help-content-c .help-content-c.is-active .help-content.is-active
Le gestionnaire de tâches de Chrome indique que la page utilise environ deux fois plus de mémoire totale que d’autres sites, tels que stackoverflow et dropbox. Je recommanderais de diviser les fonctionnalités en plusieurs pages au lieu d'une longue page. En séparant les fonctionnalités, cela améliorerait l'efficacité du serveur, le temps de chargement du navigateur et l'utilisation de la mémoire. Il y aurait moins de JavaScript et de CSS en cours d'exécution sur chaque page et de plus petites quantités de données seraient envoyées du serveur. Avoir toutes les fonctionnalités sur la page d'accueil est inefficace. Par exemple, si un utilisateur avait seulement besoin de savoir comment créer une étiquette d'icône de police, il devrait charger d'autres sections de la page inutiles et utiliser de la mémoire.
Votre balise HTML contient des erreurs (telles qu'une balise div à l'intérieur d'une balise h1) qui doivent être corrigées avant d'essayer d'analyser un blocage.
Je vous suggère de l'exécuter via un validateur HTML, par exemple http://validator.w3.org/check?uri=http%3A%2F%2Fdavidtheclark.github.io%2Fscut%2F&charset=%28detect+automatically%29&doctype = En ligne & groupe = 0
La division dans h1 a apparemment provoqué une cascade d’erreurs que le validateur a dû supprimer pour continuer.
Lorsque je rencontre des problèmes de plantage du navigateur, la validation HTML est toujours ma première étape. Ensuite, j'essaie de voir ce qui pourrait ne pas être correct avec le javascript si la correction du code HTML n'a pas aidé.
Supprimer position: sticky; nous a aidée, ainsi que mon problème de plantage avec mon safari mobile. Je ne sais pas exactement pourquoi.
body:before{
position:-webkit-sticky;
position:sticky;
}
Je viens de lire ce post et j'ai essayé http://davidtheclark.github.io/scut/ sur mon iPad. Chrome se bloque immédiatement, bien que la page d'accueil s'affiche parfois brièvement. Safari rend la page d’accueil correcte et de nombreuses autres pages, mais cliquer sur le lien "à propos de" situé à gauche le fait planter immédiatement (enfin, une fois qu’il s’affiche correctement, cliquez de nouveau) Tout cela est assez cohérent.
Les erreurs sont en effet dues à LowMemory et c'est le processus du navigateur qui utilise le plus de mémoire. Les accidents se produisent aux alentours de 150000 pages (4Ko/page? => 600Mo ???).
Cela étant dit, j'ai bien peur de ne pas avoir de réponse à votre question. J'espère que ça aide au moins un peu.
Cordialement, /Sigiswald