Need Code Splitting

core
1

Today, Workpop, is sending down over 9mb compressed to our clients. This includes mobile web and web, and our page load time in the 95% is 12 seconds. This is so unacceptable. For big apps like ours, sending JavaScript bundles that big is torture for the businesses we serve and the users we want to enjoy our experience.

Please MDG, let’s get bundle optimizations in the roadmap sooner. Cause it’s not like there aren’t alternatives! If you think code splitting and build tool enhancements over what’s already been discussed is in order, like this post

That is all.

24 Likes
2

He’s not talking about 9MB of Javascript. A big app can reach 1MB-2MB in js & css code for sure if nothing gets split up. Now add the images that will be loaded on the first route, all the saas scripts and bam you’re easily at 3-4MB with any ‘large’ app due to no code splitting. If you’d code split that you’d probably have less than 1 MB for the first route.

3

9MB of Javascript?! Dude.

1 Like
4

But images are only loaded if you visit the route, not before. And if the image size is a problem, you may need to check your compression settings.

5

I was assuming we’d get the build tool looked at during/shortly after 1.5, confirmation would be great though.

6

A hero image and a few images on i. e. a marketplace site and you have about 500-1k kb. Sure, you can lazy load stuff etc. but it just doesn’t change the fact that this means you’re loading 100% of your app on certain routes that only need 5% of your app. Anyway, back to topic. I believe if you require instead of import it loads only the code you require. Require/import both bundle the app code. However, afaik require does not load it all at once in app.js, whereas imports as of now still load it all at once in app.js.

Am I right about this @benjamn ?

7

Is this because module system?

I don’t understand how module system work. And this is also my reason I’m still on 1.2. For example, importing system:

// post.js (alone is 50kb)

import React from "react";  // 500kb
import Meteor from "meteor";  // 300kb
import RelatedPackages from "related-packages"; // 500kb
import Component from "./components"; // 100kb

How much is the size of post.js file?

Is this 50kb?
or
50 + 500 + 300 + 500 + 100 = 1.45 MB?

If 1.45 MB then it’s normal an app have size of 9MB

8

Honestly it seems more likely that we’ll eventually all move to Webpack.

9

Have you thought about replacing your images with svg?
Or loading images from CDN directly if your app is a webapp?

We have a big app too, and it’s 1.5MBs of JS, most of our images are optimized svg so add another few 100kB’s.
Frankly, lazy loading JS is overkill given the amount of local storage available, and you can manage to push your images yourself (and wouldn’t help you as most of your data is images anyway).

10

The size of post.js will just be a few bytes, but the JavaScript code you’re importing will of course be sent to the client as well. If you import from the same JavaScript file multiple times, you will only receive one copy of the imported code.

11

Nah, if it so, import is not a correct term. What I imagine, if I have 1.psd file and then I import 1.jpg (5kb) and 2.jpg (5kb) then 1.psd file will have at least 10kb. The same with if I have 2.psd file and importing 2.jpg, 3.jpg (5kb) and 4.jpg (5kb) will make the 2.psd have 15kb. 2.psd file won’t has access to 1.jpg from 1.psd because it hasn’t import 1.jpg

And if it only importing one copy, it become global to an app, no? I guess module system is the way to isolate global variable to only a file that importing stuff. And that’s why it won’t be accessed in other file

See this question in SO complaining how big webpack bundle:

12

This quite unfortunate to sacrifice file size in order to gain local variable.

13

An alternative to code splitting would be compressing your data with the brand new Pied Piper middle-out compression solution. Their jackets are ugly but there’s been more than 100,000 Pied Piper installs in 10 days.

2 Likes
14

Maybe MDG should take a look at http://rollupjs.org

1 Like
15

Meteor needs to become Build Tool independent. It’s not only code splitting but also developer experience regarding hot module replacement, building for browser extensions, Apple tvs and all the other js targets that are not browser and Cordova.

The meteor build tool is the number one reason why I decided for the last two projects not to use meteor. Despite all the “feature improvements”.

Meteor is starting to lag behind and the build tool is the main anchor holding it back even further. In the current situation I don’t see how things like service workers and http2 will ever be adopted in the near future and how a developer experience of specialized build tools could ever be achieved.

Meteor needs to get on NPM asap

1 Like