Improve scrolling performance

[andreiborisov]

Describe the bug
Svelte Site performance is very bad. Scrolling home page on Safari freezes rendering for 5 (!) seconds at times on a modern Mac.

To Reproduce

• Go to https://svelte.dev/ using Safari on macOS (other browsers somewhat better, but still bad).

Expected behavior
Silky smooth performance always above 60 fps.

Severity
I think this is a problem. The site is the first what people see when they try to learn about Svelte. This level of performance is immediately noticeable even for non-engineer eyes.

Additional context
Half of the appeal of Svelte is better performance. The site should demonstrate that level of performance.

[antony]

I'm pretty sure this is down to having 4 codemirror REPLs on the homepage. Without significantly decreasing the usefulness of the homepage, I think this might be a tough thing to do.

Open to ideas though.

[andreiborisov]

I’m not sure REPL is to blame, for example, here is API page (there is no REPL there) on iPhone 8:

https://share.icloud.com/photos/061yVvtTPiIPClAE6umfpIwYg

[jasonlyu123]

Maybe we can try if throttling the scroll event helps? Seen two scroll event handler in Nav and Docs component in site-kit. I can't try it because I don't see any lags on my windows/android firefox.

[Bradley-H]

I'm pretty sure this is down to having 4 codemirror REPLs on the homepage. Without significantly decreasing the usefulness of the homepage, I think this might be a tough thing to do.

Open to ideas though.

If the REPL is to blame, what I think should happen is to remove any inactive REPL. My suggestion would be any that haven't been viewed / touched for 4 months should be purged.

[laeckerv]

If the REPL is to blame, what I think should happen is to remove any inactive REPL. My suggestion would be any that haven't been viewed / touched for 4 months should be purged.

Pretty sure you misunderstood. @antony meant the REPLs showing as part of the landing page at https://svelte.dev/

I can't really confirm 5 seconds rendering freezes (Macbook Pro 2017, Safari 13.1.1). It stutters a tiny little bit reaching the contributors section, but other than that it seems smooth.

[antony]

Yes, @laeckerv is correct - there are four codemirror instances sitting on the homepage to demonstrate concepts.

It's a bit jerky for me but nothing too serious, and I expect jerkiness on a page when I see a fully interactive REPL.

We might be able to lazy-load the REPLs using IntersectionObserver when they are fully on the page, and just add a placeholder image otherwise, but it sounds like a lot of effort for something that doesn't really seem to be too much of an issue.

[andreiborisov]

@jasonlyu123 yep, some brief profiling on iPhone seems to point to scrolling events too. It seems they definitely should be throttled, especially, since there is no sidebar visible on iPhone.

On the other note, parallax scrolling on API page seems to be broken anyway, it doesn't trigger on any of my browsers, although I distinctly remember it working some time ago... What is more interesting, Sapper analogous page has parallax scrolling working and scrolls without a hitch on iPhone.

[robots4life]

https://web.dev/uses-passive-event-listeners/

What browsers are we looking at to support? I'd say give {passive: true} a shot? Otherwise as mentioned perhaps try this. https://davidwalsh.name/javascript-debounce-function

Had a look at https://svelte.dev/client/index.eea181dc.js. Would someone kindly someone give me a swift overview of what this section does?

function V(t, n) {
  "static" === getComputedStyle(t).position && (t.style.position = "relative");
  const e = document.createElement("object");
  let o;
  return (
    e.setAttribute(
      "style",
      "display: block; position: absolute; top: 0; left: 0; height: 100%; width: 100%; overflow: hidden; pointer-events: none; z-index: -1;"
    ),
    (e.type = "text/html"),
    (e.tabIndex = -1),
    (e.onload = () => {
      (o = e.contentDocument.defaultView).addEventListener("resize", n);
    }),
    /Trident/.test(navigator.userAgent)
      ? (t.appendChild(e), (e.data = "about:blank"))
      : ((e.data = "about:blank"), t.appendChild(e)),
    {
      cancel: () => {
        o && o.removeEventListener && o.removeEventListener("resize", n),
          t.removeChild(e);
      },
    }
  );
}

From what I understand this

• gets the computed styles for a static element with position relative
• creates an object element
• adds style attributes to it and those change the position among others
• and then we have an onload that checks for a viewport resize
• ensuing a userAgent check
• finally removing the listener

Is this needed and what part of the page is this for?

Additionally to make things faster the REPL CSS could be inlined in the head and async loaded before the end of body? https://www.filamentgroup.com/lab/async-css.html https://caniuse.com/#search=preload

Checked the page in BrowserStack IOS iPhone 11 Pro Safari and even there a bit of a hiccup is felt when scrolling down and coming to the REPL section. However that might also be due to BrowserStack, could not test on a real device.

[bwbroersma]

@robots4life: It's an add_resize_listener probably due to a bind:clientWidth in the ReplWidget which is used on the page, and that elementresize(?) that triggers the creation of a resize listener?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.