How to concatenate assets together

[renoirb]

While looking at what gets generated, I see that we still have numerous assets loaded. Is there a way we could minimize the number of HTTP requests by bundling assets together.

I see that the project is using something called "webassets" in Pyramids and that its possible to bundle them up together.

[tilgovi]

production.ini does this

[tilgovi]

We could be more aggressive about it and bundle more. I'm uncertain whether that's a good idea, though.

[renoirb]

I’m running on production.ini. The run file calls production.ini instead and that’s where I saw that more than 20 javascript files are still called.

[tilgovi]

Should be only 2 from the embed. One JS. One CSS. The rest are in the iframe, which should load after the rest of the page, I think. If so, I don't know whether bundling those is good. It can decrease parallelism. On Oct 4, 2014 5:11 PM, "Renoir Boulanger" notifications@github.com wrote:

I’m running on production.ini. The run file calls production.ini instead and that’s where I saw that more than 20 javascript files are still called.

— Reply to this email directly or view it on GitHub https://github.com/webplatform/notes-server/issues/13#issuecomment-57922429 .

[tilgovi]

I'll consider bundling more aggressively in upstream h. That's the bulk of it. Nothing to do here for now. But if you want to look at the assets.yaml in h, or webassets documentation, you can minify the auth bundle in our assets.yaml here.

[renoirb]

I still need to make this happen.

[tilgovi]

You do realize this decreases parallelism and is no longer a universally recognized optimization. Have you profiled the difference? I've not done this in h yet because I have not.

Why do you think you just do this?

[renoirb]

Desired end result is to have as less as possible assets —and therefore less HTTP requests— to download for each pages that will load the annotation sidebar.

That is because every request counts. Not all web apps are fast to load. MediaWiki is already slow by itself. Once we have this available to all participating W3C specs and WebPlatform web apps, we want to be sure that the notes-server can hold the load and not slow down other parties relying on it.

Maybe i’m wrong on where I want to make the desired end result, maybe I’m describing in a wrong way, but there must be a way.

[tilgovi]

I think you are possibly wrong about the desired end result. It may be detrimental to performance.

Copying my message from the mailing list:

1) Far future cache headers.

Running with production.ini, headers are set for far future expirations, so browsers should only have to fetch these scripts the first time the sidebar loads.

2) Parallel downloads

Browsers these days make a great attempt to download scripts in parallel. Bundling prohibits that. With HTTP Keepalive and especially with SPDY (supported in recent Nginx) the amount of overhead for each requests drops a lot and the parallelism is even more useful.

3) Hash-based query string cache busting

Our asset pipeline generates query strings wherever our static assets are referenced that contain a hash of the content. If we update one dependency, the browser can use the old, cached versions of all the other ones still. With bundling, the entire application and all its dependencies get invalidated if we change one thing.

Taken together, these are enough to convince me that bundling isn't obviously a good idea, and could even be a bad idea. That's why I want to profile.

[tilgovi]

So, we can definitely do what you're asking, but you should understand that you may not want to. It is not obvious or certain that bundling the way you describe is a good idea or would result in better performance. It may even result in worse performance.

[tilgovi]

Solved upstream in hypothesis/h@f5c8d47