Debugging a iOS Safari crash "A problem repeatedly occurred"

Sometimes when visitors visit our website on their iPhone and start scrolling, Safari will show an error "A problem repeatedly occurred for ...." . When we try to reproduce the issue, nothing shows in the console log and we can't seem to find a crash report.

Is there any way to debug this issue further? When reloading the page, and doing the same action, will sometimes not result in the same error.

Tried to use developer tools via Safari on Mac. This shows nothing in the console errorwise.

Sidenote: on desktops and other mobile devices, we don't seem to have this issue.

This sounds like its caused by high GPU consumption.

Test

Open your web page in Safari, and in dev tools look for the Layers panel. This opens up a lovely interactive 3d view of the 'layers' on your page. Layers are essentially elements which require separate composition. There are many factors which can trigger this, and handily in the 3d view if you click on a layer, it'll tell you the reason for that particular layer being composited. It'll also show you the GPU used to composite that layer.

As you interact with your page, you'll see these values update in real-time. This is really useful since you can see whether interactions and animations cause significant spikes.

If you want a clearer idea of how a real device is impacted, you can plug an iPhone in to your laptop, and use remote dev tools in desktop Safari to get the same Layers view.

Common causes

• use of position: fixed/sticky CSS properties
• use of CSS 3D transform properties (e.g. translateZ, translate3d)
• use of filter CSS property
• use of will-change CSS property
• use of -webkit-overflow-scrolling CSS property
• use of backface-visibility: hidden
• animation of transform or opacity CSS properties
• iframe elements
• element overlapping another compositing layer (implicit compositing)
• element clipping a compositing descendant (implicit compositing)

See this Chromium code for a peek under the hood: https://source.chromium.org/chromium/chromium/src/+/main:third_party/WebKit/Source/platform/graphics/CompositingReasons.h;drc=a30d423812ad0d766e93b0f3a53523807b50b17b

Something that's not completely clear from the above is that content overflowing the body on the x-axis can cause GPU spikes during scroll events.

Note also that as a user scrolls, pinch-zooms (particularly), etc. your page, rapid redraws of these composited layers is required, because everything requires a re-render to remain sharp, since these layers are essentially bitmapped RGBA PNGs.

Generally speaking, the larger the dimensions of the element, the more GPU is required. Which makes sense but the interesting thing about this is that you'll likely see the issue more on larger devices and/or devices with higher-density displays, e.g. Pro/Max/Ultra models of iPhone.

How to fix

Hopefully the above will give you an idea of what causes your issue, and you can use the evidence to start mitigating the problem. Any fixes will entirely depend on your code but in general you'll be looking to remove the number of composited elements.

It's absolutely impossible to have no composited layers (the document root is one...) but if you have an abundance of large ones (e.g. full-page modals) then you'll have a good place to start.

In general you might consider the following:

• Don't render (display: none) composited elements which aren't visible. For example, techniques like simply moving elements off-screen until they're required.
• If you're using React, ensure that modals, toasts, etc. utilise a React Portal - this will put all elements in a single container, reducing implicit composition.
• If you have an abundance of elements which are inherently composited (e.g. videos, iframes) utilise some logic to reduce the number of these on page at once. For example with a video, don't render the video element until a thumbnail is clicked.
• If you use fixed positioning for elements, is there any opportunity to switch to absolute?
• If you happen to use large, semi-transparent, single-colour elements (e.g. a full-page, semi-transparent backdrop) you can create these as tiny elements, say 5×5px and scale it up using a CSS transform. The GPU requirement will be for a 5×5px bitmap rather than the full screen, e.g. something like 2556×1179px.

I've dealt with this problem myself (GPU on one of our pages was peaking at 550mb, and is now 12mb) so if you have any questions feel free to reach out via. a comment.