It would be great
Depends on #22

Might be nice to be able to change some of the looks of the toolbar. Background colour and text colour changes for example?

Thanks!

Hello,

I'd like to contribute some code for the console proxy feature.

console = {
    justice: document.getElementById('justice'),
    lines: 0,
    writeLine: function (type, msg) {
        var line = document.createElement('div');
          
        line.classList.add('justice-console');        
        line.style.color = '#fff';
        line.style.width = '100%';
        line.textContent = this.lines + ': ' + msg;
        this.justice.appendChild(line);
        this.lines++;
    },
    log: function (msg) {
        this.writeLine('log', msg);
    },
    info: function (msg) {
        this.writeLine('info', msg);
    },
    warn: function (msg) {
        this.writeLine('warn', msg);
    },
    error: function (msg) {
        this.writeLine('error', msg);
    }
}

Maybe this is helpful, I could finish the feature by myself with a API documentation :-)

Hi,
First just want to say I really like this plugin and find it useful. It gives really easy access to important metrics.

I'm trying to investigate critical rendering and I was wondering how firstPaintTime compares to domContentLoaded and why you are using firstPaintTime and domContentComplete, but not domContentLoaded.

Does firstPaintTime actually match critical render or is just when something happens when anything starts to be painted on the screen? I've tried to find some docs on firstPaintTime but can't find anything specific and what it indicates.

On google's page regarding critical rendering time, it doesn't reference the paint time.
https://developers.google.com/web/fundamentals/performance/critical-rendering-path/measure-crp?hl=en

For example, what would be the difference between what these two indicate?

1:
((window.chrome.loadTimes().firstPaintTime * 1000) - (window.chrome.loadTimes().startLoadTime*1000)).toFixed(0);

2:
(window.performance.timing.domContentLoadedEventStart - window.performance.timing.domLoading)

Do you know which one of these would be closer to critical rendering time?

We might be able to add shims but I'm in favor of just reporting what the browser is capable of handling. Think about it.

I went to http://okor.github.io/justice/ in Safari and did not see the expected metric bar. The following errors were in the console:

[Error] TypeError: undefined is not an object (evaluating 'window.performance.timing')
    (anonymous function) (justice.min.js, line 1)
    global code (justice.min.js, line 1)
[Error] TypeError: undefined is not an object (evaluating 'Justice.init')
    global code (justice, line 93)

OS X 10.8.5
Safari 6.2.4

If browsers don't support window.performance Justice should fail gracefully.

justice inserts two divs with the id "justice-text-metrics", the demo is affected too.

👍 for the bookmarklet in your roadmap!
That would proof very handy!!

Is this project still actively maintained and developed?

• Network latency
• First paint
• various image stats
• others

Hey @okor!

I plan on doing some work on this, because we want to use it at @Lostmyname. If I send pull requests, will you deal with them? Just asking because you don't seem to have been active on github for a while :)

Alternatively, would you be willing to add me as a collaborator? I can run you through a few ideas I've had to see if you approve (mostly around ES6 and bower/npm right now).

Something like this:

<script type="text/javascript">

    $(document).on("justice:metrics", function (event, metrics) {
        console.log(metrics);
        $.ajax({
            type: "POST",
            url: "/api/metrics",
            data: JSON.stringify(metrics),
            dataType: "application/json",
            success: function (result) {
                console.log(result);
            }
        });
    });

    Justice.init({
        metrics: {
            TTFB: { budget: 200 },
            domInteractive: { budget: 250 },
            domComplete: { budget: 800 },
            firstPaint: { budget: 1000 },
            pageLoad: { budget: 2000 },
            requests: { budget: 6 },
        },
        warnThreshold: 0.8,
        showFPS: true,
        chartType: 'spline'
    });

</script>

And in seriouslyInit publish metrics:

function seriouslyInit(opts) {
        timing = window.performance.timing;
        options = mergeOptions(opts);
        setActiveMetrics(options, activeMetrics, availableMetrics);
        renderUI();
        fpsRenderer = getFpsRenderer(options.chartType);
        window.requestAnimationFrame(tick);

        var metrics = [];
        for (var k in activeMetrics) {
            var metric = activeMetrics[k];
            metrics.push({
                id: metric.id,
                label: metric.label,
                unitLabel: metric.unitLabel,
                value: metric.collector()
            });
        }

        $(document).trigger("justice:metrics", [metrics]);
    }

Accept fixed/absolute & top/bottom arguments.

It would be really nice to have a memory usage chart, much like with the FPS counter.

Google Chrome Only window.performance.memory

https://docs.webplatform.org/wiki/apis/timing/properties/memory

Light docs on usage.

does

dataFpsHistory.shift()

have to reindex the 400 length array every single time it gets called? or is this not a problem?

You can use webpack to build this as a UMD module.

It would be rad to be able to pull in RUM metrics from GA. This may be best handled by supporting custom metrics, since everyone will have different requirements.

DRY and should make theming very easy.

They are currently thoughtless but we should have good defaults.

Currently using ms everywhere, would be great to add optional s unit. Feels like this should be an option.

With limited space, this might be challenging. But it would be cool to display a simple timeline chart for various load time metrics. Might just be a 2px tall border along the top/bottom of the UI.

Goals:

• Share style variable between SCSS and JS.
• Allow theme customization

Anything that resides inside of tick() should be wicked fast. As part of the test suite we should ensure everything runs are 60ps or better.

I'd like to get some more eyes on this before the initial release. Sanity checks and the like.

Hi,

Could you add a SpeedIndex mesure ?
The visual progress may not be easy to calculate.
But it may be possible with the help of paint events.
cf https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

Regards,

npm and/or bower would be great. I want to include this but I don't want to manage getting updates manually.

Before moving a metric into the active queue, confirm the browser has the appropriate API available.

Not extreme, but some basic linting rules. Prevent build if fail.

To avoid CSS conflicts and attain superb render performance, consider using canvas everywhere.