DEV Community: Christian Aysner

Interactive Screenshots with Web Bundles

Christian Aysner — Thu, 20 Aug 2020 14:49:48 +0000

What?

WARNING: This article is about technology that is highly experimental and still in development - things could change, break or never get released to the public. (20. Aug. 2020)

Screenshots are useful for giving someone a quick impression of a website or web app. Unfortunately, screenshots are not enough to communicate the feel and usability of a website.

Many things cannot be shown on screenshots, especially when it comes to interactive elements like an image gallery, a web form or animations.
One possible way out of this is to capture a video of the website, but usually that can't cover everything and you may end up with multiple videos.

But there is a solution! 🎉 Google has introduced a new technology in 2019 called "Web Bundles".

A Web Bundle stores all HTML, CSS, JavaScript and other assets in a single shareable file. This makes it possible to share a Website just like a PDF or Word document, by simply sending a file.

The website then works completely offline and is still interactive. (Interactive of course only as long as it doesn't need any data that is not included in the bundle - like search results or something like that)

It is perfect to share a website which is still under development or that no longer exists. Imagine sending a file to the customer to show him the current development status or a portfolio with interactive sites instead of screenshots.

Step 1: Install the needed software

Let's look at how we can create our first interactive screenshot. (respectively Web Bundle)
To create it, we need an application that converts HAR files into the Web Bundle format.

We will use software which is written in Go, so we have to install Go first.
Under Arch or Manjaro Linux you can type in your terminal

pacman -Ss go

When this is done, you can install the actual software with the following command:

go get -u github.com/WICG/webpackage/go/bundle/cmd/...

(Yes really with the three dots at the end)

The actual software contains the applications "dump-bundle", "gen-bundle" and "sign-bundle".

We will only need the gen-bundle application in this article.
With sign-bundle you could sign the Web Bundle and with the dump-bundle application you could check which data is included in a Web Bundle file.

Step 2: Create the HAR file

So now that we have the necessary software, next we have to tell the application which pages or data it should bundle for us.

One way to do this is to use an HAR file which contains all server requests and server responses.

This file can be easily created using the "Network" panel in the Chrome Developer Tools.

Important: Please make sure that "Disable Cache" is enabled in the Developer Tools, otherwise you may get problems with resources that are already in the browser cache.

When you have the network panel open, reload the page. You may need to scroll the page once from top to bottom to ensure that all lazy loaded files are included in the HAR file.
It makes sense to do the whole thing in the mobile view as well.

After that you can right-click on one of the server requests in the network panel and select "Save all as HAR with content".

We now have an HAR file which is usually a few megabytes large, depending on the website.

Hint: In the lower right corner of the Network panel you can see the size of all resources, this will be approximately the size of our Web Bundle.

Step 3: Generate the Web Bundle

To build our first "Web Bundle" we have to call the following command.

~/go/bin/gen-bundle -har urlaubsguru.har -o urlaubsguru.wbn -primaryURL "https://www.urlaubsguru.at/"

Important: The primaryURL parameter must match exactly the Request URL! For example, I forgot about the slash at the end and the Web Bundle file was no longer created.

Hooray! Our first Web Bundle should be ready now.

Step 4: Testing in the browser

As already explained in the beginning, Web Bundles are still highly experimental and therefore we have to activate the functionality in the Chrome browser.

Enter the following line in your Chrome browser address bar.

chrome://flags/#web-bundles

At this address you can activate the feature and then you have to restart the browser.

Tip: As soon as you change the setting, a button "Restart browser" appears, but there is another possibility to restart Chrome. One which can be useful from time to time during development. Just type chrome:restart into the address bar and the browser will restart.

Now it should be possible to open the Web Bundle file in the Chrome browser.
If the website is displayed that's fine, but that doesn't mean that everything will work offline.
Chrome will try to load resources which are not in the bundle from the original URL.
This also means that if you click on a link that is not in the bundle, the real website will open.

When you want to be sure that you have all the assets you need for the website included in the bundle, you can open the bundle after enabling the offline mode in the Chrome Developer Tools.

Save multiple pages.

Now we have our first interactive screenshot. Animations for the slider works, we can test the behavior of the input fields and we can see how the images are lazy loaded when we scroll the page down.

But we can go one step further and save several pages into one bundle. So it will be possible to go from the start page to a detail page for example.

Unfortunately, the Chrome Developer Tools sometimes cause problems with generating HAR files for multiple pages. There is the option "preserve log" but it doesn't guarantee that all request responses will be saved in the HAR file.

Therefore, I wrote a puppeteer script to fix the exported HAR file.

https://github.com/aysner/harWebBundleFixer

To export a website with multiple pages, open the chrome developer tools. Clear the content of the "Network panel", activate "Preserve log", reload the website, capture all the requests and continue that for all the subpages which you would like to have included.

Save the HAR file and then run the harWebBundleFixer. This script tries to download all requests that have no response content in the HAR file and changes 302 status codes to 200. (304 is the code for "Not Modified" and these responses would be ignored by the gen-bundle application)

The harWebBundleFixer writes a new har file to the disk, this file can now be used to create the Web Bundle.

Closing words

There is far more potential in this technology than just "interactive screenshots". In the future this could open up whole new ways of distributing websites and webapps. Maybe via USB stick or P2P network? Furthermore, websites could be pre-loaded in the background by the browser and without JavaScript running, all necessary assets would already be downloaded at the moment the user clicks on the link.

To make sure that all this works safely, Web Bundles will get the possibility to be signed by the owner of a domain. Once a Web Bundle is signed it will run under the actual context of the website - so it can access all localStorage data, cookies and so on from the original domain.

This would also be a great option for distributing web apps that are already working without a server.

References

Reading performance data with JavaScript.

Christian Aysner — Sun, 05 Jul 2020 14:12:57 +0000

How fast is my website on the user device? Did my code change have any negative effect on the page loading time?

These are questions which we can answer with the Navigation Timing API!

With this API it is possible to read various performance data via JavaScript. We can use it to get real device performance measurements from our website visitors or for quickly checking code and website changes at developing time.

We can already see the page load time in Google Analytics (Behavior > Site Speed), but to find out where we can optimize we usually need some more data.

Navigation Timing v1

The first version of Navigation Timing is a well supported solution to read out performance data. You can access it data via the performance.timing object.

console.table(performance.timing);

Output:

index	Value
navigationStart	1593164606981
unloadEventStart	0
unloadEventEnd	0
redirectStart	0
redirectEnd	0
fetchStart	1593164606987
domainLookupStart	1593164606990
domainLookupEnd	1593164607010
connectStart	1593164607010
connectEnd	1593164607249
secureConnectionStart	1593164607199
requestStart	1593164607250
responseStart	1593164607266
responseEnd	1593164607284
domLoading	1593164607296
domInteractive	1593164608387
domContentLoadedEventStart	1593164608587
domContentLoadedEventEnd	1593164608590
domComplete	1593164609302
loadEventStart	1593164609302
loadEventEnd	1593164609302

All values are in the JavaScript timestamp format. (milliseconds since January 1, 1970)

Unfortunately, this leads to the situation that we first have to do a few calculations in order to come to meaningful output.

To get something like "domComplete after 1 second" we have to subtract the navigationStart timestamp from the domComplete timestamp. Chronologically the navigationStart is the first event that gets logged.
So we can run domComplete - navigationStart and we will get 2321 as result. (1593164609302 - 1593164606981)

In other words the moment when document.readyState jumped to complete was after 2.3 seconds.

The browser support of Navigation Timing is very good, every browser except Internet Explorer 11 supports it, but v1 is outdated and will soon be replaced by Navigation Timing v2.

Navigation Timing v2

In the new version we access the data via

performance.getEntriesByType("navigation")

The values are no longer timestamps but already the milliseconds since the navigationStart event.

console.table(
    performance.getEntriesByType("navigation")[0]
);

Output:

index	Value
unloadEventStart	0
unloadEventEnd	0
domInteractive	1405.5849999999737
domContentLoadedEventStart	1606.17000000002
domContentLoadedEventEnd	1609.4399999997222
domComplete	2320.669999999609
loadEventStart	2320.7649999999376
loadEventEnd	2320.7800000000134
type	"navigate"
redirectCount	0
initiatorType	"navigation"
nextHopProtocol	"http/1.1"
workerStart	0
redirectStart	0
redirectEnd	0
fetchStart	5.5749999996805855
domainLookupStart	8.484999999836873
domainLookupEnd	29.160000000047148
connectStart	29.160000000047148
connectEnd	268.12500000005457
secureConnectionStart	217.72499999997308
requestStart	268.50500000000466
responseStart	284.6549999999297
responseEnd	302.77499999965585
transferSize	29889
encodedBodySize	29347
decodedBodySize	134069
serverTimingname	"https://example.com/"
entryType	"navigation"
startTime	0
duration	2320.7800000000134

So our example code for domComplete would change to

performance.getEntriesByType("navigation")[0].domComplete

The data we are getting back now is 2320.66999999999609, a value which is much more accurate than in v1 (at Firefox it is still rounded to 2321).

Also noticeable is that the domLoading event is no longer available, but some new informations like "redirectCount" and "nextHopProtocol" is.

Browser support is not as good here - for example in Safari we still have to work with the Navigation Timing v1.

Significant events

Event	Description
navigationStart	User has entered or accessed a URL
fetchStart	Browser is ready to load the document
domainLookupStart	IP is fetched from the DNS server
domainLookupEnd	IP was fetched from DNS serve
connectStart	Browser establishes the connection
connectEnd	Connection is established
requestStart	Browser sends the HTTP request
responseStart	Server responds
responseEnd	Server response is complete
domLoading	Browser starts document parsing (deprecated - v1 only)
domComplete	Document parsed
loadEventStart	document.onload JavaScript is executed
loadEventEnd	document.onload JavaScript has been executed

Read out interesting data

I usually use the following data to get a quick overview of the website speed

Server response (Time To First Byte)
Time needed to download the HTML file
Time until DOM interactive
Time until DOM complete
Load event start and duration

Server response time (Time To First Byte)

How long did it take the server to start sending the HTML document? With responseStart - navigationStart we can check this.
A high value can indicate a long running server process or a slow internet connection.

Time needed to download the HTML file

This value tells us how long it has taken to download the complete HTML file. For this we use repsonseEnd - repsonseStart. If the value is high there are probably problems with the internet connection or the HTML document is unusually large.

Time until DOM interactive

JavaScript can block user input. For example, when we have complex and time-consuming JavaScript in the HEAD block, this time can become correspondingly long. So the number that we get is the time that the user may already have seen something on screen but was not able to do anything on the website.

Load event start and duration

One of the most important JavaScript events is the document load event. When it is executed depends on a number of different factors.

With loadEventStart we can see when the browser was ready to start the document.onload JavaScript, but even more interesting is that with the help of loadEventStop we can calculate how long it took to complete.

So loadEventEnd - loadEventStart is the full runtime of all the JavaScript code that is added with

document.addEventListener('load', ...

Building a snippet.

We can now write a helper script which shows us all this data in the developer console.

(function() {
    let timing = performance.timing;
    let consoleOutput = '';

    let timings = {
        "Server response (TTFB)": timing.responseStart - timing.requestStart,
        "HTML download from Server": timing.responseEnd - timing.responseStart,
        "DOM interactive": timing.domInteractive - timing.navigationStart,
        "DOM complete": timing.domComplete - timing.navigationStart,
        "Load event start" : timing.loadEventStart - timing.navigationStart,
        "Load event end" : timing.loadEventEnd - timing.navigationStart,
        "Load event duration" : timing.loadEventEnd - timing.loadEventStart
    };

    for(let elementName in timings) {
        consoleOutput += (elementName + ' ').padEnd(32, '.') + ' ' + timings[elementName] + 'ms\n';
        // Note: You could also directly write it to the console or
        // print the timings array with console.table
    }

    console.log(consoleOutput);
})();

Output:

Server response (TTFB) ......... 2ms
HTML download from Server ...... 2ms
DOM interactive ................ 383ms
DOM complete ................... 1048ms
Load event start ............... 1048ms
Load event end ................. 1048ms
Load event duration ............ 0ms

This gives us a good first insight into the performance of a website.

If we want to access these values in a production environment we have to rewrite it a bit because otherwise it is possible that values like responseEnd and loadEventEnd would not be present when the code runs.

We can prevent this by inserting the code into the following function.

function measureTimings() {
    // Insert code for performance measurement here
}

if (document.readyState === "complete") {
    window.setTimeout(measureTimings, 0);
} else {
    document.addEventListener('readystatechange', () => {
        if (document.readyState === 'complete') { 
            window.setTimeout(measureTimings, 0);
        }
    }, {passive: true});
}

This code ensures that we do not access the data until all values are available. Unfortunately neither the "onload" nor the "readystatechange" event has the value of loadEventEnd set, so we have to do the trick with setTimeout. This runs the code asynchronously at a later time.

The problems at development

These data are fine, but if we call the snippet on the system where we are currently programming, we will face the problem that the server response time can be very variable. For example, if the development server takes 3 seconds longer on the first call because the cache is still empty, the load event will also be delayed by 3 seconds.

To filter that out we can switch from using navigationStart to the responseEnd event. This gives use the time passed since the HTML file was completely downloaded and should be a much more constant value - regardless of how long server side PHP/JavaScript/.Net was running.

So our array changes to

    let timings = {
        "Server response (TTFB)": timing.responseStart - timing.requestStart,
        "HTML download from Server": timing.responseEnd - timing.responseStart,
        "DOM interactive": timing.domInteractive - timing.responseEnd,
        "DOM complete": timing.domComplete - timing.responseEnd,
        "Load event start" : timing.loadEventStart - timing.responseEnd,
        "Load event end" : timing.loadEventEnd - timing.responseEnd,
        "Load event duration" : timing.loadEventEnd - timing.loadEventStart
    };

The script was very handy when I worked at Restplatzbörse. At that company we had a slightly slower development system which took different amounts of time to deliver the HTML document depending on whether the PHP cache was already warmed up and on some other factors.

Adding the snippet to the Chrome Developer Tools

To quickly access the script we can add it to the Chrome Developer Tools.
Chrome is able to save JavaScript snippets for a long time.

These snippets are an extremely powerful feature of the Developer Tools. We can access all the functions and variables that we also have in the developer console.

So a snippet like

copy($0);

would copy the HTML source of the element, wich is currently selected in the "Elements" tab, to the clipboard.

We can add our snippet under "Sources > Snippets > New snippet"

(function() {
    let timing = performance.timing;
    let consoleOutput = '';

    let timings = {
        "Server response (TTFB)": timing.responseStart - timing.requestStart,
        "HTML download from Server": timing.responseEnd - timing.responseStart,
        "DOM interactive": timing.domInteractive - timing.responseEnd,
        "DOM complete": timing.domComplete - timing.responseEnd,
        "Load event start" : timing.loadEventStart - timing.responseEnd,
        "Load event end" : timing.loadEventEnd - timing.responseEnd,
        "Load event duration" : timing.loadEventEnd - timing.loadEventStart
    };

    for(let element in timings) {
        consoleOutput += (element + ' ').padEnd(32, '.') + ' ' + timings[element] + 'ms\n';
    }

    console.log(consoleOutput);
})();

We can now access it here when needed, but even faster is pressing CTRL + P in the Chrome Developer Tools and entering a callsign. This displays a list of all snippets - no matter which tab you are currently in.

References