4 ms·

What we need is somehow the ability to serve the html/js and json at the same time without having to wait for the client to get the html and then do the fetch r

by unlog 4y ago

What we need is somehow the ability to serve the html/js and json at the same time without having to wait for the client to get the html and then do the fetch request for that json. This will save a full round trip for loading content while keeping things simple.

yread 4y ago
I just generate the json when loading the page and embed it as script with a nonce. Of couse I lose the caching of the "static" page but it's worth it.
GordonS 4y ago
Hmm, that's an interesting idea - perhaps the browser first downloads some kind of "manifest" file, which lists the required URIs, then the browser can request them all at once?
jefftk 4y ago
I think you're asking for https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 Mozilla has it as "worth prototyping" https://mozilla.github.io/standards-positions/#http-early-hints https://mozilla.github.io/standards-positions/#http-early-hi... and their tracker entry is https://bugzilla.mozilla.org/show_bug.cgi?id=1407355 https://bugzilla.mozilla.org/show_bug.cgi?id=1407355
toast0 4y ago
If you're going to serve all the js all the time, put it inline.
- pca006132 4y ago
  It is not faster in case the js can be cached or serviced through a faster CDN comparing to your own server.
  - kastagg 4y ago
    Is it slower?
    - pca006132 4y ago
      Yes, if your website that serves the webpage is slower than those CDNs, and your website cannot be cached while those js files can be cached.
dmw_ng 4y ago
Put the HTML/CSS inside the JS, make that whole bundle cacheable, and make your "HTML" response basically be one <script> tag starting the JS and another containing the JSON response. Folk have been using this technique for a decade or more
cyral 4y ago
If you mean avoiding the dreaded loading spinner when loading a single page app, you can add the JSON data in some script within the HTML. This is what server-side rendering frameworks like Next.JS do. In it's simplest form, just include something like: <script> window.initialData = { isLoggedIn: true, email: 'example@example.com', todos: [ ... ] } </script>
riskable 4y ago
An alternative is to have a minimal HTML that has basically nothing except a <script> tag that connects to a WebSocket then have all content delivered over that. I've done testing with this in the past and it definitely outperforms HTTP/1.1 but maybe not HTTP/2 or HTTP/3 (never tested against those--this was several years ago). I even wrote a web server with bundled framework (as an academic exercise) whose whole purpose was to work like this. It was basically made for delivering any given bundles of assets over a WebSocket and had some cool features like the ability to auto-encode, auto-compress, or translate from one file type to another (say, turning a PNG into a JPEG or minifiying JS/CSS) as a simple matter of modifying the configuration.
johnny_canuck 4y ago
This sort of sounds like what 103 Early Hints aims to resolve https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103

by unlog 4y ago

yread 4y ago

I just generate the json when loading the page and embed it as script with a nonce. Of couse I lose the caching of the "static" page but it's worth it.

GordonS 4y ago

Hmm, that's an interesting idea - perhaps the browser first downloads some kind of "manifest" file, which lists the required URIs, then the browser can request them all at once?

jefftk 4y ago

I think you're asking for https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 Mozilla has it as "worth prototyping" https://mozilla.github.io/standards-positions/#http-early-hints https://mozilla.github.io/standards-positions/#http-early-hi... and their tracker entry is https://bugzilla.mozilla.org/show_bug.cgi?id=1407355 https://bugzilla.mozilla.org/show_bug.cgi?id=1407355

toast0 4y ago

If you're going to serve all the js all the time, put it inline.

pca006132 4y ago
It is not faster in case the js can be cached or serviced through a faster CDN comparing to your own server.
- kastagg 4y ago
  Is it slower?
  - pca006132 4y ago
    Yes, if your website that serves the webpage is slower than those CDNs, and your website cannot be cached while those js files can be cached.

dmw_ng 4y ago

Put the HTML/CSS inside the JS, make that whole bundle cacheable, and make your "HTML" response basically be one <script> tag starting the JS and another containing the JSON response. Folk have been using this technique for a decade or more

cyral 4y ago

If you mean avoiding the dreaded loading spinner when loading a single page app, you can add the JSON data in some script within the HTML. This is what server-side rendering frameworks like Next.JS do. In it's simplest form, just include something like: <script> window.initialData = { isLoggedIn: true, email: 'example@example.com', todos: [ ... ] } </script>

riskable 4y ago

An alternative is to have a minimal HTML that has basically nothing except a <script> tag that connects to a WebSocket then have all content delivered over that. I've done testing with this in the past and it definitely outperforms HTTP/1.1 but maybe not HTTP/2 or HTTP/3 (never tested against those--this was several years ago). I even wrote a web server with bundled framework (as an academic exercise) whose whole purpose was to work like this. It was basically made for delivering any given bundles of assets over a WebSocket and had some cool features like the ability to auto-encode, auto-compress, or translate from one file type to another (say, turning a PNG into a JPEG or minifiying JS/CSS) as a simple matter of modifying the configuration.

johnny_canuck 4y ago

This sort of sounds like what 103 Early Hints aims to resolve https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103