Allow apps to inline provide inline js

[rullzer]

Right now we have some apps providing small pieces of javascript on each page load. Examples for this are the theming and accessibility. But in the future the mainly loaded js file of the firstrunwizard (nextcloud/firstrunwizard#106) will also be tiny.

In my opinion is makes most sense to inline those tiny scripts as much as possible to get the request count down. Given they are small enough of course.

I would propose a similar approach as we do with the capabilities. We provide an interface (one for JS and one for CSS). And an app can register their stuff to inline easily.

During the rendering of the templates we can then decide on a case by case basis (using some metrics) if we want to inline.

• Does the browser support CSPv3?
• Is the script/css not to big?

If not all criteria are met we can still chose to call a route that will simple server the same css/js for an app.

CC: @ChristophWurst @juliushaertl @MorrisJobke @skjnldsv

[rullzer]

I'm just not 100% sure if we can verify server side if no bad actions are happening (like faulty js). On the other hand there is nothing stopping somebody from doing that now with some script as well

[juliusknorr]

I'm just not 100% sure if we can verify server side if no bad actions are happening (like faulty js). On the other hand there is nothing stopping somebody from doing that now with some script as well

We could at least wrap it into a try/catch but there is nothing we can do about syntax errors i guess.

[rullzer]

@juliushaertl yeah that is similar to what we have today of course.

[rullzer]

First try POC https://github.com/nextcloud/server/tree/enh/13570/inline_js_css

But it fails because OCA is not defined... @juliushaertl feel free to mess with that branch

[MorrisJobke]

For the backend I would love to get something similar to #13488 (comment) does that make sense?

[MorrisJobke]

In general I see a problem here: those things can't be cached easily and causes in general higher traffic. If this is served over a unique endpoint then the caching needs to be thought of a bit to avoid it to redo all the collecting of those entries on each page load.

[rullzer]

For the backend I would love to get something similar to #13488 (comment) does that make sense?

Nope we can't in this case. Because we can only inline when CSPv3 is supported. Otherwise we have to fall back to loading it the normal way.

[rullzer]

In general I see a problem here: those things can't be cached easily and causes in general higher traffic. If this is served over a unique endpoint then the caching needs to be thought of a bit to avoid it to redo all the collecting of those entries on each page load.

Well extra loads also result in higher traffic or at least slower load times. In general I think loading the theming and accesibility scripts inline saves 3 loads on each page at minimum traffic cost.Especially compared to the rest of the page. I agree we should not load huge js files. But the tiny ones dynamic ones.

[MorrisJobke]

But then they are calculated on each access and not simply stored as result in a file anymore. Or do I miss something easy here?

[juliusknorr]

We could still just have them not inlined (so it is one request instead of 3 - firstrunwizard/theming/accessibility), but then we can have proper browser caching.

[rullzer]

But then they are calculated on each access and not simply stored as result in a file anymore. Or do I miss something easy here?

The themeing and accessibility are not stored in a file now anyway. They are calculated on the fly.

We could still just have them not inlined (so it is one request instead of 3 - firstrunwizard/theming/accessibility), but then we can have proper browser caching.

That could also work of course.

[juliusknorr]

First try POC /13570/inline_js_css@enh

Thanks, I'll have a look