Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate Reducing Website Build Time #2730

Open
DanielRosenwasser opened this issue Feb 28, 2023 · 3 comments
Open

Investigate Reducing Website Build Time #2730

DanielRosenwasser opened this issue Feb 28, 2023 · 3 comments

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Feb 28, 2023

One of the rough parts around onboarding (#2500) is that the site takes so long to produce an initial build. Even an incremental build feels surprisingly fast.

We need to get to the point where our website takes no longer than a minute to build, and no longer than 10 seconds for an incremental change. Ideally we could get better results, but I'm setting a reasonable bar when comparing what we have today.

Achieving this may require some compromises in what the site guarantees today, but we would like to keep around most of the features we have (e.g. sample code validation, error messages, Shiki, etc.). So we should benchmark and see where much of the work here is going, see if there's an easy way to keep these around.

We're not wedded to any specific static site generator, nor any specific approach for operating over data, so that's on the table too.

@orta
Copy link
Contributor

orta commented Feb 28, 2023

You folks are totally welcome to make the changes you want, but I'd love to know what sort of pages takes longer than 10s to see changes - those numbers for iterating are /wild/ and I'd not want to work with them either

I just loaded up my repo with #2717 up, after bootstrapping and it takes ~5s to boot the dev server via yarn start into the homepage, edits to that are instant, I changed some of the handbook markdown and the edits there were also instant. The dev server loads pages when requested, and all twoslash results are cached in node_modules which is probably making it faster for me though. It looks like a sandbox/playground change can take ~5s to be ready, so if that's the perf hit I'd recommend switching those out those two modules from using tsdx to something using esbuild/swc like tsup which should probably convert those seconds to microseconds

Building the entire site for me takes ~20s via yarn build-site. Perhaps there's a weird linux vs windows thing going on?

If you want to disable twoslash for everyone out of the box for this, you can set TWOSLASH_DISABLE somewhere on process.env and it should be that sort of performance for newbies, and then just have a documented way to get turned off?

Always happy to chat through these things!

@typescript-bot
Copy link
Collaborator

Hello! As per #2804, we are automatically closing all open issues. Please see #2804 for a description of what issues and PRs can be accepted going forward.

@clearfram3
Copy link

I keep seeing this in the iteration plans—is there a discussion somewhere that details the idea? The website seems to use an old version of Gatsby. I am interested in remaking the website in a simpler updated stack, same styles, and enhanced a11y. A different design can always be done later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants