Https:// so slow... Why?

Why does it have to be, that Python-Classic-Notebook and Jupyter-Lab on Project Jupyter | Try Jupyter takes ages to respond?

Sometimes, like during the last hours and now, neither Classic nor Lab is working. So the best a (new) user can get is a webpage, which takes ages to get ready.


Hi! Could you tell us how long “ages” is? E.g. 30s, a minute, several minutes, etc?

Hi. At the moment, I can’t measure the time, because neither “Classic” nor “Lab” is working:

At other occasions, it was “between 20 s and 90 s”… approximately. For comparison: Opening a Jupyter-Notebook (I hope, I am using the correct technical term) on Colab needs approximately 5 seconds…

I am using an internet connection download-speeds > 20 Mbit/s, so this is not the problem. And I am surprised, that you ask. Because I think, this performance problem is a persistent problem, isn’t it?

For what it’s worth, I just tried, and opened a Jupyter with R notebook in ~14 seconds.

That one screenshot tells you the problem is in that case: too many concurrent users of the backing repo. Granted the solution isn’t obvious from the error menu. That page screenshot tells you that it is the service is providing the resources. If I recall correct most default sites are limited to 100 concurrent users on the system. That general default can be specifically overridden for short times, such as giving demonstrations at JupyterCon sessions, etc., by contact ahead of time MyBinder folks are contacted. I suspect the ‘Try Jupyter’ demos have much higher limit settings, nonetheless they must have been exceeded at that time.
If you don’t specifically care what environment you start out with, you can go to here and launch any MyBinder-backed example. Hopefully, you’ll find one that isn’t currently used by too many concurrent users. If you do need the content from the Try Jupyter demos there are ways to copy the content over after launch.

You can also develop a repository somewhere and via configuration files configure it to launch with the environment you prefer as well. You may want to start with the How-to-Guides and look at examples people have made. If you overlook the postBuild file my repo here, it is otherwise a fairly simple example that can be set up on Github solely by using the browser-based interface. The requirements.txt file is specifying the packages installed there. You don’t even need a full repo to do this because Gists can work as well. This is an example. You can click the launch binder badge there or follow the directions in that README to paste the URL for one you make in the page. The page can make the launch binder badges.

If you do make a new repo or gist, or update it, upon first launch, the image backing the container needs to get built before the session can spin up and so expect some delay initially. For simple requirements.txt-based sites the build time is fairly fast these days. You want to keep your requirements small. If you try to install every package on the planet that will make the build take longer. Aside from build time when you start or edit a repo or gist, another time you may see a delay is when the system needs to make a new node because the MyBinder service is experiencing a lot of use. I’ve personally not noticed this very often lately as the management seems quite good now.

For a while, I was seeing Chrome get locked out of launches from some repos if it had a bad launch. This was usually when I was developing an environment or content. Also, I haven’t seen it in a while but the best way to test if that has happened to you, is to try another browser on the same machine. Or try the same launch route from a different computer. MyBinder can also be launched from most modern hand-held devices so sometimes you can a tablet or phone that to test where the issue is in launching.

Hopefully, knowing a little of the amazing things going on behind the curtain will give you some more options now.

Comparing a free service provided by an open source community to a mega-corporation’s paid product is not valid. Even if you don’t personally pay for Colab now, you may if you want to have better features. Or it may just be discontinued at any point, see examples here. Full disclosure / Disclaimer: Google Cloud is one of the wonderful partners that support the service.


Hi, thanks for your detailed info.

I think, it is valid to compare, though. Why not compare a self-made rocket with a Whatever-Starship to check, what feature of the self-made rocket can be improved…?

The reason for my post was: If the Jupyter-Community has a “Try in your Browser” button on its homepage: I don’t understand, why this is not working easy, fast and nicely.

Nothing else…

I mean we could possibly serve JupyterLite which does not require a server.

Could MyBinder include JupyterLite as a fallback when no server is available?

Or at least add a link to a JupyterLite deployment in the error messages, like “all our droids are busy, but you can try JupyterLite >here< (link)”


JupyterLite as a webserver error page would definitely stand out :slight_smile:

Problem is it only makes sense to direct people to JupyterLite where the desired repo is similar enough, especially since a lot of users will be directed to a particular notebook/repo by others, and won’t have much knowledge of the Jupyter ecosystem, so may be confused if we suggest JupyterLite as an alternative.

Do you have some repos in mind where providing JupyterLite as an alternative makes sense (and if so, should we recommend trying JupyterLite first ahead of something on mybinder?)

1 Like

I guess it would make most sense on the for kernels which have an in-browser equivalent (so for now basically Python, and expand as new kernels get added).

(which I understand is the biggest frustration in this thread, but could be avoided this way)

If it’s just about trying the JupyterLab and RetroLab interfaces, then JupyterLite should be more than enough. The advantage is that it indeed boots in seconds and is always available.

Another idea similar to what is being discussed here (and scattered across GitHub - jupyterlite/jupyterlite: Wasm powered Jupyter running in the browser 💡 and Twitter) would be to have a BinderLite deployment that would understand the same files as normal Binder (requirements.txt / environment.yml to start with).

Do you have some repos in mind where providing JupyterLite as an alternative makes sense (and if so, should we recommend trying JupyterLite first ahead of something on mybinder?)

The default deployment over at has a couple of example notebooks and files for:

  • simple data visualization
  • interactive widgets
  • mime renderers: json, geojson

Which is very similar to the content of JupyterLab Demo: GitHub - jupyterlab/jupyterlab-demo: Demonstrations of JupyterLab
So for these kind of demo repos maybe that would be suitable?

Still lacking interactive C++ in the browser but we’ll get there eventually!


Yep: the only way to win the on-demand-container game is to not play, by either:

  • having an (exhaustible) pool of ready-to-use containers (like the old
  • not using containers at all

Since the bad old days of jyve, I’d always hoped we’d get up to where we could give (millions of) site visitors the 80% jupyter interactive experience with the right application (from a custom voila app to full lab, and various things in between) without needing a hard-to-deploy solution. I think lite’s getting there, in a way that’s reproducible, extensible, and free.

Longer term (e.g. for ju and r): getting a no-fooling conda channel for wasm-32 would pretty much blow the doors off it, as we’d likely be able to package up any number of well-behaved kernels.


So are there any plans to improve the performance and usability of Project Jupyter | Try Jupyter ?

As mentioned above: running free-compute-as-a-service is an increasingly loss-leading activity these days, and as open source organization, we basically get as good as we are donated and or can engineer ourselves. As long as we have to fire up a cold container, it can’t really get much faster… and keeping containers warm is kinda out of scope.

As for JupyterLite, which would be (pipes willing) all-but-instantaneous when hosted for free by a big CDN: we’re buttoning up a few things which get us closer to effectively demoing JupyterLab and/or RetroLab (soon to be Notebook 7) without Docker or any reliance other than that static host.

The last few steps, of getting rid of external CDN dependencies, are a bit tricky, but I think necessary if it were to start to supplant the role of try.


Wow I just tried and am super impressed. If the JupyterLite team believes that the tech is up to the task for serving the most popular links at, I would be in favor of directing those links to use JupyterLite rather than (even if it means we need to update some of the content in those repositories, I think it would be well-worth the reduction in usage for Binder)

1 Like

Just to close this thread: now links to JupyterLite which should load instantaneously on fast Internet connection, see the announcement in JupyterLite: Jupyter ❤️ WebAssembly & Python - #4 by bollwyvl and


Performance and usability is much better now. :slight_smile:
Thanks for your update.

1 Like