npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

wpt-reporter

v0.0.1

Published

A thin wrapper for the WebPageTest API that report specific metrics as csv/json or send them to Graphite/Statsv

Downloads

3

Readme

wpt-reporter

Collect browser metrics using WebPageTest and choose how to report it. We wrap the functionality of the https://github.com/marcelduran/webpagetest-api and collect the most important metrics from the (giant) result JSON and report it as/to CSV/JSON/Graphite/statsv.

Install

Run

To be able to use it you need to either have an API key to the public WebPageTest instance (you can get one here) or setup your own instance (follow our instructions here on how to setup your own instance at AWS).

When you have the key or your own instance and cloned/installed this repository, you are ready to go.

You can check all configuration with help:

All parameters will also be passed on to the webpagetest-api so if you want to configure a specific WebPageTest configuration that isn't included in the help section, check out the runTest method and add that to the parameter list.

Choose server and location

When you run a test you need configure which WebPageTest server to use (default one is http://www.webpagetest.org) and a location (for WebPageTest.org it uses Dulles:Chrome but you can change that to one of the available in http://www.webpagetest.org/getLocations.php).

If you run your own WebPageTest server make sure to also change the location. You change server and location with the parameters webPageTestHost and location.

The keys/name of the metrics

If you send the data to Graphite/statsv, the key names will be generated like this: namespace.location.browser.view.metric

Lets go through it:

  • namespace is the start of the key default is webpagetest but you can change that with the parameter --namespace when you run the script.
  • location is the location of your agent, this will be picked up automatically from your configuration.
  • browser is the browser type in WebPageTest. If we emulate a mobile browser, the name will have -emaulatedMobile appended to the name. If the name isn't configured in WebPageTest, the full location string is used.
  • view is the firstView or repeatView.
  • metrics is the actual metric that's picked up

A key look something like this webpagetest.us-west-1.chrome.firstView.SpeedIndex

Note: If you test your pages with different connectivities or in other ways want to sepaprate the keys, just add an part of your key with the namespace like: --namespace webpagetest.cable

Choose what metrics to collect

Default these metrics are collected:

You can override the timing metrics by supplying the --metrics parameter with a comma separated list of metrics to collect. They will be fetched from the median run from the JSON namespace of data.median.firstView.METRIC and data.median.repeatView.METRIC.

How report the metrics

You can choose how to report the metrics collected by setting the reporter.

CSV

Why should you use CSV? It's nice in way if you want to test a couple URLs and compare the result. You can choose where CSV data will be stored with the file option. If the file doesn't exist, it will add one line with all the column names of the metrics. If the file exists, it will just append the new metrics on a new line.

JSON

The JSON reporter is a nice way to just check metrics for a run. Use it like this:

Graphite

Do you want to graph your data? Do that by storing the metrics in Graphite. To do that you need to have Graphite up and running (hint: use a Docker container including Graphite, that's much easier than installing it yourself).

When you run you add your configuration to the Graphite host and port:

statsv

Statsv what we use at Wikimedia to get metrics to Graphite, via statsd, over HTTP. You can read more about how we use it together with WebPageTest.

Environment variables and scripting

If you feed the script with a batch file containing multiple runs or if you use WebPageTest script language, keys will automatically be replaced with environment variables. The keys need to be of the format <%KEY_NAME>.

If we have the variable <%WMF_WPT_KEY> in our script, it will be replaced by the environment variable named WMF_WPT_KEY. Running in node, the value will be replaced with process.env.WMF_WPT_KEY. If the environment variable is missing from the file, you will notice that in the console log.

How can you use that? One example is that you can make generic login script and parametrize the URL you want to test like this:

Here you set the login name (<%WPT_USER>) the password <%WPT_USER_PASSWORD> and the URL to test (<%WPT_MOBILE_URL>) as variables.

Want to know more?

You can find more info about how we use WebPageTest at Wikitech.

This is a Github mirror of "performance/WebPageTest" - our actual code is hosted with Gerrit (please see https://www.mediawiki.org/wiki/Developer_access for contributing.