単純なWebサイトがモバイル（少なくともiOS SafariとChrome）でクラッシュするのはなぜですか？
私は非常にシンプルですが非常に長いウェブサイトを持っています-スクロールできる多くのテキスト。これはドキュメンテーションサイトであり、コンテンツの性質（多くの短い類似エントリ）を考慮して、すべてを一度に表示することを決定しました。これにより、ユーザーはエントリからエントリへスクロールするか、サイドバーインデックスを介して移動できます。これは私が好きな一般的なドキュメントモデルです（例 nderscore 、 Backbone 、および LoDash ））。
サイトはこちらです http://davidtheclark.github.io/scut/ 。あなたはここで本番前のコードを見ることができます： https://github.com/davidtheclark/scut/tree/master/docs/dev 。
そして、これが問題です：多くのユーザーにとって、このサイトは一貫してiOSブラウザーをクラッシュさせます。すべてのユーザーではない（私ではない）;しかし、doでクラッシュが発生する場合、一貫して再発するようです。 （このサイトは、一部の人のAndroid電話、私にはわかりません：Androidユーザーから何も聞いていません。）誰かがこの問題の診断と解決に役立つことを願っています
私が抱えている問題の1つは、自分でクラッシュを再現できないことです。自分のiOSデバイスやXcodeシミュレータでは再現できません。サイトはリソースを大量に消費しておらず（約70KBの負荷）、JavaScriptはほとんど含まれていないため、これを修正するための以前の試行の影響がであるため、問題にはメモリ使用量が含まれます-サイトが要求するメモリが多すぎるため、iOSブラウザがクラッシュします。しかし、私は確信がありませんそれが問題であり、もしそうなら、どうすればそれを修正できるのかわかりません。
次に何を試したらよいかわからないので、精通したStackOverflowウィズにアドバイスがあるといいですね。私の目にはとてもシンプルで基本的に見えるこのサイトの何がそれがブラウザをクラッシュさせるほどメモリを要求しているのですか？
長すぎる？レンダリングするのが難しすぎるCSSはありますか？ JavaScriptのメモリリークはありますか？
この特定のサイトのためだけでなく、将来的に他のサイトで同様の問題を予測、防止、および/または診断および修正する方法についても知りたいです。
[Githubの問題]（ このGithubの問題 もご覧ください。
補遺
関連する可能性のあるサイトについて知っておくべきいくつかのことを次に示します。
- HTMLドキュメントは、他のサイトのHTMLドキュメントと比較してlargeです。縮小されていない場合は、約225KBになります。 （LoDashのドキュメントがさらに大きいことに気づきました-そのサイトは人々の電話をクラッシュさせますか？）
- 提供されるHTMLドキュメントは縮小されます。
- 提供されるCSSとJSも縮小されます。
- このサイトでは、構文の強調表示に Prism.js を使用しています。
- このサイトでは Overthrow を使用して、タブレットで2スクロール列のレイアウトを機能させています。
<aside id="help-content">は画面外で修正および翻訳されています。任意のユーティリティの「use-name」のような[？]をクリックするとスライドします。
IOSクラッシュログ
これらは、Chromeを実行し、サイトでクラッシュするiPhoneからのクラッシュレポートの潜在的に関連する行であるように私に見えます（私が持っていないため、それらが実際に関連しているかどうかわかりません） t iOSアプリを開発し、これらのレポートの詳細を知らない場合）：
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)
直したと思います！
疑わしい問題は、CSSレイアウトが原因のレンダリング/ペイントでした。電話サイズでは、選択されるまで各エントリのコンテンツを非表示にしていた。そして、私がそれらを非表示にし、position: absoluteを含むレイアウトからそれらの痕跡を取り除くために使用していた方法。さまざまな読者や理由により、コンテンツを表示したくないがそこに保管したいの一般的な懸念のため、最初はdisplay: noneを使用しませんでした。私はそれらの懸念を取り除き、レイアウトを変更して、エントリがdisplay: noneで非表示になり、display: blockで表示されるようにしました。これにより、クラッシュが修正されたようです。
絶対配置では画面の隅に大量のコンテンツが積み重なっていたと思いますが、表示されていませんが、メモリを要求していました。
これを試すことに私を決めたのは、@ tea_totalerによって上記にリンクされた別の関連する質問への回答でした： https://stackoverflow.com/a/14866503/2284669 。それは言う：
私を大いに助ける傾向があるのは、現時点では表示されないものは何も表示しないようにすることです。これは原始的に聞こえるかもしれませんが、実際にはトリックを行います。これは、ブラウザーのレンダラーに現時点でこの要素が必要ないことを通知し、メモリを解放する簡単な方法です。これにより、現時点で使用していない要素を非表示にしている限り、あらゆる種類の3D効果を備えた1マイルの長さの垂直スクローラーを作成できます。
私の他の隠蔽方法は、他の利点（とにかくこの特定のサイトとは無関係であった可能性があります）にもかかわらず、メモリを解放するではないであったと思います。サイトが長かっただけで問題になったと思います。
ただし、要素を非表示にする場合は、検討する必要があります。レンダリング/メモリ要求。
私のサイトでは、cssプロパティ-webkit-backface-visibility: hidden
このプロパティを削除すると、すべてのクラッシュが修正されました！
参照 iOS：-webkit-backface-visibility：hidden crash browser with multiple divs with zooming
推測しただけで申し訳ありませんが、スタイルシートに2つの潜在的な原因があり、クラッシュの原因となる可能性があります
1.）こちらのような背景画像のレンダリングにdata-urlを使用する
.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が原因である可能性もあります。詳細についてはこちらをご覧ください https://stackoverflow.com/a/11833285/900132
私はサイトでChrome=を使用して監査を実行しました。これはこれを示唆しています：
未使用のCSSルールを削除（44）
現在のページで使用されていないCSSの44ルール（10％）。
css-built.min.css：10％は現在のページで使用されていません。
オーディオ、キャンバス、ビデオ audio：not（[controls]） [hidden] abbr [title] dfn hr mark q sub、sup sup sub svg：not（：root ） 図 フィールドセット 凡例 ボタン[無効]、html入力[無効] 入力[タイプ=チェックボックス]、入力[タイプ= radio] input [type = search] input [type = search] ::-webkit-search-cancel-button、input [type = search] ::-webkit-search-decoration textarea table .older-docs .older-docs> li .older-docs> li：not（：last-child） ：after *、：before、：after fieldset textarea ：not（pre）> code [class * = language-]、pre [class * = language-] ：not（pre）> code [class * = language-] .namespace .token.regex、.token.important 。 t oken.important .older-docs .changelog dt .changelog> dt .changelog> dt：after .changelog> dd .changelog-i-list ：target> .entry-body .sub--h .example--css.is-active .preload .help-content-c .help-content-c.is-active .help-content.is-active
Chrome=のタスクマネージャーは、ページが他のサイト（stackoverflowやdropboxなど）の約2倍のメモリを占めることを示しています。機能を1つの長いページではなく別々のページに分割することをお勧めしますページ。機能を分離することで、サーバーの効率とブラウザの読み込み時間とメモリ使用量が向上します。各ページで実行されるJavaScriptとCSSが少なくなり、サーバーから送信されるデータの量が少なくなります。すべての機能をたとえば、ユーザーがフォントアイコンラベルの作成方法を調べるだけでよい場合は、ページの他の不要なセクションを読み込んでメモリを占有する必要があります。
HTMLマークアップにいくつかのエラー（h1タグ内のdivタグなど）があり、クラッシュを分析する前に修正する必要があります。
H1内のdivは、バリデーターが続行するために抑制しなければならないエラーのカスケードを引き起こしたようです。
ブラウザがクラッシュする問題が発生した場合、常にHTML検証が最初のステップです。次に、HTMLを修正しても問題が解決しない場合は、JavaScriptの何が問題なのかを確認してみます。
position: sticky;を削除すると、モバイルサファリのクラッシュの問題が解決しました。正確な理由はわかりません。
body:before{
position:-webkit-sticky;
position:sticky;
}
私はこの投稿を読んで、iPadで http://davidtheclark.github.io/scut/ を試しました。 Chromeすぐにクラッシュしますが、すぐにホームページが表示されることがあります。Safariはホームページを正しくレンダリングし、他の多くのページを表示しますが、左側にある[バージョン情報]> [インストール]リンクをクリックすると、すぐにクラッシュします（まあ、OKと表示された後、もう一度クリックするとクラッシュしました。）これらはすべて、かなり一貫しています。
エラーは確かにLowMemoryによるものであり、最も多くのメモリを使用しているのはブラウザプロセスです。クラッシュは約150000ページで発生します（4KB /ページ？=> 600MB ???）。
そうは言っても、私はあなたの質問に対する答えがありません。それが少なくとも少し役立つことを願っています。
よろしく、/ Sigiswald