GitHub "Sign up" page is way too slow

[carbon-twelve]

Select Topic Area

Bug

Body

Join GitHub · GitHub is way too slow.
I typed my email address, and then it took a couple of seconds for those letters to be shown.
Admitting that my computer is something below the high-end, but a sign up page should not require so much resource generally.

Browser: Firefox 107.0
OS: Windows 11 Home
CPU: Intel Core i5-12600K
Memory: 32GB DDR4
GPU: NVIDIA GeForce RTX 3060 Ti

[dantliff-sqc]

Same issue here with Firefox 123.0 on Ubuntu 22.04. INCREDIBLY slow. Almost impossible to navigate, but I got through it eventually.

[antler5]

I haven't checked to see if the current page is the same design that was being commented on in Late 2022, but @dantliff-sqc and I are both here these week because the performance of the current Sign-Up flow is unusually slow on FireFo. To be clear, I think the design is gorgeous and that great work was done implementing it in every other regard -- I'm not here to demean any team's work.

For context, I have a great deal of experience implementing a static field of twinkling stars on my personal site. I didn't want to use Javascript, and when naively translating CSS masks around made the fans on my old Core i3 Dell Latitude scream, I went through at least a half dozen more approaches ranging from optimized CSS animation layers with only simple property animations, to B/W JPEG Sprite-Sheets containing both the stars and several "frames" of masks to lay on top, to embedding SMIL animations in an externally loaded SVG to reduce the number DOM elements (interested readers: refer to O'Reilly).

I don't claim to be any sort of expert about what's going on under the hood, nor that anyone should share the performance expectations I was exercising at the time, but the performance profile of the current Github Sign-in flow is (by my estimation) at least two orders of magnitude slower, in the more favorable of either frame-rate or response latency, then any performance I observed in my adventure. It brings my ol' Latitude to a crawl, but is still intractable. My "Other Laptop" is an XPS 13 with a 4K Screen, and scaling that effect up to cover 10x the pixel-area is another order of magnitude worse. The mouse cursor begins to skip 1-2 inches per frame, each of which (I'd say, just eye-balling) is at least 300ms apart (3.3fps).

If I learned just three things from my personal excursion with twinkling star performance, they'd be:
a.) This would have been easier with Javascript. I didn't use it because I'm a NoScript user, but that's what any example of performant complex animation was doing when I (as some kinda "into this") saw something interesting in the wild and looked under the hood.
b.) Avoid re-flows. I think we know this one.
c.) Avoid re-paints. If I open the GH Sign-up page in FireFox on my Latitude or XPS and profile it, I can see that Paints are taking up 47-49% of the sampling time, plus a consistent 20% under Styles (computation, interactions, and rendering updates). There's your problem.

I haven't dug in too deep with the inspector because it hurts to have open, but I see you've set up a clever zooming and rotating cascade of layers with a very nice seamless loop. Like I said, I'm not here to dunk and I think this is very nice work in other respects. I did something similar at one point, splitting stars into about the same number of groups and putting their opacity animations on different offsets, but once again, without Javascript and with very careful curation of which properties to animate. I did not find the performance adequate, but would not be writing this if GH was at the same level.

I can infer from the pixel scaling performance that you're using SVG. That's going to be a factor as long as you're doing so, but shouldn't be a deal-breaker at standard zoom levels. In terms of solutions, I'd suggest ensuring that star groups are on separate compositing layers and that animations are only acting on those layers as units through will-change attributes for stuff the JS is gonna touch and careful attribute selection / tag structure (lord help you if this is already the case). You may follow my example by moving the animation into SMIL, pre-calculating attribute key-frames if necessary, reducing the number of elements in the DOM and (AFAIK) helping the browser separate the image layers from the rest of the render pipeline. You could try rendering the star layers from a B/W JPEG Spritesheet, cropping each layer to it's "frame" and masking it with itself via mask-type: luminance; (and poly-fill equivalents). You could seek examples of similar effects utilizing JS in the wild and examine their performance and methodologies. But if this has been the case since Late 2022, that's unfortunate, and it should at least be put behind in opt-in toggle to ensure basic functionality on devices with low processing power and/or high pixel densities.

Sorry if this came off as harsh at all, this is just an area I've personally invested a lot of time digging into. Wish I had a job working on stuff like this. I really do think it's pretty, and clever, and am hoping that my personal accounts can clarify the problem and aid in the discussion, location, and selection of a resolution.

I'm not including a profile export or anything because this seems to be occurring widely, but can on the off-chance we're just affected by a really niche bug. At the end of the day I think it's really a browser issue, because only seems to by Firefox and shouldn't have to be like this. anyway, thx.