Reports of code editor performance degrading over time

[lasjorg]

Describe the Issue

Opening for visibility.

I have not seen this happen myself, but I also haven't spent much time in the editor.

Link to threads reporting this.

https://forum.freecodecamp.org/t/code-editors-performance-degrades-over-time/685239

Affected Page

https://www.freecodecamp.org/learn/

Steps to Reproduce

Unknown, I guess usage over time.

Expected behavior

Performance not degrading over time.

Screenshots

No response

System

• Device: [e.g. iPhone 6, Laptop]
• OS: [e.g. iOS 14, Windows 10, Ubuntu 20.04]
• Browser: [e.g. Chrome, Safari]
• Version: [e.g. 22]

Additional context

No response

[zxc-w]

I've experienced this issue multiple times. After the donation pop-up appears, the performance of the website becomes laggy. Even after refreshing the page, it returns to normal temporarily, but the lag returns once the donation pop-up reappears.

Note: the lag doesn't occur immediately after the pop-up, it becomes noticeable as you continue solving challenges, with delays in typing and overall slowness.

[ilenia-magoni]

I have not noticed this in the dev environment, even if the pop-up is present there too (python course)

[juancaorg]

I thought I was crazy or that my machine was "too old" for this, but I have experienced this too.

In my experience, it has happened after working a while on the editor or just doing a little bit of work on the editor, leaving it open, and then coming back. It becomes really slow and the only workaround that I have found is closing my browser completely and opening it again.

Note: As a current donor, the pop-up doesn't show up in my account and I don't think is related to that component itself.

[samhlking]

Commenting to add I experience this every single time I use the editor for more than maybe 20 minutes. It doesn't just happen suddenly. It starts with a slight delay then gets worse and worse.

I just opened up Incognito with no extensions enabled, and I noticed the delay after around 15 minutes. Then by 25 minutes it was definitely worse. It isn't unusable, but if you type relatively quickly it is very noticeable that words on screen are being completed maybe 100ms after you actually type them, then gets a little worse from there.

Info:
Chrome/124.0.6367.158 (no extensions)
macOS Ventura
Responsive Web Design Certification (I have had delays throughout this entire course)

[gikf]

I'm able to get the slowdown both in production and in development.

Reproducing it a bit loosely:

• Go through multiple steps (around 20?).
• At some point writing few characters in a row will start feel delayed/lagged.
• In console start appearing warnings, something like [Violation] 'input' handler took 1123ms.

Recorded performance showed then longer times of redux updates coming from (if I didn't mix up anything) the editor's onChange:

freeCodeCamp/client/src/templates/Challenges/classic/editor.tsx

Lines 867 to 895 in 4270793

	const onChange = (editorValue: string) => {
	const { updateFile, fileKey, isResetting } = props;
	if (isResetting) return;
	// TODO: now that we have getCurrentEditableRegion, should the overlays
	// follow that directly? We could subscribe to changes to that and redraw if
	// those imply that the positions have changed (i.e. if the content height
	// has changed or if content is dragged between regions)
	const coveringRange = getLinesCoveringEditableRegion();
	const editableRegionBoundaries = coveringRange
	? [coveringRange.startLineNumber - 1, coveringRange.endLineNumber + 1]
	: [];
	// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access
	if (player.current.sampler?.loaded && player.current.shouldPlay) {
	void import('tone').then(tone => {
	if (tone.context.state !== 'running') void tone.context.resume();
	// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, @typescript-eslint/no-unsafe-call
	player.current.sampler?.triggerAttack(
	editorNotes[player.current.noteIndex]
	);
	player.current.noteIndex++;
	if (player.current.noteIndex >= editorNotes.length) {
	player.current.noteIndex = 0;
	}
	});
	}
	updateFile({ fileKey, editorValue, editableRegionBoundaries });
	};

[ojeytonwilliams]

Thanks, @gikf that's really helpful!

Just so I'm on the same page: how did you record the performance and did you have campfire mode on while you were testing this? Also, did you complete and submit 20 steps or just navigate through them?

[gikf]

Hey @ojeytonwilliams!

• It was the Performance tab in the browser's developer tools. Not the profiler from react developer tools. Once I noticed the lagging, I turned on recording and did couple more steps. Then stopped recording, and tried to make heads or tails out of it 👀
• It doesn't seem to be related to campfire mode. I actually have campfire mode on in production, but when I was checking in development I believe it was off.
• Steps were completed/submitted. I haven't tried just navigating them.

[ojeytonwilliams]

It's not easy to read, but it does seem to be onChange that's taking the time, which makes sense. That's what I see even when the editor is working normally.

I've yet to see the slowdown from

• having the editor open for a long time
• typing a lot in a single page
• navigating through 80+ challenges

I'll try completing a lot of challenges next and see if I see what you saw, @gikf.

Regardless, it seems like either the amount of typing you need to do to complete a bunch of challenges OR the completion/submission process is the problem. That's my current guess.

[captain-baha]

I'm seeing the same code editor latency after about 5 to 10 minutes of usage. I see it both in Chrome and Firefox browsers when testing in Windows 11 and Linux Fedora 40. The best solution I have is to do a force cache reload of the page when it starts happening. Is the code editor overloading the cache to cause a slow down?

[hbar1st]

I'm on Windows Chrome browser and the editor is super slow for me. I type and I can't see what I've typed in till seconds later (good thing I'm a good typist) and I click Submit and it takes a long pause to respond. I tried clearing cache but it fixes the issue for maybe a couple of steps max then back to the slow performance. Definitely something I didn't experience back in early 2023 when I last used the curriculum. If there's some data I can collect to help debug, let me know. (Edit: i switched to MS Edge which I didn't use for fcc work before and the issue disappeared for the first 10 steps i tried). I may continue here for a bit before retrying chrome again at some point.) 2nd Edit: the performance improvement didn't last. Same issue occurred after a few more steps and I persisted for a couple more of these slow steps just to see if anything would change, but nothing did. So I logged off and switched back to Chrome. First few steps are back to normal performance at this point. Perhaps the pattern will repeat (and things will slow down momentarily at which point I will try another browser switch).

[huyenltnguyen]

Hi all, thank you for reporting the issue.

We are trying to reproduce the issue, but no luck yet.

From what I gather, the issue can happen:

• On any OS (so far we have reports on MacOS, Windows, and Linux)
• On any browser (so far we have reports on Chrome, Firefox, and MS Edge)
• In both incognito and normal browsing modes
• With or without browser extensions
• To both donor and non-donor users
• With both campfire mode enabled and disabled

I guess what's left is the challenge pages that you are on when you experience the issue.

I personally have tried going through 50+ Python challenges of the Building a Cipher project, and I haven't experienced the lag. We have one user experienced the issue with the Responsive Web Design challenges (#54736 (comment)), so maybe this is where I'd try next.

But we would love to get more information from everyone else: which page / course you were on when you experienced the issue.

Thanks again for reporting.

[hbar1st]

The lag happens consistently to me on the Role Playing Game project (js beta) pages. Everytime I recycle my browser the issue goes away temporarily. (Or if I close the tab on edge and reopen it)

[samhlking]

I guess what's left is the challenge pages that you are on when you experience the issue.

As I have already commented, I experienced this throughout the responsive web design cert, but I have since finished that course and moved onto the JavaScript one, and can confirm I am having the exact same issue on there.

The easiest way I've found to get rid of the delay is ⌘ + Shift + r to reload page while ignoring cache.

[gikf]

It might be needed for user to be logged in.

I've tried to reproduce it on Firefox.

• I've went from last steps of Learn HTML by Building a Cat Photo App to about 30 step of the Learn Basic CSS by Building a Cafe Menu - without being logged in, no issues.
• Then after logging in, I started at the first step of Learn Basic CSS by Building a Cafe Menu, passing code was still in browser, so was just submitting it for the most part. By the 20th step writing was again slowing down. Edit: although Firefox doesn't display warning in console.

[lasjorg]

I also see it when logged in. It literally became so bad that is spiked the CPU if I held down a key and just let it repeat.

It might somehow be related to the completion modal in the lower jaw, but I'm really not certain. That is at least also different depending on if you are signed in or not.

The problem is, it didn't seem as bad in dev mode for me, so I'm not confident. But I removed the progress component and did twice as many steps, and it didn't happen. But as said, I'm really not sure if I trust it in dev mode.

In the Performance log, looking at the bottom-up tab, completedPercentageSelector was the first one.

[ojeytonwilliams]

Thanks everyone. I've finally reproduced it by doing ~20 responsive web design lessons while signed in.

It does seem like completedPercentageSelector is part of the problem, thanks @lasjorg. I'm not sure it's the root of the problem, but it's definitely getting called far too often.

My plan is to create a quick PR to stop the unnecessary calls and/or memoize the function. Hopefully that fixes it, but we'll have to see.

[lasjorg]

@ojeytonwilliams I was briefly looking at the Progress component and saw ProgressInner

client/src/components/Progress/progress-inner.tsx

Something about that code doesn't sit right with me. The lastShopwnPercent and myInterval variable names seems a little like something that wasn't fully checked and tested.

If I just log when the component renders, it does so on every keystroke, and even just left-clicking inside the active editor section logs a re-render. This is after you have completed at least one challenge step.

Might not be related, but it doesn't seem right considering it isn't even shown. I'm a little skeptical of the Intersection observer and useEffect.

---

I know this isn't very constructive, but that's all I've got for now.

[ojeytonwilliams]

I agree about the naming, it's a little sloppy. And, yes, something is going wrong meaning that it's getting re-rendered after challenge completion.

#54925 makes it a lot better, though. It's still rendering when you start a new challenge (and it shouldn't), but it no longer renders in response to, well, everything.