Special fields for data URIs and localStorage

[Guypo]

Hi,

I think HAR 1.3 should have dedicated space for HTML-based information
sources, such as data URIs and localStorage.
These are important pieces of information when analyzing the
performance of a given page, but there's no good place to include them
right now.
We have this problem with Blaze Mobiltest (blaze.io/mobile), as we're
collecting data URIs but are not sure how to display them.

I know it goes outside the HTTP world, but frankly HAR has already
done that with pageTimings and other fields.
With HAR becoming a common way to communicate across performance
analysis tools, I think it's needed.

WDYT?

Cheers,
Guypo

[Jan Odvarko]

On Mar 15, 8:46 pm, Guypo <guy...@gmail.com> wrote:
> Hi,
>
> I think HAR 1.3 should have dedicated space for HTML-based information
> sources, such as data URIs and localStorage.
> These are important pieces of information when analyzing the
> performance of a given page, but there's no good place to include them
> right now.

It looks to me that this could be a nice adept for HAR custom fields.

> We have this problem with Blaze Mobiltest (blaze.io/mobile), as we're
> collecting data URIs but are not sure how to display them.

Can I see an example (e.g. on blaze.io) somewhere?

Honza

[Guy Podjarny]

Hi, 

I agree custom fields work, but that loses the whole "Specification" aspect :)

I can use custom fields for now, but I think the next spec should standardize how such data is stored in the HAR file, so that tools can rely on it.

For an example, check this report: http://www.blaze.io/mobile/result/?testid=110315_1417&vidid=110315_1417.1.0

If you click the "View HAR", you'll get this: http://www.softwareishard.com/har/viewer/?inputUrl=http://www.blaze.io/gethar.php%3Fharid%3D110315_1417

Cheers,

Guypo

[Jan Odvarko]

> For an example, check this report:http://www.blaze.io/mobile/result/?testid=110315_1417&vidid=110315_14...
> <http://www.blaze.io/mobile/result/?testid=110315_1417&vidid=110315_14...>If
> you click the "View HAR", you'll get this:http://www.softwareishard.com/har/viewer/?inputUrl=http://www.blaze.i...
So, the fields you are talking about are no there yet, right?
I see only:

_onRender - see how to put this one in the viewer here:
http://code.google.com/p/harviewer/wiki/API
_realBodySize - is this somehow related to localStorage?
_status

What impact data URIs and localStorage have on page load performance?

Honza

On Mar 16, 8:29 pm, Guy Podjarny <guy...@gmail.com> wrote:
> Hi,
>
> I agree custom fields work, but that loses the whole "Specification" aspect
> :)
> I can use custom fields for now, but I think the next spec should
> standardize how such data is stored in the HAR file, so that tools can rely
> on it.
>

> For an example, check this report:http://www.blaze.io/mobile/result/?testid=110315_1417&vidid=110315_14...
> <http://www.blaze.io/mobile/result/?testid=110315_1417&vidid=110315_14...>If
> you click the "View HAR", you'll get this:http://www.softwareishard.com/har/viewer/?inputUrl=http://www.blaze.i...
>
> <http://www.softwareishard.com/har/viewer/?inputUrl=http://www.blaze.i...>

[Guy Podjarny]

The custom fields are not there yet - we're debating how to display
them, and haven't decided yet. Currently we display them as requests,
which is wrong. We'll probably use custom fields for now.

Data URIs and localStorage are significant for performance
optimization. They're similar in nature to caching policies or
consolidating files, and proper use of them could significantly speed
up sites. Souders latest blog about JDrop where he analyzes (amongst
others) Google and Bing are good examples. Having those in the data
URIs as standard fields would help interop with future analysis tools
like YSlow and others.

Cheers,
Guypo

Guy Podjarny | CTO, Blaze | 613-800-0413 x102

[Pat Meenan]

FWIW, as part of the Web-Testing-Framework we're also going to have to
take a look at serializing the browser DOM and shuffling it around
(probably inside of the har container). We probably want to wait until
we flesh out the ideas before adding it to the standard but I expect
there are going to be a few different (common) things that people are
going to want to include in the payload along with the request data.

Thanks,

-Pat