Currently npm run release already handles the tagging and releasing automatically but only increments the patch version.
It would be good to play nice with npm and have some automated way of also releasing Major and Minor versions - e.g. npm run release --major or at least npm run release-major. It could parse the version number and update it based on the release.

1.2.3-> major -> 2.0.0
1.2.3-> minor -> 1.3.0
1.2.3-> patch -> 1.2.4

Timing are rendered via an object, so the order is not guaranteed - change to array or so to keep the right order (Blocked, DNS, Connect, SSL (TLS), Send, Wait, Receive).

Also add TLS to SSL label and total

One thing I like with the current modified version we use is that we have the ability to run some super simple rules on an asset, so that we can highlight if something is wrong (like missing cache headers). It looks like this:

Hi there,

It seems like the built js has disappeared from the npm package between versions 0.2.1 and 0.2.3. Any chance of getting it back?

Thanks

@soulgalore's Initial remarks from https://github.com/sitespeedio/har/issues/1:

Been thinking a lot on what would make a good HAR viewer, here are some bullets up for discussion:

• Open Source (would be cool if it's so good that many projects use it)
• SVG (best thing I've seen is the resource waterfall if the performance bookmarklet
• Clean separation of model & view.
• Coloring: I think it would be great if all tools have the colors, so we should aim to have the same colors as WebPageTest. What's cool in WebPageTest is that you can color either by content type or have the bar split in different colors depending on timings. I personally like color by content type with the ability to switch.
• How to fit a large waterfall? One of the problems is how to show what's necessary for us to understand what asset we showing and still have some space left to show the waterfall.I'm not 100% sure there what's the best.
• In sitespeed.io we render the pages once and run them without a server, so it would be cool if we could prerender the pages that show the waterfall (meaning both functionalities to load the HAR using JS and render it in nodejs).
• The possibility to compare HAR files. WebPageTest is doing but by changing the opacity on different layers is that the way to go or are there other ways?
• One thing I like with the current modified version we use is that we have the ability to run some super simple rules on an asset, so that we can highlight if something is wrong (like missing cache headers). It looks like this:
• We should show every timing in the timings field in the HAR (also those that starts with an underscore) so we can show cool things like start render etc.

• Same as WPT
• Switch or split view for timing and content type?

We should just use the warning and redirect icon since we don't know the content type.

If there's a site that is slow, it is crowded in the end of the graph. What do you think about changing from sec to s?

The vertical bar that shows the timings is unnecessary? If we are able to always show the total time and then show the timing per type inside the extra info field, then the interface will be cleaner. And it will work the same way on both mobile and desktop.

Are you going to publish this package on npm and/or bower?

Example har with video: https://gist.github.com/soulgalore/35a80f439f8c7ea735cc522ddac09790

In the current version we miss when servers have content type like text/css; charset=UTF-8 and categorise them as others. In another project I used regex to get the type like https://github.com/sitespeedio/snufkin/blob/master/lib/util.js#L27

I can fix this tomorrow, just added it so I remember :)

I think (but this is only a suggestion) that the content type icon should be to most right just before the number. And if we have errors/redirect that icon should be displayed there too.

And then the no-gzip, no-cache (and in the future more) could be displayed to the left BUT only one. It would be like a category that you should check that PerfCascade has discovered something that probably isn't perfect.

We can also in that last column only check for content that is served without TLS if the main document has TLS and then signal that with a red open lock.

Add tslint to grunt build steps.

• https://www.npmjs.com/package/tslint
• https://www.npmjs.com/package/grunt-tslint

I think the current Github example version has been hacked so for example timings aren't correct that me and @tobli thinking something was wrong in PerfCascade. It's better to try to fins a site that will display most of our use cases.

I think it would look better if you round off the timings.

We don't have any MIME / type handling for audio and video itm.

The Fetch specs (https://fetch.spec.whatwg.org/#concept-request-destination) have a good separation, perhaps we could borrow some ideas from it.

I try to display several Cascade on the same page, they are displayed well but the opening of info window spreads to all the Cascades of the page.

• verify export as UMD works for AMD (see microsoft/TypeScript#2036)
• create standalone importable UMD module for PerfCascade to be used (without converter etc)
• public API
• Add setup object

Related to #28:
When opening more than one window the tabs of all others switch to the first since the overlays are re-drawn.

Add total time after the each bar. This is a super ugly example but hope it makes it more understandable.

Related to #28

I can make a generic function to make a name of the URL smaller. Things you want to know/see:

• HTTP/HTTPS
• domain
• the last part of the URL but make difference between base page and request parameters
• content type (depending on how what kind of view we use)

I think something broke with the last changes, I maybe can have look tonight of someone else doesn't beat me to it:

The HAR spec has onLoad an onContentLoad specified in the pageTimings element. The HAR spec is old and we know today that there are other metrics that are (more) interesting. WebPageTest adds startRender in the timings with an underscore like this:

 "pageTimings": {
          "onLoad": 557,
          "onContentLoad": -1,
          "_startRender": 449
 },

Maybe we should generate vertical lines for all keys in pageTimings, then we are open to put other timings in there and automatically get them in our HAR?

I'll look at this later on tonight.

The demo currently requires the user to upload a HAR file. How about adding a button saying “load sample data” for those who just want to get an idea of what PerfCascade looks like?

Since SVG nodes need to be added to the DOM to measure their length getNodeTextWidth takes quite a while (up to 90ms/run), particular for long text nodes it seems (they might push out the canvas).

Perhaps there is a way of reducing the need for it, e.g. by calling it on demand or measuring the shortest character (i or so) and calculate how long a text would (pessimistic) need be to fill the screen, so longer words don't need to be measured?

It'd be good to not have generated files in the git repository (see discussion in #78). This issue is to work out a solution that covers all use cases. The ones that come to mind are:

• making a release to npm
• making a GH release
• making the generated js/css files available for download (not via npm)
• updating the site with assets from the latest release
• something else ???

ping @micmro

I pushed a branch with some preliminary work.

Thanks for the great library makes implementing a HAR viewer very easy. It would be great to have the
option to export the waterfall as a SVG/PNG or other suitable object. Perhaps as an optional widget on the waterfall chart?

The HAR viewer is awesome!

Would it be possible to extend this with support for Fiddler's SAZ format? There are millions of Fiddler users out there, and SAZ files are pretty common in a number of communities. The SAZ file format is simple (it's just a ZIP file of traffic and metadata, see http://fiddler.wikidot.com/saz-files). I know there are a number of clientside JavaScript libraries that can decompress ZIPs, so it's only a matter of pulling in one of those and writing some script to parse the timers and other metadata from the XML file for each request/response pair.

Redirects (3xx), errors (client 4xx, server 5xx?) to have different row background colours.

See WPT as reference.

3xx: #ffff60
4xx: #ff6060

I think the app cache etc coming from the original resource timing waterfall, I'll go through it tonight.

A HAR file can contain multiple pages in the same file in the specification (WPT uses that when you choose to download the HAR and made more than one run if I remember correctly). We need to decide how to handle that.

Currently normalize.css and Boilerplate code is added with perf-cascade-full.css.
Create optimized version of main.css, since there is no need for reset for most (potential) users.

I don't if you have tested @micmro but we have integrated PerfCascade in sitespeed.io and with small fixes going it next release, it will look great. I've added some PRs that will make it easier to "read" the graph, hope you like them.

One thing, we turn off the icons, to much clutter (I know it was my idea from the beginning sorry). I think what could be one solution is to just have icons for content type, then each row will have one icon. I'm also in favor changing the icons (I can do that if you agree and help out a little). I think we can find some with a license that we feel are ok, I kind like those here: http://www.flaticon.com/search?word=content%20type

Today we set the width of the waterfall to the last requests but I've seen cases (especially in FF) where onload and lastVisualChange happens after that, so those metric lines aren't included in the graph. We should check the metrics we have and if they are larger than the last response time we should have that as the width (+ 500ms or something). I'll add a gist to a example HAR later.

Improve the detail box that is shown on click. Perhaps similar to WPT.

From #5

Other interesting infos (a lot of those could be highlight-flags):

• httpVersion
• headersSize
• Encoding
• bodySize
• _transferSize (perhaps as with ratio to bodySize + headersSize)
• Perhaps we can calculate to request (Cookie) and response (Set-Cookie) cookie size
• cache settings (request and response)
• Font type used (e.g. suggest woff2)

Today we have vertical lines every second. If the whole waterfall is only a couple seconds, we have space to add small vertical lines say every 200 ms, that would make it easier to spot when requests start/ends. I'm not sure how to add it and how to make the logic that only add it when the width is larger than X. It would be nice if the color is vaguer than the 1 second lines and we don't need to have any numbers below, only the lines that help guide us through.

Something like what web page test or HTTP Watch does

The viewer shows all timings that are inside the timing part inside of the HAR and that's super cool. But it's hard to see the actual number.

We could show it direct after the metric name: onContentLoaded (2.32 s) in the vertical text? Then we will also see it easy on mobile.

Got a couple of suggestions. Only suggestions :) Would be cool if we can make some of them configurable.

• The background for the waterfall graph should be white and 1-2 px gap between the bars (today they are line in line right). Think that will make the look and feel even nicer.
• The extra info layer could also be white.
• Each bar will have different colors depending on the content type. We discussed this before in another issue. I really like that because it makes it so easy to see what kind of content the page uses.
• Redirects, errors can have different background colors per row. Think we also discuss that, but could be that it is hard to implement?
• Skip the icons. Yep it was my idea but it was probably a bad idea. Thinking we could use that space to show a small version of the image if the response is an image as Firefox do.

We signal a redirect as a yellow row in the waterfall, but we shouldn't do that for 304 since it something good (Not Modified).

I noticed a problem when testing this project with http://www.tagesschau.de/ and managed to track down the issue to heuristics.ts#L58, which currently reads…

return getHeader(headers, "Cache-Control").indexOf("no-cache") > -1

…but actually should have an existence check prior to attempting to look for the "no-cache" string like so…

return getHeader(headers, "Cache-Control") && getHeader(headers, "Cache-Control").indexOf("no-cache") > -1

I tested this manually locally in my src/dist/perf-cascade.js file with success.

Today you open the extra info when you click on the row and the close it on the little x to the right. I think it would be a nice user experience if also could close if you clicked on the row and the info box is open.

Would be cool to also be able to handle zipped HAR files (http://www.softwareishard.com/blog/har-12-spec/ HAR compression), some HAR files are quite big.

Add automatic versioning to auto publish and add versions to source files.
https://github.com/vojtajina/grunt-bump

In sitespeed.io we render the pages once and run them without a server, so it would be cool if we could prerender the pages that show the waterfall (meaning both functionalities to load the HAR using JS and render it in nodejs).

The possibility to compare HAR files. WebPageTest is doing but by changing the opacity on different layers is that the way to go or are there other ways?

• @soulgalore