Pourquoi un simple site web plante-t-il sur un mobile (iOS Safari et Chrome, au moins)?

Je pense que j'ai corrigé!

Le problème, comme suspect, a été rendu, de la peinture causés par la mise en forme CSS. Téléphone de la taille, j'avais été cacher le contenu de chaque entrée jusqu'à ce qu'il a choisi; et la méthode que j'avais utilisé pour les cacher, et de supprimer toute trace d'eux à partir de la mise en page, inclus position: absolute. Je n'ai pas de recourir d'abord à display: none en raison de préoccupations typiques de l'envie de ne pas voir le contenu, mais le garder ilpour les différents lecteurs et des raisons. J'ai jeté ces préoccupations de côté et changé la mise en page afin que les entrées ont été cachés avec display: none et illustré avec display: block -- et qui semble avoir fixé le crash.

Je pense que le positionnement absolu est empilement d'une énorme quantité de contenu dans le coin de l'écran, et bien qu'il n'était pas visible, il était exigeant de la mémoire.

Ce clued sur moi pour essayer ceci était une réponse à une autre question, liée ci-dessus, par @tea_totaler: https://stackoverflow.com/a/14866503/2284669. Il dit:

Ce qui a tendance à beaucoup m'aider est de garder tout ce qui n'est pas visible à ce moment en vertu de display: none. Cela peut sembler primitif, mais en fait le truc. C'est une façon simple de dire le moteur de rendu du navigateur que vous n'avez pas besoin de cet élément en ce moment et donc libère de la mémoire. Cela vous permet de créer des miles le long de la verticale ascenseurs avec toutes sortes d'effets 3d aussi longtemps que vous le cacher des éléments que vous n'utilisez pas en ce moment.

Je pense que mes autres se cachant méthode a été pas la libération de la mémoire, en dépit de ses autres avantages (qui étaient peut-être pas pertinent pour ce site particulier, de toute façon). Je suis sûr que c'est devenu un problème que parce que le site a été si longtemps.

C'est quelque chose à considérer, cependant, lorsque vous souhaitez masquer un élément: rendu/demandes de mémoire.

J'ai couru un audit avec Chrome sur le site. Il a suggéré ceci:

Supprimer les règles CSS (44)

44 règlement (10%) de la CSS n'est pas utilisé par la page en cours.

css-construit.min.css: 10% n'est pas utilisé par la page en cours.

 
audio, de la toile, la vidéo 
audio:pas([commandes]) 
[caché] 
abbr[titre] 
dfn 
rh 
marque 
q 
sub, sup 
sup 
sous 
svg:not(:racine) 
la figure 
fieldset 
légende 
bouton[désactivé], d'entrée html[désactivé] 
input[type=checkbox], input[type=radio] 
input[type=search] 
input[type=search]::-webkit-recherche-annuler-bouton, input[type=search]::-webkit-recherche-décoration 
textarea 
table 
.plus-docs 
.plus-docs>li 
.plus-docs>li:not(:dernier enfant):après 
* , :: après 
fieldset 
textarea 
:pas de(pré -)>code[class*=la langue], pré[class*=la langue] 
:pas de(pré -)>code[class*=la langue] 
.espace de noms 
.jeton.regex .jeton.important 
.jeton.important 
.plus-docs 
.changelog dt 
.changelog>dt 
.changelog>dt:après 
.changelog>dd 
.changelog-i-liste 
:target>.d'entrée de corps 
.sous--h 
.exemple--css.est-active 
.la précontrainte .aide-contenu-c 
.aide-contenu-c.est-active 
.aide-le contenu.est-active 

Le gestionnaire de tâches sur Chrome indique que la page prend environ 2x comme quantité de mémoire que d'autres sites, comme stackoverflow et dropbox. Je recommande la répartition des fonctions dans des pages séparées au lieu d'une longue page. En séparant les fonctions qu'il permettrait d'améliorer le serveur de l'efficacité et le navigateur du temps de chargement et 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és à partir du serveur. En ayant toutes les caractéristiques sur la page d'accueil est inefficace. Par exemple, si un utilisateur a uniquement besoin de chercher comment faire une Icône de Police de l'Étiquette qu'ils auraient à charge d'autres sections de la page qui ne sont pas nécessaires et de prendre de la mémoire.

Votre balisage HTML a quelques erreurs (comme une balise div à l'intérieur d'une balise h1) qui doivent être corrigés avant d'essayer d'analyser un accident.

Je vous suggère de le lancer à travers un validateur HTML, par exemple http://validator.w3.org/check?uri=http%3A%2F%2Fdavidtheclark.github.io%2Fscut%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

La div à l'intérieur de h1 apparemment causé une cascade d'erreurs que le validateur a dû supprimer pour continuer.

Quand j'ai le navigateur s'écraser problèmes, la validation HTML est toujours ma première étape. Ensuite, j'essaie de voir ce qui pourrait être mal avec le javascript si la correction du HTML n'a pas aidé.

Retrait position: sticky; m'a aidé et mon mobile safari problèmes de plantage. Vous ne savez pas exactement pourquoi.

body:before{
    position:-webkit-sticky;
    position:sticky;
}