为什么简单的网站会在移动设备上崩溃（至少 iOS Safari 和 Chrome）？

Why does simple website crash on mobile (iOS Safari and Chrome, at least)?

提问by davidtheclark

I have a website that is very simple, but very long -- a lot of text that could be scrolled through. It's a documentation site, and considering the nature of the content (a lot of short similar entries) I decided to show everything at once, so the user could either scroll from entry to entry or navigate via a sidebar index. It's a common documentation model that I like (e.g. Underscore, Backbone, and LoDash).

我有一个非常简单但很长的网站——很多文本可以滚动浏览。这是一个文档站点，考虑到内容的性质（很多简短的类似条目），我决定一次显示所有内容，以便用户可以从条目滚动到条目或通过侧边栏索引导航。这是一个常见的文档模型，我喜欢（如下划线，骨干，并LoDash）。

The site is here: http://davidtheclark.github.io/scut/. You could look at the pre-production code here: https://github.com/davidtheclark/scut/tree/master/docs/dev.

该网站在这里：http: //davidtheclark.github.io/scut/。您可以在此处查看预生产代码：https: //github.com/davidtheclark/scut/tree/master/docs/dev。

And here's the problem: For a number of users this site consistently crashes their iOS browsers. Not all users (not me); but for those that doexperience the crash, it seems to recur consistently. (The site may also crash some people's Android phones, I don't know: haven't heard from any Android users.) I am hoping someone can help me diagnose and possibly fix this problem.

这就是问题所在：对于许多用户来说，这个网站总是让他们的 iOS 浏览器崩溃。不是所有用户（不是我）；但对于那些确实经历过崩溃的人来说，它似乎一直在重复发生。（该网站也可能会导致某些人的 Android 手机崩溃，我不知道：还没有收到任何 Android 用户的来信。）我希望有人可以帮助我诊断并可能解决此问题。

Part of the difficulty I have is that I cannot reproduce the crash myself -- not on my own iOS devices, not on the Xcode simulators. Because the site is not at all resource-heavy (~70KB load) and involves very little JavaScript, and because of the effects of a few prior attempts to fix this, I'm guessing that the problem involves memory usage-- that iOS browsers are crashing because the site is demanding too much memory. But I'm not surethat's the issue, and if it is I'm not sure how I can fix it.

我遇到的部分困难是我自己无法重现崩溃——不是在我自己的 iOS 设备上，也不是在 Xcode 模拟器上。因为该站点根本不占用大量资源（约 70KB 负载）并且涉及的 JavaScript 很少，并且由于之前尝试解决此问题的一些影响，我猜测该问题涉及内存使用- 即 iOS 浏览器正在崩溃，因为该站点需要太多内存。但我不确定这是问题所在，如果是，我不确定如何解决。

I'm not sure what to try next, and I'm hoping some savvy StackOverflow whizzes have advice. What is it about this site, which seems so simple and basic to my eyes, that is making it so memory-demanding that it is crashing browsers?

我不确定接下来要尝试什么，我希望一些精明的 StackOverflow 高手给出建议。这个网站在我看来是如此简单和基本，它是什么使它如此需要内存以至于它使浏览器崩溃？

Is it just too long? Is there CSS that is too difficult to render? Are there JavaScript memory leaks?

是不是太长了？有没有太难渲染的 CSS？是否存在 JavaScript 内存泄漏？

I'm interested both for the sake of this particular site and so that I can learn to anticipate-and-prevent and/or diagnose-and-fix similar problems on other sites in the future.

为了这个特定站点，我很感兴趣，以便我可以学习预测和预防和/或诊断和修复将来其他站点上的类似问题。

Feel free to look at or contribute to [the Github issue](in this Github issue, as well.

随意查看或贡献 [the Github issue]（在这个 Github issue 中，以及。

Addendum

附录

Here are some things to know about the site that might be relevant:

以下是有关该网站的一些可能相关的信息：

• The HTML doc is largerelative to other sites' HTML docs. Unminified it looks to be ~225KB. (I notice that LoDash docs are even bigger -- does that site crash people's phones?)
• The served HTML doc is minified.
• Served CSS and JS are also minified.
• The site uses Prism.jsfor syntax highlighting.
• The site uses Overthrowto make the 2-scrolling-columns layout work on tablets.
• <aside id="help-content">is fixed and translated off-screen; it slides in when you click a [?] like the one by any utility's "use-name".

• 相对于其他站点的 HTML 文档，HTML 文档很大。未缩小它看起来是 ~225KB。（我注意到 LoDash 文档更大——该网站是否会使人们的手机崩溃？）
• 提供的 HTML 文档被缩小。
• 服务的 CSS 和 JS 也被缩小。
• 该站点使用Prism.js进行语法高亮显示。
• 该网站使用Overthrow使 2 滚动列布局在平板电脑上工作。
• <aside id="help-content">在屏幕外固定和翻译；当您单击任何实用程序的“使用名称”中的 [?] 时，它会滑入。

An iOS Crash Log

iOS 崩溃日志

These look to me to be the potentially relevant lines of a crash report from an iPhone running Chrome and crashing on the site (I'm not sure whether they are actually relevant or not because I haven't developed iOS apps and don't know the ins-and-outs of these reports):

这些在我看来是运行 Chrome 并在网站上崩溃的 iPhone 崩溃报告的潜在相关行（我不确定它们是否真的相关，因为我没有开发过 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)

采纳答案by davidtheclark

I think I fixed it!

我想我修好了！

The problem, as suspected, was rendering/painting caused by CSS layout. At phone-size, I had been hiding the content of each entry until it was selected; and the method I had been using to hide them, and remove any trace of them from the layout, included position: absolute. I didn't initially use display: nonebecause of typical concerns about wanting to not see content but keep it there, for various readers and reasons. I threw those concerns aside and changed the layout so that the entries were hidden with display: noneand shown with display: block-- and that seems to have fixed the crashing.

问题，正如怀疑的那样，是由 CSS 布局引起的渲染/绘制。在手机大小时，我一直在隐藏每个条目的内容，直到它被选中；以及我一直用来隐藏它们的方法，并从布局中删除它们的任何痕迹，包括position: absolute. 我最初没有使用，display: none因为出于各种读者和原因，我通常担心不想看到内容但将其保留在那里。我把这些顾虑放在一边，并改变了布局，以便将条目隐藏display: none和显示display: block——这似乎已经解决了崩溃问题。

I think the absolute positioning was stacking a huge amount of content in the corner of the screen, and although it wasn't visible, it was demanding memory.

我认为绝对定位是在屏幕的角落堆积了大量的内容，虽然它不可见，但它需要内存。

What clued me in to trying this was an answer to another related question, linked to above by @tea_totaler: https://stackoverflow.com/a/14866503/2284669. It says:

是什么让我尝试这个是另一个相关问题的答案，链接到上面@tea_totaler：https://stackoverflow.com/a/14866503/2284669 。它说：

What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.

对我有很大帮助的是将此时不可见的任何内容都显示出来：无。这听起来可能很原始，但实际上确实有效。这是告诉浏览器的渲染器您此时不需要此元素并因此释放内存的简单方法。这允许您创建具有各种 3d 效果的一英里长的垂直滚动条，只要您隐藏此时不使用的元素即可。

I think that my other hiding method was notreleasing memory, despite its other advantages (which were possibly irrelevant to this particular site anyway). I'm sure it became a problem only because the site was so long.

我认为我的其他隐藏方法没有释放内存，尽管它有其他优点（无论如何可能与这个特定站点无关）。我敢肯定这只是因为网站太长而成为一个问题。

That's something to consider, though, when you want to hide an element: rendering/memory demands.

但是，当您想隐藏元素时，这是需要考虑的：渲染/内存需求。

回答by lloiser

On my site it was caused by elements with the css property -webkit-backface-visibility: hidden

在我的网站上，它是由具有 css 属性的元素引起的 -webkit-backface-visibility: hidden

removing this property fixed all crashes!

删除此属性修复了所有崩溃！

see iOS: Multiple divs with -webkit-backface-visibility:hidden crash browser when zooming

请参阅iOS：带有 -webkit-backface-visibility 的多个 div：缩放时隐藏的崩溃浏览器

回答by anuj_io

Sorry for just making a guesses but I see two potential causes in your stylesheet which could be resulting in crash

很抱歉只是猜测，但我在您的样式表中看到了两个可能导致崩溃的潜在原因

1.) Using data-url for background image rendering such as here

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.) Also -webkit-transition could be the culprit. Read here for more https://stackoverflow.com/a/11833285/900132

2.) -webkit-transition 也可能是罪魁祸首。在这里阅读更多https://stackoverflow.com/a/11833285/900132

回答by Expanding-Dev

I ran an audit with Chrome on the site. It suggested this:

我在网站上使用 Chrome 进行了审核。它建议：

Remove unused CSS rules (44)
44 rules (10%) of CSS not used by the current page.
css-built.min.css: 10% is not used by the current page.

删除未使用的 CSS 规则 (44)
当前页面未使用的 CSS 的44 条规则 (10%)。
css-built.min.css: 10% 未被当前页面使用。

    audio, canvas, video  
    audio:not([controls])  
    [hidden]  
    abbr[title]  
    dfn  
    hr  
    mark  
    q  
    sub, sup  
    sup  
    sub  
    svg:not(:root)  
    figure  
    fieldset  
    legend  
    button[disabled], html input[disabled]  
    input[type=checkbox], input[type=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  
    .token.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  

The task manager on Chrome shows that the page takes up about 2x as much total memory than other sites, such as stackoverflow and dropbox. I would recommend dividing up the features into separate pages instead of one long page. By separating the features it would improve the server's efficiency and the browser's load time and memory usage. There would be less JavaScript and CSS running on each page and smaller amounts of data would be sent from the server. Having all the features on the home page is inefficient. For example, if a user only needed to look up how to make a Font Icon Label they would have to load other sections of the page that are not needed and take up memory.

Chrome 上的任务管理器显示该页面占用的总内存大约是其他站点（例如 stackoverflow 和 dropbox）的 2 倍。我建议将功能分成单独的页面而不是一个长页面。通过分离功能，它将提高服务器的效率以及浏览器的加载时间和内存使用率。每个页面上运行的 JavaScript 和 CSS 会更少，从服务器发送的数据量也会更少。在主页上拥有所有功能是低效的。例如，如果用户只需要查找如何制作字体图标标签，他们将不得不加载页面中不需要的其他部分并占用内存。

回答by Anachronist

Your HTML markup has some errors (such as a div tag inside an h1 tag) that should be fixed before you try to analyze a crash.

您的 HTML 标记有一些错误（例如 h1 标记内的 div 标记），应该在您尝试分析崩溃之前修复这些错误。

I suggest you run it through an HTML validator, for example http://validator.w3.org/check?uri=http%3A%2F%2Fdavidtheclark.github.io%2Fscut%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

我建议您通过 HTML 验证器运行它，例如http://validator.w3.org/check?uri=http%3A%2F%2Fdavidtheclark.github.io%2Fscut%2F&charset=%28detect+automatically%29&doctype=Inline&group =0

The div inside h1 apparently caused a cascade of errors that the validator had to suppress to continue.

h1 中的 div 显然导致了验证器必须抑制的级联错误才能继续。

When I have browser crashing problems, HTML validation is always my first step. Then I try seeing what might be wrong with the javascript if correcting the HTML didn't help.

当我遇到浏览器崩溃问题时，HTML 验证始终是我的第一步。然后，如果更正 HTML 没有帮助，我会尝试查看 javascript 可能有什么问题。

回答by Ziggy

I just read this post and tried http://davidtheclark.github.io/scut/on my iPad. Chrome crashes immediately, although sometimes shortly shows the home page. Safari renders the home page correct and many other pages, but clicking on the "about > installation" link at the left makes it crash right away (well, once it displayed OK, but clicking again crashed it). All of this is pretty consistent.

我刚刚阅读了这篇文章并在我的 iPad 上尝试了http://davidtheclark.github.io/scut/。Chrome 立即崩溃，但有时很快就会显示主页。Safari 使主页和许多其他页面正确呈现，但是单击左侧的“关于>安装”链接会使其立即崩溃（好吧，一旦显示正常，但再次单击它就会崩溃）。所有这些都非常一致。

The errors are indeed due to LowMemory and it's the browser process that uses the most memory. The crashes happen at around 150000 pages (4KB/page? => 600MB???).

错误确实是由于 LowMemory 造成的，而且它是使用最多内存的浏览器进程。崩溃发生在大约 150000 页（4KB/页？=> 600MB？？？）。

That being said, I'm afraid I don't have an answer to your question. Hope it helps at least a little bit.

话虽如此，恐怕我无法回答您的问题。希望它至少有一点帮助。

Kind regards, /Sigiswald

亲切的问候，/西吉斯瓦尔德

回答by teewuane

Removing position: sticky;helped me and my mobile safari crashing issues. Not sure exactly why.

删除position: sticky;帮助我和我的移动 safari 崩溃问题。不知道究竟是为什么。

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