As far as minimizing the size of the reference.zip file, I have done some research to figure out next steps, and some work has already been done to fix some things. However, there are plenty of more short-term and long-term work to do.
As a quick explanation of the current bundle size: Gatsby prioritizes speed and size of loaded content over bundle size, which is great for serving over the web, but not so great if the size of the stored content matters. One example of this is that the same page content is saved in the HTML files and page-data JS files, but only one of those files will be loaded by the user depending on whether it's the initial load (HTML) or link navigation (page-data). But both are obviously contributing to the bundle size, even though some of this is de-duplicated by the zipping algorithm. On top of this comes things like responsive images, which produces 3-4 versions of each image in the final bundle, but works in the same way: Only a single image is loaded, but all of them are in the bundle. So in some way, we're going to need to fight Gatsby a bit to get the best of both worlds.
Here are some short-term things we can do:
Remove all .map files. Easy. Little effect on bundle size
Remove fake german translation pages. Easy. Large effect on bundle size (I need to check if this has already been done)
Make a separate build with responsive images disabled. More work. Medium effect on bundle size.
I did a quick test of these things:
I removed the fake German translation and .map files, and this resulted in a 60MB ZIP file. Since we don't have any translations on the site right now anyway, I think we should do this. We can then try to make the translations less heavy when we have one ready to go, but each translation is basically duplicating the site.
I did another test where I removed some of the responsive images, and I could shave further 10MB off this. I need to look more into it, but I think it will save space.
I tested zipping the site without images, which resulted in a 20MB file. This is not super good, but taking the thousands of generated files into account, not horrible either.
We might find more when we start working through these things, but the 50-60MB ZIP file seems very doable. We also need to localize some things, like not relying on the P5.js CDN version, but that's trivial. The longer term work will be going through the code with this constraint in mind and template by template looking at the file sizes and what optimizations can be done. This can save a lot of space based on the way Gatsby works, but I'm not sure how much and it'll take a bit more time.
As mentioned in https://github.com/processing/processing-website/issues/213, we need to make the
reference.zipfile smaller so people with low connection speeds can download it fairly fast. Here's what I wrote in the parent issue:As far as minimizing the size of the
reference.zipfile, I have done some research to figure out next steps, and some work has already been done to fix some things. However, there are plenty of more short-term and long-term work to do.As a quick explanation of the current bundle size: Gatsby prioritizes speed and size of loaded content over bundle size, which is great for serving over the web, but not so great if the size of the stored content matters. One example of this is that the same page content is saved in the HTML files and page-data JS files, but only one of those files will be loaded by the user depending on whether it's the initial load (HTML) or link navigation (page-data). But both are obviously contributing to the bundle size, even though some of this is de-duplicated by the zipping algorithm. On top of this comes things like responsive images, which produces 3-4 versions of each image in the final bundle, but works in the same way: Only a single image is loaded, but all of them are in the bundle. So in some way, we're going to need to fight Gatsby a bit to get the best of both worlds.
Here are some short-term things we can do:
I did a quick test of these things:
We might find more when we start working through these things, but the 50-60MB ZIP file seems very doable. We also need to localize some things, like not relying on the P5.js CDN version, but that's trivial. The longer term work will be going through the code with this constraint in mind and template by template looking at the file sizes and what optimizations can be done. This can save a lot of space based on the way Gatsby works, but I'm not sure how much and it'll take a bit more time.