URL to address in page data?

Question

We have a JavaScript widget which loads data from an URL.

To reduce round-trips I would like to avoid a second HTTP request and put the data into the HTML page.

It would be great if I could leave the JavaScript widget unchanged.

Is there a URL scheme to read data from the current HTML page?

Example: Instead of https://.... this dom://....

A big win with HTTP is heavy caching. Is this a GET which can be cached? If so, there's no need to "avoid a second HTTP request" since it will be cached by the browser and return immediately. — Clev3r, Dec 06 '15 at 19:49
Yes, you right. I like caching for ever, since validating (for example e-Tags) would do a second http-request again. Your comment was good hing. If you code the hash-sum into the URL, I could cache the data for ever. — guettli, Dec 07 '15 at 08:39

score 2 · Answer 1 · answered Nov 27 '15 at 08:26

2

No, but you can use data URIs, if that's a feasible approach for you. It's not the best choice for large amounts of data though.

answered Nov 27 '15 at 08:26

a better oliver

26,330
2
58
66

score 2 · Answer 2 · answered Nov 30 '15 at 21:33

I'm not sure to have completely caught your needs, zeroflagL answer could be a correct answer; possibly read also http://blog.teamtreehouse.com/using-data-uris-speed-website before discarding the option.

Otherwise, although it might take a little adaptation to your javascript, consider that HTML5 has a feature called data blocks read about it in https://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla:

Leveraging this feature you can reduce round-trips and put one or more dataset into the HTML page, in the case into namespaces script blocks like this:

<script id="purchase-order" type="application/xml">
<purchaseOrder xmlns="http://entities.your.own.domain/PurchaseOrderML">

or this

<script id="another-set-of-data" type="application/xml">
<dataSet xmlns="http://entities.your.own.domain/DataSetML">

therefore, your javascript can access data reading them from the current HTML page; ....example:

<script>
function runDemo() {
  var orderSource = document.getElementById("purchase-order").textContent;
  var parser = new DOMParser();
  var doc = parser.parseFromString(orderSource, "application/xml");
  var lineItems = doc.getElementsByTagNameNS("http://entities.your.own.domain/PurchaseOrderML", "lineItem");
  var firstPrice = lineItems[0].getElementsByTagNameNS("http://entities.your.own.domain/PurchaseOrderML", "price")[0].textContent;
  document.body.textContent = "The purchase order contains " + lineItems.length + " line items. The price of the first line item is " + firstPrice + ".";
}
</script>

score 1 · Accepted Answer · edited May 23 '17 at 12:07

I am also an advocate for dataURIs as they are the most transparent (client code-wise) way to implement embedding of data in webpages.

They were, however, first used to embed small images and other resources that would hamper performance due to the connection overhead and also the parallel download limitations of HTTP/1. The tradeoff is delicate since encoding data as dataURIs can cause a (ballpark estimation) of 30% increase in data size, however the critical point where dataURIs stop being helpful is around the size of small images, which are usually orders of magnitude above serialized data.

The critical point here for a single page application scenario is that there's more than the single data-fetch roundtrip to consider.

Embedding the data for use by page's scripts on otherwise static HTML has the following implications:

The HTML itself can't be cached (only with a cached copy for every different set of embedded data and every version of the page.)
The (multiple versions of the) entire page must be generated on a server that also has knowledge of how to get the data.
The inlined data might block page rendering up to a user-perceivable time (this might be worked around by embedding the data at the end of the HTML, but client script execution would probably have to wait completely, thus also making stuff like displaying a loading indicator harder to implement.)

On the other hand, keeping the data on a separate round trip, despite the round trip itself, would:

Probably keep your already working implementation as it is
Allow for clients to use the cached HTML and scripts which would only need a refresh on an actual version change (there was a failed specification called AppCache for this purpose, now superseded by the experimental Service Workers)
Allow for that HTML and scripts to be fully static assets that can be served from 'dumb' CDNs that are faster and closer to the client browser and don't need to query the database or run any server-side code

All those are big wins in my view, so I recommend you to seriously consider the need for embedding data, because it could be an early optimization that can lead to a lot of pain and an actual decrease in performance! Specially because SPDY and now HTTP/2 are already coming in to address these round-trip and connection-number issues.

score 0 · Answer 4 · answered Dec 07 '15 at 04:59

0

You could put the data, whatever it is, in the global window object, and use it later on.

But that requires you to change the code.

answered Dec 07 '15 at 04:59

Manan

929
9
11

URL to address in page data?

4 Answers4