Updating docs for 5.0 (#1576)

This commit is contained in:
Peter Hedenskog 2017-04-19 18:25:34 +02:00 committed by GitHub
parent 2289afd8f6
commit faaa01d7ad
24 changed files with 535 additions and 166 deletions

View File

@ -1,7 +1,6 @@
FROM sitespeedio/webbrowsers:firefox-52.0.1-chrome-57.0 FROM sitespeedio/webbrowsers:firefox-52.0.1-chrome-57.0
ENV SITESPEED_IO_BROWSERTIME__XVFB true ENV SITESPEED_IO_BROWSERTIME__XVFB true
ENV SITESPEED_IO_BROWSERTIME__CONNECTIVITY__ENGINE tc
ENV SITESPEED_IO_BROWSERTIME__CHROME__ARGS no-sandbox ENV SITESPEED_IO_BROWSERTIME__CHROME__ARGS no-sandbox
RUN mkdir -p /usr/src/app RUN mkdir -p /usr/src/app

23
HELP.md
View File

@ -1,22 +1,17 @@
# Help # Help
We want to make sitespeed.io the best web performance tool in the world and we hope you want to help us! We want to make sitespeed.io the best web performance tool in the world and we hope you can to help us!
# Money
> "Can't we just support you with money?"
We would prefer that you spend your money on people that really needs it, support the [Red Cross](https://www.icrc.org/eng/donations/ways-to-donate/). We will add more specific projects that we want you to support soon.
## Developers ## Developers
We love to have more people involved in making sitespeed.io better. We are constantly working on adding more documentation and trying to write more information in the issues so its easier to help out. If there's an [issue](https://github.com/sitespeedio/sitespeed.io/issues) that suites you, take it on! If you want help to get started or want to discuss the solution, ping the issue and we can setup a hangout. We love to have more people involved in making sitespeed.io better. We are constantly working on adding more documentation and trying to write more information in the issues so its easier to help out. If there's an [issue](https://github.com/sitespeedio/sitespeed.io/issues) that you want to take on, ping the the issue and we can help you get started. You can also [join our Slack channel](https://sitespeedio.slack.com/shared_invite/MTY5ODMzNjAwNTEyLTE0OTI0OTgzOTUtYWJjNDhiNzI2ZA) if you need help!
## Designers ## Designers
Help us make the result pages look better! Help us make the documentation look better [https://www.sitespeed.io](https://www.sitespeed.io). You can pretty much help us with everything := As a designer there's a lot you can do: You can make the HTML result pages look better. Maybe we should restructure the metrics? Maybe we should have graphs? Or could the header/footer look better? You could also have look at [https://www.sitespeed.io](https://www.sitespeed.io) where we have all the documentation. Make it look phab. You can pretty much help us with everything, no one in the core team got design skills :)
## Documentation ## Documentation
Documentation is fun and it is the core of making software easy to use. Help us out and proof read and add sections that are missing. Documentation for 4.0 happens [here](https://github.com/sitespeedio/sitespeed.io/tree/master/docs). Documentation is fun and it is the core of making sitespeed.io easy to use. We got a [special documentation tag for issues](https://github.com/sitespeedio/sitespeed.io/issues?q=is%3Aissue+is%3Aopen+label%3Adocumentation) that you can use to find where we know we lack documentation. Fixing spelling mistakes is great. Or rewrite parts that you think is too complicated. You can find what you need to send a PR to the documentation [here](https://github.com/sitespeedio/sitespeed.io/tree/master/docs).
## Tests ## Tests
We lack a lot of tests for the coming 4.0. Writing tests is a good way to get familiar with the codebase and will help us a lot in the future. A good start is adding support for the code in the [support library](https://github.com/sitespeedio/sitespeed.io/tree/master/lib/support). We lack unit tests. You can read about [our testing pipeline](https://www.sitespeed.io/releasing-with-confidence/) that works good for us but more unit tests are always good. A good start is adding support for the code in the [support library](https://github.com/sitespeedio/sitespeed.io/tree/master/lib/support).
## Companies ## Companies
@ -24,8 +19,6 @@ Do you use sitespeed.io in your everyday work? Then we have a perfect propositio
# Help wanted # Help wanted
You can help us: You can help us:
* We want to be able to [blacklist/whitelist URLs](https://github.com/sitespeedio/browsertime/issues/156). If you do Python this could be your thing. * Make it possible to [drive Chrome on Android phones from Docker](https://github.com/sitespeedio/browsertime/issues/312).
* Do you use InfluxDB? @tobli did a POC implementing InfluxDB and you can [help us make it better](https://github.com/sitespeedio/sitespeed.io/issues/889). * [Add connectivity support](https://github.com/sitespeedio/browsertime/issues/313) for Android phones.
* Help us make the documentation even better. We love your feedback and help [https://github.com/sitespeedio/sitespeed.io/tree/master/docs](https://github.com/sitespeedio/sitespeed.io/tree/master/docs). * Help us make the documentation even better. We love your feedback and help [https://github.com/sitespeedio/sitespeed.io/tree/master/docs](https://github.com/sitespeedio/sitespeed.io/tree/master/docs).
Checkout the [milestones](https://github.com/sitespeedio/sitespeed.io/milestones) and check if there's issues you want to do. Are they lacking info? Ping the issue and we will help you.

View File

@ -13,7 +13,7 @@
Using sitespeed.io you can: Using sitespeed.io you can:
* Test your web site against Web Performance best practices using the [Coach](https://github.com/sitespeedio/coach). * Test your web site against Web Performance best practices using the [Coach](https://github.com/sitespeedio/coach).
* Collect timing metrics like Navigation Timing API and User Timing API from Firefox/Chrome using [Browsertime](https://github.com/sitespeedio/browsertime). * Collect Navigation Timing API, User Timing API and Visual Metrics from Firefox/Chrome using [Browsertime](https://github.com/sitespeedio/browsertime).
* Run your custom-made JavaScript and collect whichever metric(s) you need. * Run your custom-made JavaScript and collect whichever metric(s) you need.
* Test one or multiple pages, across one or many runs to get more-accurate metrics. * Test one or multiple pages, across one or many runs to get more-accurate metrics.
* Create HTML-result pages or store the metrics in Graphite. * Create HTML-result pages or store the metrics in Graphite.
@ -23,6 +23,8 @@ See all the latest changes in the [Changelog](https://github.com/sitespeedio/sit
And a lot of more things. But what does it look like? And a lot of more things. But what does it look like?
Checkout our example [dashboard.sitespeed.io](https://dashboard.sitespeed.io/dashboard/db/page-summary)
A summary report in HTML: A summary report in HTML:
<img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/html-summary.png"> <img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/html-summary.png">
@ -30,20 +32,18 @@ Individual page report:
<img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/page.png"> <img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/page.png">
Collected metrics from a URL in Graphite/Grafana: Collected metrics from a URL in Graphite/Grafana:
<img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/pagesummary-grafana.png"> <img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/grafana-page-summary.png">
Video - easiest using Docker. This gif is optimized, the quality is much better IRL: Video - easiest using Docker. This gif is optimized, the quality is much better IRL:
<img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/barack.gif"> <img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/barack.gif">
## 4.0 ## Lets try it out
Version 4.0 is a ground-up rewrite for node.js 6.9.1 and newer. It builds on all our experience since shipping 3.0 in December 2014,
the first version to use node.js.
Using Docker (requires 1.10+): Using Docker (requires 1.10+):
```bash ```bash
$ docker run --privileged --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --video --speedIndex https://www.sitespeed.io/ $ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --video --speedIndex https://www.sitespeed.io/
``` ```
Or install using npm: Or install using npm:
@ -62,31 +62,6 @@ $ bin/sitespeed.js --help
$ bin/sitespeed.js http://www.sitespeed.io $ bin/sitespeed.js http://www.sitespeed.io
``` ```
## Why 4.0?
There's a lot of things that we wanted to improve since 3.0. Here's some of the most important changes:
* We support HTTP/2! In 3.X we used PhantomJS and a modified version of YSlow to analyze best practice rules. We also had BrowserMobProxy in front of our browsers that made it impossible to collect metrics using H2. We now use [the coach](https://github.com/sitespeedio/coach) and Firefox/Chrome without a proxy. That makes it easier for us to adapt to browser changes and changes in best practices.
* We now support the feature that people asked about the most: Measure a page as a logged in user. Use --browsertime.preScript to run a selenium task to before the page is analyzed. Documentation is coming soon.
* New HAR files rock! In the old version we use BrowserMobProxy as a proxy in front of the browser to collect the HAR. In the new version we collect the HAR directly from the browser. For Firefox we use the [HAR export trigger](https://github.com/firebug/har-export-trigger) and in Chrome we generates it from the performance log.
* Stability: We have a new completely rewritten version of [Browsertime](https://github.com/tobli/browsertime) that makes it easier for us to catch errors from the browser, drivers and environment problems.
* Speed: Yep we dropped Java (it was needed for BrowserMobProxy) and most things are happening in parallel with the new version.
* Don't overload Graphite: One thing that was annoying with 3.x was that it by default sent a massive amount of metrics to Graphite. That's cool in a way but it was too much. We now send curated metrics by default and you can choose to send more.
* You can collect metrics from Chrome on an Android phone. In the current version you need to have it connected using USB to the server running sitespeed.io, lets see how we can make it better in the future.
* Using our Docker container you will get support getting SpeedIndex and startRender using [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics). This is highly experimental at this stage.
* We now support video and calculating SpeedIndex (since 4.1). Use our Docker container to get an easy ride.
There are new things that will come also that isn't 100% implemented yet and you can help us.
* InfluxDB support. We have started with a POC but need to implement it properly, see [889](https://github.com/sitespeedio/sitespeed.io/issues/889).
## I want to help! ## I want to help!
We have a [special page](HELP.md) for you! We have a [special page](HELP.md) for you!

View File

@ -3,5 +3,5 @@
* * * * * *
{{ post.intro }} {{ post.intro }}
[read the blog post to find out more]({{site.baseurl}}{{ post.url }}). [Read the blog post to find out more]({{site.baseurl}}{{ post.url }}).
{% endfor %} {% endfor %}

View File

@ -3,4 +3,4 @@
[<img src="{{site.baseurl}}/img/pippi.png" class="pull-left img-big" alt="Pippi Longstocking a true hero" width="180" height="151">](https://dashboard.sitespeed.io) [<img src="{{site.baseurl}}/img/pippi.png" class="pull-left img-big" alt="Pippi Longstocking a true hero" width="180" height="151">](https://dashboard.sitespeed.io)
With sitespeed.io it's easy to become a performance hero! Check out our [example dashboard](https://dashboard.sitespeed.io), it's a great example that shows you what you can do. With 4.0 it's super easy to get that up and running. You can even use our [new Docker Compose file]({{site.baseurl}}/documentation/sitespeed.io/performance-dashboard/#docker-compose-file) to get Graphite/Grafana with default dashboards up and running in less than 5 minutes! With sitespeed.io it's easy to become a performance hero! Check out our [example dashboard](https://dashboard.sitespeed.io), it's a great example that shows you what you can do. It's super easy to get that up and running. You can even use our [new Docker Compose file]({{site.baseurl}}/documentation/sitespeed.io/performance-dashboard/#docker-compose-file) to get Graphite/InfluxDB/Grafana with default dashboards up and running in less than 5 minutes!

View File

@ -1,8 +1,10 @@
## Docker to the rescue! ## Docker to the rescue!
* * * * * *
Use our [Docker containers](https://hub.docker.com/u/sitespeedio/) to get an environment with Firefox, Chrome, XVFB and sitespeed.io up and running as fast as you can download them. Use our [Docker container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) to get an environment with Firefox, Chrome, XVFB and sitespeed.io up and running as fast as you can download them.
~~~ bash ~~~ bash
$ docker pull sitespeedio/sitespeed.io $ docker pull sitespeedio/sitespeed.io
$ docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ -b firefox $ docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ -b firefox --speedIndex --video
~~~ ~~~
To set the connectivity follow our [connectivity guide]({{site.baseurl}}/documentation/sitespeed.io/browsers/#change-connectivity) for Docker.

View File

@ -1,9 +1,10 @@
## Upgrade to sitespeed.io 4.0! ## Use sitespeed.io 5.0!
* * * * * *
* HTTP/2 support * Collect timing metrics, video, screenshots and page metrics in one go
* You can write your own plugins * Run Firefox and or Chrome
* Super simple setup with Docker
* Generic dashboard templates for Grafana
* The coach is the new YSlow * The coach is the new YSlow
* Generic dashboard templates * Write your own plugins
* HAR files as seen by the browser * HAR files as seen by the browser
* Completely rewritten code base to make it easier to update in the future

View File

@ -1,5 +1,5 @@
## Browsertime 1.0 (soon) ## Browsertime 1.0
* * * * * *
[<img src="{{site.baseurl}}/img/browsertime-ff-chrome.png" class="pull-left img-big" alt="Browsertime" width="180" height="162">]({{site.baseurl}}/documentation/browsertime) [<img src="{{site.baseurl}}/img/browsertime-ff-chrome.png" class="pull-left img-big" alt="Browsertime" width="180" height="162">]({{site.baseurl}}/documentation/browsertime)
We've been working on releasing 1.0 of Browsertime for some time now and we will soon be there. We have two things we want to correct first. We want to [change the error handling](https://github.com/sitespeedio/browsertime/issues/185), so errors that occur are reflected in the resulting JSON. It would also be cool to be able to [add request headers](https://github.com/sitespeedio/browsertime/issues/155). Let us know if you can help us! We've been working on releasing 1.0 of Browsertime for some time and now it's here! You should use Browsertime if you want a raw JSON result for timings and/or execute your own JavaScript. Browsertime is perfect if you wanna build your own performance tool, as VoxMedia did when they created [Lightbike](https://github.com/voxmedia/lightbike) built on top of Browsertime.

View File

@ -1,5 +1,16 @@
## Contribute ## Contribute
* * * * * *
You can make sitespeed.io better! Check the [help section](https://github.com/sitespeedio/sitespeed.io/blob/master/HELP.md) and the [full issue list](https://github.com/sitespeedio/sitespeed.io/issues). There's a lot that needs to be done!
[These people](https://github.com/sitespeedio/sitespeed.io/blob/master/CONTRIBUTORS.md) has already improved sitespeed.io with pull requests or ideas (massive love!). There's a lot of things you can do to help us make sitespeed.io even better than it is today.
If you code, write documentation or do UX you can check the [help section](https://github.com/sitespeedio/sitespeed.io/blob/master/HELP.md) and the [full issue list](https://github.com/sitespeedio/sitespeed.io/issues).
[These people](https://github.com/sitespeedio/sitespeed.io/blob/master/CONTRIBUTORS.md) has already improved sitespeed.io with pull requests or ideas (massive love!).
And if you are into a long time commitment you can also join the sitespeed.io team:
<a href="https://twitter.com/beenanner"><img src="{{site.baseurl}}/img/aboutus/jonathan.jpg" class="photo pull-left" width="100" height="100"></a>
<a href="https://twitter.com/tobiaslidskog"><img src="{{site.baseurl}}/img/aboutus/tobias.jpg" class="photo pull-left" width="100" height="100"></a>
<a href="https://twitter.com/soulislove"><img src="{{site.baseurl}}/img/aboutus/peter.jpg" class="photo pull-left" width="100" height="100"></a>

View File

@ -0,0 +1,85 @@
---
layout: default
title: Releasing with confidence
description: How we work to keep sitespeed.io releases as bug free as possible.
authorimage: /img/aboutus/peter.jpg
intro: We release often and try to have as few bugs as possible (surprised!) and we do that by ...
keywords: sitespeed.io, sitespeed, release, pipeline, test, slack
nav: blog
---
# Releasing with confidence
Some people say we release sitespeed.io too often. That is partly true. We release often. But we don't release too often :) We've been releasing new functions when they are done the last 4.5 years (sitespeed.io will turn 5 years in October!). We had some bugs but we have worked out a system where we usually find them before we release.
If you have problem updating and keeping track on when we release, follow [us on Twitter](https://twitter.com/sitespeedio). We always tweet about the new release and if there are a serious bug fix we will highlight that.
Let us go back in time and see how we did things in the beginning.
## The first years
The first years I was doing the development by myself and getting very few PRs. Keeping the bug level low was a matter of how much time I spent testing most use cases before each release. It worked ok, I had a list of URLs in a shell script I manually started before each release to check that they worked, some bugs was found before the release, and some later on. It worked ok for the code base at that time.
## Today
We are a three member team, more PRs (but we want more!) and a larger code base since we have five web performance tools that we built. We need to have a more automated setup today to be able to release often.
### Workflow
Let us check what happens when we push code:
1. We commit our code (or merge your PR) to [Github](https://github.com/sitespeedio/sitespeed.io).
2. [Travis-CI](https://travis-ci.org/sitespeedio/sitespeed.io) runs a couple of unit tests and a couple of full integration test where we run sitespeed.io from the command line, testing a couple of sites in Chrome/Firefox and test our WebPageTest integration. You can find our Travis configuration [here](https://github.com/sitespeedio/sitespeed.io/blob/master/.travis.yml).
3. The commit also builds a new [Docker container at the Docker hub](https://hub.docker.com/r/sitespeedio/sitespeed.io-autobuild/). Remember: This is not the same as you use when you run sitespeed.io in production, this one contains the latest and greatest commits.
4. We have a test server on Digital Ocean that runs the latest Docker container (it auto updates when there's a new version of the container). When the next test runs, it will use that latest version. When the test runs, it will upload the HTML to S3 and send the metrics to our Graphite instance.
5. On the server we also watch the sitespeed.io log and curls a Slack message when we get an error in the logs (using [http://blog.getpostman.com/2015/12/23/stream-any-log-file-to-slack-using-curl/](http://blog.getpostman.com/2015/12/23/stream-any-log-file-to-slack-using-curl/)).
![Getting alerts from Slack when we get an error in the logs]({{site.baseurl}}/img/slack-alert-error.png)
{: .img-thumbnail-center}
<p class="image-info">
<em class="small center">We need to do some tweaks in our WebPageTest integration before we do the next release!</em>
</p>
### Test server setup
We use Digital Ocean to run [dashboard.sitespeed.io](https://dashboard.sitespeed.io) (Graphite/Grafana on one server and one server running sitespeed.io). There we run sitespeed.io with the setup described [here](https://www.sitespeed.io/documentation/sitespeed.io/performance-dashboard/#get-the-metrics). We test 20+ URLs every hour:
* Five URLs for Wikipedia (both with Chrome and Firefox) 5 runs each.
* Two URLs as logged in and 3 URLs for a second view (first access one page to fill the browser cache and then measure the next URL).
* We test [https://www.sitespeed.io](https://www.sitespeed.io) with both Chrome & Firefox for five runs.
* Three pages both for first and second view of the mobile version of Wikipedia.
* We test [https://www.ryanair.com/us/en/](https://www.ryanair.com/us/en/) and [https://www.nytimes.com/](https://www.nytimes.com/) to include websites with ads.
You can checkout the result on [dashboard.sitespeed.io](https://dashboard.sitespeed.io) and by clicking the *runs* checkbox you can access the HTML result pages served by S3. The code that generates these metrics are always the latest commits. You can check yourself how we are doing :)
![Go from Grafana to S3 HTML result]({{site.baseurl}}/img/grafana-runs-to-s3.png)
{: .img-thumbnail-center}
<p class="image-info">
<em class="small center">Go from Grafana to the HTML result uploaded in S3.</em>
</p>
### Release
When we release (= a new version to npm and a new tag to the Docker hub) we use [this](https://github.com/sitespeedio/sitespeed.io/blob/master/release.sh) super simple release script. But before we release we always let the latest code run for a while on our test server and wait for errors on our Slack channel. We always manually browse the logs before a release and verify the HTML result pages on S3.
### How you should upgrade sitespeed.io
If you use Docker (and you should do that) make sure that you run our tagged versions and by tag we don't mean latest. Use the version tag so you are sure you run the exact version. If you use the latest tag you can accidentally update sitespeed.io.
~~~bash
$ docker pull sitespeedio/sitespeed.io:4.7.0
~~~
When when you upgrade, read the [changelog](https://github.com/sitespeedio/sitespeed.io/blob/master/CHANGELOG.md) and Docker pull the new version and then change your run script/yml file (or whatever you use to start sitespeed.io).
## What can we do better
We want to improve make our releases even safer. What can we do?
* More unit tests, that would help us find tests earlier. Realistically I don't think that will happen until we got more people joining the team.
* Tobias has [started to move Browsertime tests](https://github.com/sitespeedio/browsertime/pull/299) to run in a Docker container in Travis. We hope that will reduce the build time and make easy for us to make more full run tests.
* It would be cool if we could check the logs on Travis and if get an error in the log, just break the build. Today we only break the build when sitespeed.io returns an error code.
If you have any ideas how we can test better, please [create an issue at Github](https://github.com/sitespeedio/sitespeed.io/issues/new) or send us a [tweet](https://twitter.com/sitespeedio)!
/Peter
P.S We will soon release 5.0, it will be a blast!

View File

@ -0,0 +1,123 @@
---
layout: default
title: sitespeed.io 5.0
description: Six months ago we released 4.0 and now it's it time for 5.0!!
authorimage: /img/aboutus/peter.jpg
intro: With the latest release we add support for storing metrics in InfluxDB, add your own request headers, block requests by domain and a massive HTML update.
keywords: sitespeed.io, sitespeed, release, 5.0
nav: blog
---
# Say hello to 5.0
Almost 6 months ago we released 4.0 and it was a lot of hard work to get that out: Adding HTTP/2 support, complete rewriting everything and making it more modular. We needed to release 4.0 but everything wasn't crisp. My personal opinion is that we missed out the final touch on the HTML result pages. We have that now with 5.0 :)
But first lets check what we have added the last months:
* Video with SpeedIndex/firstVisualChange/lastVisualChange and VisualComplete 85%. This is real SpeedIndex where we record a video of the screen and use [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics/) to analyze and get the metrics.
* Upload the [HTML result to Amazon S3](https://results.sitespeed.io/en.wikipedia.org/2017-04-10-06-00-04/pages/en.wikipedia.org/wiki/Barack_Obama/).
* A better way to [set connectivity using Docker networks]({{site.baseurl}}/documentation/sitespeed.io/browsers/#change-connectivity).
* Cleaner default Grafana dashboard with links to the HTML results.
* Newer and cleaner version of [PerfCascade](https://github.com/micmro/PerfCascade) that makes the waterfall of the HAR files look great!
* Collect the timeline log and netlog from Chrome.
Before we go on about the new things in 5.0 we wanna tell you about the status of the project:
We have had more 500 000 downloads of sitespeed.io (588k + the ones we had before we moved to NodeJS and Docker)! We have a lot of more things we want to add and now are the time to help us!
We have a Slack channel for developers [that you should join](https://sitespeedio.slack.com/shared_invite/MTY5ODMzNjAwNTEyLTE0OTI0OTgzOTUtYWJjNDhiNzI2ZA)! There you can get help with building plugins or if you want to contribute to sitespeed.io. If you have questions how to run sitespeed.io, please use [Github issues](https://github.com/sitespeedio/sitespeed.io/issues/new).
Between latest 4.7 and now 5.0 we have focused on getting the HTML mean and clean. Let's check out the changed in 5.0.
## UX improvements
We structure the data better now, the whole experience using 5.0 is so much better than 4.0 :)
### Video
If you have tried sitespeed.io since we introduced video support you have seen that we have a really crisp video. One cool thing is that we display the visual metrics in the video when it happens. The video now also includes Visual Complete 85% so it is easy to see when that happens.
We also made it easier to download the video. Checkout the yellow button for downloading. You can download the video, the HAR files, Chrome timeline (if you configured that) and the sitespeed.io log from that run. It's not a big thing but it makes life a little easier.
![The video includes metrics by default]({{site.baseurl}}/img/video5.0.png)
{: .img-thumbnail}
<p class="image-info">
<em class="small center">The video includes metrics by default but you can turn that off if you want.</em>
</p>
### Timing metrics
The Browsertime result page was a little hard to read. To make it easier we have split the metrics in visual metrics and metrics from the browser.
![Metrics are now easier to see the Browsertime result tab]({{site.baseurl}}/img/visualmetrics-browsertime.png)
{: .img-thumbnail}
<p class="image-info">
<em class="small center">If you click on the metric you will get to the definition of the metric</em>
</p>
### Find that run
On the page summary (where you see summary metrics for all the runs) it is now super easy to match a metric to a specific run. All min/median/max metrics are linked to the run that hold that metric.
This is super useful if come from Grafana and want to match a specific run that was graphed.
![It is now easy to find the run that had that metric]({{site.baseurl}}/img/findthatrun.png)
{: .img-thumbnail}
<p class="image-info">
<em class="small center">All metric numbers are now links, pointing to that run that had that metric</em>
</p>
### WebPageTest
We are still in love with WebPageTest and improved the look and feel of the WebPageTest result page. We also automatically download the HAR file, Chrome timeline JSON and the images for the waterfall graphs, so that the result is self contained. No more beacons back when your user access your result pages.
We show more metrics than before and also follow the structure of metrics that we use for Browsertime.
![New look and feel for WebPageTest metrics]({{site.baseurl}}/img/wpt-5.0.png)
{: .img-thumbnail}
## Logs
As we mentioned before you can now download the logs easily from the HTML by adding <code>--html.logDownloadLink</code> to your CLI parameters.
![Download the log]({{site.baseurl}}/img/download-log.png)
{: .img-thumbnail}
## InfluxDB
We have had a long time goal to support one other TSDB than Graphite and now we officially support InfluxDB. We have [one example dashboard](https://dashboard.sitespeed.io/dashboard/db/wip-influxdb?orgId=1) that you can use and maybe we can have more example dashboards in the future.
This is extremely new so it could be miss out on functionality, if that's the case, create an issue and we will fix that!
A special thank you [@theist](https://github.com/theist) and [@eripa](https://github.com/eripa) who helped us fix the InfluxDB integration so the structure is better than we had in the original version.
![InfluxDB dashboard]({{site.baseurl}}/img/influxdb-dashboard.png)
{: .img-thumbnail}
## Browsertime 1.1
Sitespeed.io 5.0 used Browsertime 1.1. And what a ride it has been for the first beta 1.0 of Browsertime eight months ago! We will soon do a blog post about 1.0 but I want to talk about the latest thing we added before releasing that final version.
### Video and SpeedIndex from your Android device
I would still call it experimental support for video and SpeedIndex for Chrome on Android. We need help to test it out on different devices. Right now you need to setup the dependencies needed for VisualMetrics yourself so it some work to get that going. Check out the [how to](https://github.com/sitespeedio/browsertime#test-on-your-mobile-device) what you need to setup.
![Video and SpeedIndex on Android](https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/barack.gif)
{: .img-thumbnail}
Warning: This is really addictive! When I integrated latest Browsertime in sitespeed.io I got stuck a couple of hours testing different sites on my low end Huawei Android phone.
Our Docker container don't support Android at the moment but we hope we can add it in the future. Let us know if you can help us with that!
### Your own request headers and blocking request
We finally have been able to add support for adding your own request headers and blocking requests by domain, by creating [our own Browser extension](https://github.com/sitespeedio/browsertime-extension). In this release it works in Chrome and soon in Firefox (we need Tobias [fix](https://github.com/SeleniumHQ/selenium/pull/3846) to land in Selenium for supporting the new extension layout in Firefox).
Adding a request header:
~~~bash
$ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ -r Name:Value
~~~
Blocking all request on my.example.com:
~~~bash
$ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ --block my.example.com
~~~
## Not backward compatible changes in 5.0
There's one change in 5.0 that changes the default behavior: TSProxy isn't default for connectivity since it doesn't work as we want together with Selenium. We also removed tc as default running Docker. When you change connectivity you should use our [Docker network setup](https://www.sitespeed.io/documentation/sitespeed.io/browsers/#change-connectivity)!
/Peter

View File

@ -18,57 +18,209 @@ Access the Web Performance Timeline, from your browser, in your terminal!
Browsertime allows you to: Browsertime allows you to:
* Query timing data directly from the browser, to access [Navigation Timing](http://kaaes.github.io/timing/info.html), [User Timing](http://www.html5rocks.com/en/tutorials/webperformance/usertiming/), 1. Query timing data directly from the browser, to access [Navigation Timing](http://kaaes.github.io/timing/info.html), [User Timing](http://www.html5rocks.com/en/tutorials/webperformance/usertiming/),
[Resource Timing](http://www.w3.org/TR/resource-timing/), first paint and [RUM Speed Index](https://github.com/WPO-Foundation/RUM-SpeedIndex). [Resource Timing](http://www.w3.org/TR/resource-timing/), first paint and [RUM Speed Index](https://github.com/WPO-Foundation/RUM-SpeedIndex).
* Generate [HAR](http://www.softwareishard.com/blog/har-12-spec/) files 1. Generate [HAR](http://www.softwareishard.com/blog/har-12-spec/) files (using [HAR Export trigger](https://github.com/firebug/har-export-trigger) for Firefox and parsing the Chrome log for Chrome).
* Run custom Javascript scripts in the browser and get statistics for each run. 1. Run custom Javascript scripts in the browser and get statistics for each run.
1. Record a video of the screen and analyze the result to get First Visual Change, Speed Index, Visual Complete 85 % and Last Visual Change.
* Lets place the TOC here
{:toc}
## A simple example ## A simple example
Use our Docker image (with Chrome, Firefox, XVFB and the dependencies needed to record a video):
~~~
$ docker run --shm-size=1g --rm -v "$(pwd)":/browsertime-results sitespeedio/browsertime --video --speedIndex https://www.sitespeed.io/
~~~
Or using node:
~~~ ~~~
$ bin/browsertime.js https://www.sitespeed.io $ bin/browsertime.js https://www.sitespeed.io
~~~ ~~~
Load https://www.sitespeed.io in Chrome three times. Results are stored in a json file (browsertime.json) with the timing data, and a har file (browsertime.har) in `browsertime-results/www.sitespeed.io/$date/` Load https://www.sitespeed.io/ in Chrome three times. Results are stored in a JSON file (browsertime.json) with the timing data, and a HAR file (browsertime.har) in browsertime-results/www.sitespeed.io/$date/
## I want more examples ## I want more examples
Checkout the [examples](https://github.com/sitespeedio/browsertime/tree/master/docs/examples). Checkout the [examples](https://github.com/sitespeedio/browsertime/blob/master/docs/examples/README.md).
## Browsers ## Browsers
Browsertime supports Firefox and Chrome on desktop. On Android we support Chrome.
#### Supported Browsers But we want to [support Opera (on Android)](https://github.com/tobli/browsertime/issues/150) and when(?!) iOS Safari supports WebDriver we will add that too.
- Chrome (desktop)
- Firefox (desktop)
- Android Chrome (mobile)
#### Future Support
- Opera (desktop & mobile) - See: https://github.com/sitespeedio/browsertime/issues/150
- Safari (desktop) - Waiting on Safari 10
- iOS Safari (mobile) - Waiting on WebDriver support
## How does it work ## How does it work
Browsertime uses Selenium NodeJS to drive the browser. It starts the browser, load a URL, executes configurable Javascripts to collect metrics, collect a HAR file. Browsertime uses Selenium NodeJS to drive the browser. It starts the browser, load a URL, executes configurable Javascripts to collect metrics, collect a HAR file.
To get the HAR from Firefox we use the [HAR Export Trigger](https://github.com/firebug/har-export-trigger) and Chrome we parse the timeline log and generates the HAR file. To get the HAR from Firefox we use the [HAR Export Trigger](https://github.com/firebug/har-export-trigger) and Chrome we use [Chrome-HAR](https://github.com/sitespeedio/chrome-har) to parse the timeline log and generate the HAR file.
Oh and you can run your own Selenium script before (<code>--preScript</code>) and after (<code>--postScript</code>) a URL is accessed, so you can login/logout or do whatever you want. Oh and you can run your own Selenium script before (<code>--preScript</code>) and after (<code>--postScript</code>) a URL is accessed so you can login/logout or do whatever you want.
# Speed Index and video
It's easiest to run [our ready made Docker container](https://hub.docker.com/r/sitespeedio/browsertime/) to be able to record a video and calculate SpeedIndex because then you get all dependencies needed for free to run [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics).
## The rewrite to 1.0 The default video will include a timer and showing when the metrics happens, but you can turn that off using <code>--videoRaw</code>.
The master is to a large degree a re-write of the internal implementation, the cli interface, and the node API. It's <img src="https://raw.githubusercontent.com/sitespeedio/sitespeed.io/master/docs/img/video-example.gif">
based on the learnings from the previous releases of Browsertime, and their use in Sitespeed.io. It's still lacking some features
from the 0.x releases, and the API is not final. However it should be a better foundation for future development, using
more modern Javascript features and a much more extensive test suite.
- With 1.0 we've dropped BrowsermobProxy, so you don't need Java to run it. This makes each run significantly faster. :smile: ## Test using Docker
- We now support HTTP/2! You can build and test changes using Docker locally.
- If you want to do things before or after the URL is tested we support pre and post selenium scripts.
If you would would like to get started there are a few examples that can be found in the [docs folder](https://github.com/sitespeedio/browsertime/tree/master/docs/examples). If you run into any issues getting started using Browsertime visit our [issues page](https://github.com/sitespeedio/browsertime/issues) for some common issues/solutions. If you still cannot resolve the problem and feel the issue is within browsertime feel free to open an issue. ~~~
$ docker build -t sitespeedio/browsertime .
$ docker run --shm-size=1g --rm -v "$(pwd)":/browsertime-results sitespeedio/browsertime -n 1 --video --speedIndex https://www.sitespeed.io/
~~~
## Connectivity
You can throttle the connection to make the connectivity slower to make it easier to catch regressions. The best way to do that is to setup a network bridge in Docker.
Default we use [TSProxy](https://github.com/WPO-Foundation/tsproxy) because it's only dependency is Python 2.7 but we have a problem with that together with Selenium, so that it is kind of unusable right now. Help us fix that in [#229](https://github.com/sitespeedio/browsertime/issues/229).
If you run Docker you can use tc as connectivity engine but that will only set the latency, if you want to set the download speed you need to create a network bridge in Docker.
Here's an full example to setup up Docker network bridges on a server that has tc installed:
~~~bash
#!/bin/bash
echo 'Starting Docker networks'
docker network create --driver bridge --subnet=192.168.33.0/24 --gateway=192.168.33.10 --opt "com.docker.network.bridge.name"="docker1" 3g
tc qdisc add dev docker1 root handle 1: htb default 12
tc class add dev docker1 parent 1:1 classid 1:12 htb rate 1.6mbit ceil 1.6mbit
tc qdisc add dev docker1 parent 1:12 netem delay 300ms
docker network create --driver bridge --subnet=192.168.34.0/24 --gateway=192.168.34.10 --opt "com.docker.network.bridge.name"="docker2" cable
tc qdisc add dev docker2 root handle 1: htb default 12
tc class add dev docker2 parent 1:1 classid 1:12 htb rate 5mbit ceil 5mbit
tc qdisc add dev docker2 parent 1:12 netem delay 28ms
docker network create --driver bridge --subnet=192.168.35.0/24 --gateway=192.168.35.10 --opt "com.docker.network.bridge.name"="docker3" 3gfast
tc qdisc add dev docker3 root handle 1: htb default 12
tc class add dev docker3 parent 1:1 classid 1:12 htb rate 1.6mbit ceil 1.6mbit
tc qdisc add dev docker3 parent 1:12 netem delay 150ms
docker network create --driver bridge --subnet=192.168.36.0/24 --gateway=192.168.36.10 --opt "com.docker.network.bridge.name"="docker4" 3gem
tc qdisc add dev docker4 root handle 1: htb default 12
tc class add dev docker4 parent 1:1 classid 1:12 htb rate 0.4mbit ceil 0.4mbit
tc qdisc add dev docker4 parent 1:12 netem delay 400ms
~~~
Then when you run your container you add the network with <code>--network cable</code>. You should also tell Browsertime that you set the connectivity external from BT. A full example running running with cable:
~~~bash
$ docker run --shm-size=1g --network=cable --rm sitespeedio/browsertime -c cable --connectivity.engine external --speedIndex --video https://www.sitespeed.io/
~~~
And using the 3g network:
~~~bash
$ docker run --shm-size=1g --network=3g --rm sitespeedio/browsertime -c 3g --nnconnectivity.engine external --speedIndex --video https://www.sitespeed.io/
~~~
And if you want to remove the networks:
~~~bash
#!/bin/bash
echo 'Stopping Docker networks'
docker network rm 3g
docker network rm 3gfast
docker network rm 3gem
docker network rm cable
~~~
## Test on your mobile device
Browsertime supports Chrome on Android: Collecting SpeedIndex, HAR and video! This is still really new, let us know if you find any bugs.
You need to [install adb](https://www.sitespeed.io/documentation/sitespeed.io/mobile-phones/#desktop) and [prepare your phone](https://www.sitespeed.io/documentation/sitespeed.io/mobile-phones/#on-your-phone) before you start.
The current version doesn't support Docker so you need to [install the requirements](https://github.com/sitespeedio/docker-visualmetrics-deps/blob/master/Dockerfile) for VisualMetrics yourself on your machine before you start.
If you want to set connectivity you need to use something like [Micro device lab](https://github.com/phuedx/micro-device-lab).
~~~
browsertime --browsertime.chrome.android.package com.android.chrome https://www.sitespeed.io --video --speedIndex
~~~
## Configuration
Run <code>$ bin/browsertime.js --help</code> and you can see the configuration options:
~~~help
browsertime [options] <url>
timeouts
--timeouts.browserStart Timeout when waiting for browser to start, in milliseconds [number] [default: 60000]
--timeouts.pageLoad Timeout when waiting for url to load, in milliseconds [number] [default: 300000]
--timeouts.script Timeout when running browser scripts, in milliseconds [number] [default: 80000]
--timeouts.pageCompleteCheck Timeout when waiting for page to complete loading, in milliseconds [number] [default: 300000]
chrome
--chrome.args Extra command line arguments to pass to the Chrome process (e.g. --no-sandbox). To add multiple arguments to Chrome, repeat --chrome.args once per
argument.
--chrome.binaryPath Path to custom Chrome binary (e.g. Chrome Canary). On OS X, the path should be to the binary inside the app bundle, e.g. /Applications/Google Chrome
Canary.app/Contents/MacOS/Google Chrome Canary
--chrome.chromedriverPath Path to custom Chromedriver binary. Make sure to use a Chromedriver version that's compatible with the version of Chrome you're using
--chrome.mobileEmulation.deviceName Name of device to emulate. Works only standalone (see list in Chrome DevTools, but add company like 'Apple iPhone 6')
--chrome.mobileEmulation.width Width in pixels of emulated mobile screen (e.g. 360) [number]
--chrome.mobileEmulation.height Height in pixels of emulated mobile screen (e.g. 640) [number]
--chrome.mobileEmulation.pixelRatio Pixel ratio of emulated mobile screen (e.g. 2.0)
--chrome.android.package Run Chrome on your Android device. Set to com.android.chrome for default Chrome version. You need to run adb start-server before you start.
--chrome.android.deviceSerial Choose which device to use. If you do not set it, first device will be used.
--chrome.collectTracingEvents Include Tracing events in the performance log (implies chrome.collectPerfLog). [boolean]
--chrome.traceCategories A comma separated list of Tracing event categories to include in the performance log (implies chrome.collectTracingEvents). [string]
--chrome.collectPerfLog Collect performance log from Chrome with Page and Network events and save to disk. [boolean]
--chrome.collectNetLog Collect network log from Chrome and save to disk. [boolean]
firefox
--firefox.binaryPath Path to custom Firefox binary (e.g. Firefox Nightly). On OS X, the path should be to the binary inside the app bundle, e.g.
/Applications/Firefox.app/Contents/MacOS/firefox-bin
--firefox.preference Extra command line arguments to pass Firefox preferences by the format key:value To add multiple preferences, repeat --firefox.preference once per
argument.
--firefox.includeResponseBodies Include response bodies in HAR [boolean]
selenium
--selenium.url URL to a running Selenium server (e.g. to run a browser on another machine).
proxy
--proxy.http Http proxy (host:port) [string]
--proxy.https Https proxy (host:port) [string]
connectivity
--connectivity.profile, -c The connectivity profile. [choices: "3g", "3gfast", "3gslow", "3gem", "2g", "cable", "native", "custom"] [default: "native"]
--connectivity.downstreamKbps This option requires --connectivity.profile be set to "custom".
--connectivity.upstreamKbps This option requires --connectivity.profile be set to "custom".
--connectivity.latency This option requires --connectivity.profile be set to "custom".
--connectivity.alias Give your connectivity profile a custom name
--connectivity.tc.device The connectivity device. Used for engine tc. [default: "eth0"]
--connectivity.engine The engine for connectivity. TC (Linux Traffic Control) needs tc work but will only setup upload and latency. Use external if you set the connectivity
outside of Browsertime. The best way do to this is described in https://github.com/sitespeedio/browsertime#connectivity
[choices: "tc", "external"] [default: "external"]
Options:
--video Record a video. Requires FFMpeg to be installed [boolean]
--videoRaw Do not add timer and metrics to the video [boolean]
--speedIndex Calculate SpeedIndex. Requires FFMpeg and python dependencies [boolean]
--browser, -b Specify browser [choices: "chrome", "firefox"] [default: "chrome"]
--screenshot Save one screen shot per iteration. [boolean]
--pageCompleteCheck Supply a Javascript that decides when the browser is finished loading the page and can start to collect metrics. The Javascript snippet is repeatedly queried to
see if page has completed loading (indicated by the script returning true). Use it to fetch timings happening after the loadEventEnd.
--iterations, -n Number of times to test the url (restarting the browser between each test) [number] [default: 3]
--prettyPrint Enable to print json/har with spaces and indentation. Larger files, but easier on the eye. [boolean] [default: false]
--delay Delay between runs, in milliseconds [number] [default: 0]
--preScript Selenium script(s) to run before you test your URL (use it for login, warm the cache, etc). Note that --preScript can be passed multiple times.
--postScript Selenium script(s) to run after you test your URL (use it for logout etc). Note that --postScript can be passed multiple times.
--script Add custom Javascript to run after the page has finished loading to collect metrics. If a single js file is specified, it will be included in the category named
"custom" in the output json. Pass a folder to include all .js scripts in the folder, and have the folder name be the category. Note that --script can be passed
multiple times.
--userAgent Override user agent
--silent, -q Only output info in the logs, not to the console. Enter twice to suppress summary line. [count]
--output, -o Specify file name for Browsertime data (ex: 'browsertime'). Unless specified, file will be named browsertime.json
--har Specify file name for .har file (ex: 'browsertime'). Unless specified, file will be named browsertime.har
--skipHar Pass --skipHar to not collect a HAR file. [boolean]
--config Path to JSON config file
--viewPort Size of browser window WIDTHxHEIGHT or "maximize". Note that "maximize" is ignored for xvfb.
--resultDir Set result directory for the files produced by Browsertime
--xvfb Start xvfb before the browser is started [boolean] [default: false]
--preURL A URL that will be accessed first by the browser before the URL that you wanna analyze. Use it to fill the cache.
--userTimingWhitelist All userTimings are captured by default this option takes a regex that will whitelist which userTimings to capture in the results.
-h, --help Show help [boolean]
-V, --version Show version number [boolean]
~~~

View File

@ -25,44 +25,55 @@ You have the following options when running sitespeed.io (run <code>sitespeed.io
sitespeed.io [options] <url>/<file> sitespeed.io [options] <url>/<file>
Browser Browser
--browsertime.browser, -b, --browser Choose which Browser to use when you test. [choices: "chrome", "firefox"] [default: "chrome"] --browsertime.browser, -b, --browser Choose which Browser to use when you test. [choices: "chrome", "firefox"] [default: "chrome"]
--browsertime.iterations, -n How many times you want to test each page [default: 3] --browsertime.iterations, -n How many times you want to test each page [default: 3]
--browsertime.connectivity.profile, -c, --connectivity The connectivity profile. --browsertime.connectivity.profile, -c, --connectivity The connectivity profile.
[choices: "3g", "3gfast", "3gslow", "3gem", "2g", "cable", "native", "custom"] [default: "native"] [choices: "3g", "3gfast", "3gslow", "3gem", "2g", "cable", "native", "custom"] [default: "native"]
--browsertime.connectivity.downstreamKbps, --downstreamKbps This option requires --connectivity be set to "custom". --browsertime.connectivity.downstreamKbps, --downstreamKbps This option requires --connectivity be set to "custom".
--browsertime.connectivity.upstreamKbps, --upstreamKbps This option requires --connectivity be set to "custom". --browsertime.connectivity.upstreamKbps, --upstreamKbps This option requires --connectivity be set to "custom".
--browsertime.connectivity.latency, --latency This option requires --connectivity be set to "custom". --browsertime.connectivity.latency, --latency This option requires --connectivity be set to "custom".
--browsertime.connectivity.tsproxy.port The port used for TSProxy [default: 1080] --browsertime.connectivity.tsproxy.port The port used for TSProxy [default: 1080]
--browsertime.connectivity.engine The engine for connectivity. TSProxy needs Python 2.7. TC (Linux Traffic Control) needs tc work but will only setup --browsertime.connectivity.engine The engine for connectivity. TC (Linux Traffic Control) needs tc work but will only setup upload and
upload and latency. Use external if you set the connectivity outside of Browsertime. latency. Use external if you set the connectivity outside of Browsertime. The best way do to this is
[choices: "tc", "tsproxy", "external"] [default: "tsproxy"] described in https://github.com/sitespeedio/browsertime#connectivity
--browsertime.pageCompleteCheck Supply a Javascript that decides when the browser is finished loading the page and can start to collect metrics. [choices: "tc", "tsproxy", "external"] [default: "external"]
The Javascript snippet is repeatedly queried to see if page has completed loading (indicated by the script --browsertime.pageCompleteCheck Supply a Javascript that decides when the browser is finished loading the page and can start to
returning true). Use it to fetch timings happening after the loadEventEnd. collect metrics. The Javascript snippet is repeatedly queried to see if page has completed loading
--browsertime.script, --script Add custom Javascript that collect metrics and run after the page has finished loading. Note that --script can be (indicated by the script returning true). Use it to fetch timings happening after the loadEventEnd.
passed multiple times if you want to collect multiple metrics. The metrics will automatically be pushed to the --browsertime.script, --script Add custom Javascript that collect metrics and run after the page has finished loading. Note that
summary/detailed summary and each individual page + sent to Graphite/InfluxDB. --script can be passed multiple times if you want to collect multiple metrics. The metrics will
--browsertime.selenium.url Configure the path to the Selenium server when fetching timings using browsers. If not configured the supplied automatically be pushed to the summary/detailed summary and each individual page + sent to
NodeJS/Selenium version is used. Graphite/InfluxDB.
--browsertime.viewPort The browser view port size WidthxHeight like 400x300 [default: "1366x708"] --browsertime.selenium.url Configure the path to the Selenium server when fetching timings using browsers. If not configured
the supplied NodeJS/Selenium version is used.
--browsertime.viewPort The browser view port size WidthxHeight like 400x300 [default: "1366x708"]
--browsertime.userAgent The full User Agent string, defaults to the User Agent used by the browsertime.browser option. --browsertime.userAgent The full User Agent string, defaults to the User Agent used by the browsertime.browser option.
--browsertime.preScript, --preScript Selenium script(s) to run before you test your URL (use it for login, warm the cache, etc). Note that --preScript --browsertime.preScript, --preScript Selenium script(s) to run before you test your URL (use it for login, warm the cache, etc). Note
that --preScript can be passed multiple times.
--browsertime.postScript, --postScript Selenium script(s) to run after you test your URL (use it for logout etc). Note that --postScript
can be passed multiple times. can be passed multiple times.
--browsertime.postScript, --postScript Selenium script(s) to run after you test your URL (use it for logout etc). Note that --postScript can be passed
multiple times.
--browsertime.delay Delay between runs, in milliseconds. Use it if your web server needs to rest between runs :) --browsertime.delay Delay between runs, in milliseconds. Use it if your web server needs to rest between runs :)
--browsertime.speedIndex, --speedIndex Calculate SpeedIndex. Requires FFMpeg and python dependencies [boolean] --browsertime.speedIndex, --speedIndex Calculate SpeedIndex. Requires FFMpeg and python dependencies [boolean]
--browsertime.video, --video Record a video. Requires FFMpeg to be installed [boolean] --browsertime.video, --video Record a video. Requires FFMpeg to be installed [boolean]
--browsertime.preURL, --preURL A URL that will be accessed first by the browser before the URL that you wanna analyze. Use it to fill the cache. --browsertime.preURL, --preURL A URL that will be accessed first by the browser before the URL that you wanna analyze. Use it to
--browsertime.userTimingWhitelist, --userTimingWhitelist This option takes a regex that will whitelist which userTimings to capture in the results. All userTimings are fill the cache.
captured by default. T --browsertime.userTimingWhitelist, --userTimingWhitelist This option takes a regex that will whitelist which userTimings to capture in the results. All
--browsertime.firefox.preference Extra command line arguments to pass Firefox preferences by the format key:value To add multiple preferences, userTimings are captured by default. T
repeat --browsertime.firefox.preference once per argument. --browsertime.firefox.preference Extra command line arguments to pass Firefox preferences by the format key:value To add multiple
--browsertime.firefox.includeResponseBodies Include response bodies in HAR when using Firefox. [boolean] preferences, repeat --browsertime.firefox.preference once per argument.
--browsertime.chrome.args Extra command line arguments to pass to the Chrome process (e.g. --no-sandbox). To add multiple arguments to --browsertime.firefox.includeResponseBodies Include response bodies in HAR when using Firefox. [boolean]
Chrome, repeat --browsertime.chrome.args once per argument. --browsertime.chrome.args Extra command line arguments to pass to the Chrome process (e.g. --no-sandbox). To add multiple
--browsertime.chrome.dumpTraceCategoriesLog Dump Chromes traceCategories log to disk. [boolean] arguments to Chrome, repeat --browsertime.chrome.args once per argument.
--browsertime.chrome.traceCategories Set the trace categories. [string] --browsertime.chrome.collectTracingEvents Collect Chromes traceCategories [boolean]
--browsertime.chrome.android.package Run Chrome on your Android device. Set to com.android.chrome for default Chrome version. You need to
run adb start-server before you start.
--browsertime.chrome.android.deviceSerial Choose which device to use. If you do not set it, the first found device will be used.
--browsertime.chrome.collectNetLog Collect network log from Chrome and save to disk. [boolean]
--browsertime.chrome.traceCategories Set the trace categories. [string]
proxy
--browsertime.proxy.http Http proxy (host:port) [string]
--browsertime.proxy.https Https proxy (host:port) [string]
Crawler Crawler
--crawler.depth, -d How deep to crawl (1=only one page, 2=include links from first page, etc.) --crawler.depth, -d How deep to crawl (1=only one page, 2=include links from first page, etc.)
@ -70,77 +81,86 @@ Crawler
Graphite Graphite
--graphite.host The Graphite host used to store captured metrics. --graphite.host The Graphite host used to store captured metrics.
--graphite.port The Graphite port used to store captured metrics. [default: 2003] --graphite.port The Graphite port used to store captured metrics. [default: 2003]
--graphite.auth The Graphite user and password used for authentication. Format: user:password --graphite.auth The Graphite user and password used for authentication. Format: user:password
--graphite.httpPort The Graphite port used to access the user interface and send annotations event [default: 8080] --graphite.httpPort The Graphite port used to access the user interface and send annotations event [default: 8080]
--graphite.namespace The namespace key added to all captured metrics. [default: "sitespeed_io.default"] --graphite.webHost The graphite-web host. If not specified graphite.host will be used.
--graphite.includeQueryParams Whether to include query parameters from the URL in the Graphite keys or not [boolean] [default: false] --graphite.namespace The namespace key added to all captured metrics. [default: "sitespeed_io.default"]
--graphite.includeQueryParams Whether to include query parameters from the URL in the Graphite keys or not [boolean] [default: false]
--graphite.arrayTags Send the tags as array or a string. In Graphite 1.0 the tags is a array. [boolean] [default: false]
Plugins Plugins
--plugins.list List all configured plugins in the log. [boolean] --plugins.list List all configured plugins in the log. [boolean]
--plugins.disable Disable a plugin. Use it to disable generating html or screenshots. [array] --plugins.disable Disable a plugin. Use it to disable generating html or screenshots. [array]
--plugins.load Extra plugins that you want to run. Relative or absolute path to the plugin. [array] --plugins.load Extra plugins that you want to run. Relative or absolute path to the plugin. [array]
Budget Budget
--budget.configPath Path to the JSON budget file. --budget.configPath Path to the JSON budget file.
--budget.config The JSON budget config as a string. --budget.config The JSON budget config as a string.
--budget.output The output format of the budget. [choices: "junit", "tap"] --budget.output The output format of the budget. [choices: "junit", "tap"]
Metrics Metrics
--metrics.list List all possible metrics in the data folder (metrics.txt). [boolean] [default: false] --metrics.list List all possible metrics in the data folder (metrics.txt). [boolean] [default: false]
--metrics.filterList List all configured filters for metrics in the data folder (configuredMetrics.txt) [boolean] [default: false] --metrics.filterList List all configured filters for metrics in the data folder (configuredMetrics.txt) [boolean] [default: false]
--metrics.filter Add/change/remove filters for metrics. If you want to send all metrics, use: *+ . If you want to remove all current metrics and send only the coach score: --metrics.filter Add/change/remove filters for metrics. If you want to send all metrics, use: *+ . If you want to remove all current metrics and send only
*- coach.summary.score.* [array] the coach score: *- coach.summary.score.* [array]
WebPageTest WebPageTest
--webpagetest.host The domain of your WebPageTest instance. [default: "https://www.webpagetest.org"] --webpagetest.host The domain of your WebPageTest instance. [default: "https://www.webpagetest.org"]
--webpagetest.key The API key for you WebPageTest instance. --webpagetest.key The API key for you WebPageTest instance.
--webpagetest.location The location for the test [default: "Dulles:Chrome"] --webpagetest.location The location for the test [default: "Dulles:Chrome"]
--webpagetest.connectivity The connectivity for the test. [default: "Cable"] --webpagetest.connectivity The connectivity for the test. [default: "Cable"]
--webpagetest.runs The number of runs per URL. [default: 3] --webpagetest.runs The number of runs per URL. [default: 3]
--webpagetest.custom Execute arbitrary Javascript at the end of a test to collect custom metrics. --webpagetest.custom Execute arbitrary Javascript at the end of a test to collect custom metrics.
--webpagetest.file Path to a script file --webpagetest.file Path to a script file
--webpagetest.script The WebPageTest script as a string. --webpagetest.script The WebPageTest script as a string.
--webpagetest.includeRepeatView Do repeat or single views [boolean] [default: false] --webpagetest.includeRepeatView Do repeat or single views [boolean] [default: false]
--webpagetest.private Wanna keep the runs private or not [boolean] [default: true] --webpagetest.private Wanna keep the runs private or not [boolean] [default: true]
gpsi gpsi
--gpsi.key The key to use Google Page Speed Insight --gpsi.key The key to use Google Page Speed Insight
Slack Slack
--slack.hookUrl WebHook url for the Slack team (check https://<your team>.slack.com/apps/manage/custom-integrations). --slack.hookUrl WebHook url for the Slack team (check https://<your team>.slack.com/apps/manage/custom-integrations).
--slack.userName User name to use when posting status to Slack. [default: "Sitespeed.io"] --slack.userName User name to use when posting status to Slack. [default: "Sitespeed.io"]
--slack.channel The slack channel without the # (if something else than the default channel for your hook). --slack.channel The slack channel without the # (if something else than the default channel for your hook).
--slack.type Send summary for a run, metrics from all URLs, only on errors or all to Slack. [choices: "summary", "url", "error", "all"] [default: "all"] --slack.type Send summary for a run, metrics from all URLs, only on errors or all to Slack. [choices: "summary", "url", "error", "all"] [default: "all"]
--slack.limitWarning The limit to get a warning in Slack using the limitMetric [default: 80] --slack.limitWarning The limit to get a warning in Slack using the limitMetric [default: 90]
--slack.limitError The limit to get a error in Slack using the limitMetric [default: 90] --slack.limitError The limit to get a error in Slack using the limitMetric [default: 80]
--slack.limitMetric The metric that will be used to set warning/error [choices: "coachScore", "speedIndex", "firstVisualChange"] [default: "coachScore"] --slack.limitMetric The metric that will be used to set warning/error [choices: "coachScore", "speedIndex", "firstVisualChange"] [default: "coachScore"]
s3 s3
--s3.key The S3 key --s3.key The S3 key
--s3.secret The S3 secret --s3.secret The S3 secret
--s3.bucketname The S3 bucketname --s3.bucketname Name of the S3 bucket
--s3.path Override the default folder path in the bucket where the results are uploaded. By default it's "DOMAIN_OR_FILENAME/TIMESTAMP", or the
name of the folder if --outputFolder is specified.
--s3.region The S3 region. Optional depending on your settings. --s3.region The S3 region. Optional depending on your settings.
--s3.removeLocalResult Remove all the local result files after they have been uploaded to S3 [boolean] [default: false] --s3.removeLocalResult Remove all the local result files after they have been uploaded to S3 [boolean] [default: false]
HTML HTML
--html.showAllWaterfallSummary Set to true to show all waterfalls on page summary HTML report [boolean] [default: false] --html.showAllWaterfallSummary Set to true to show all waterfalls on page summary HTML report [boolean] [default: false]
--html.fetchHARFiles Set to true to load HAR files using fetch instead of including them in the HTML. Turn this on if serve your pages using a server.
[boolean] [default: false]
--html.logDownloadLink Adds a link in the HTML so you easily can download the logs from the sitespeed.io run. If your server is public, be careful so
you don't log passwords etc [boolean] [default: false]
text text
--summary Show brief text summary to stdout [boolean] [default: false] --summary Show brief text summary to stdout [boolean] [default: false]
--summary-detail Show longer text summary to stdout [boolean] [default: false] --summary-detail Show longer text summary to stdout [boolean] [default: false]
Options: Options:
--version, -V Show version number [boolean] --version, -V Show version number [boolean]
--debug Debug mode logs all internal messages to the console. [boolean] [default: false] --debug Debug mode logs all internal messages to the console. [boolean] [default: false]
--verbose, -v Verbose mode prints progress messages to the console. Enter up to three times (-vvv) to increase the level of detail. [count] --verbose, -v Verbose mode prints progress messages to the console. Enter up to three times (-vvv) to increase the level of detail. [count]
--mobile Access pages as mobile a fake mobile device. Set UA and width/height. For Chrome it will use device Apple iPhone 6. [boolean] [default: false] --mobile Access pages as mobile a fake mobile device. Set UA and width/height. For Chrome it will use device Apple iPhone 6. [boolean] [default: false]
--resultBaseURL The base URL to the server serving the HTML result. In the format of https://result.sitespeed.io --resultBaseURL The base URL to the server serving the HTML result. In the format of https://result.sitespeed.io
--gzipHAR Compress the HAR files with GZIP. [boolean] [default: false]
--outputFolder The folder where the result will be stored. --outputFolder The folder where the result will be stored.
--firstParty A regex running against each request and categorize it as first vs third party URL. (ex: ".*sitespeed.*") --firstParty A regex running against each request and categorize it as first vs third party URL. (ex: ".*sitespeed.*")
--utc Use Coordinated Universal Time for timestamps [boolean] [default: false] --utc Use Coordinated Universal Time for timestamps [boolean] [default: false]
--config Path to JSON config file --config Path to JSON config file
--help, -h Show help [boolean] --help, -h Show help [boolean]
Read the docs at https://www.sitespeed.io/documentation/sitespeed.io/ Read the docs at https://www.sitespeed.io/documentation/sitespeed.io/
~~~ ~~~

View File

@ -94,6 +94,14 @@ Full example:
$ docker run --rm -v "$(pwd)":/sitespeed.io -v /etc/localtime:/etc/localtime:ro sitespeedio/sitespeed.io -b firefox https://www.sitespeed.io/ $ docker run --rm -v "$(pwd)":/sitespeed.io -v /etc/localtime:/etc/localtime:ro sitespeedio/sitespeed.io -b firefox https://www.sitespeed.io/
~~~ ~~~
## Access localhost
If you run a server local on your machine and want to access it with sitespeed.io you can do that on your Mac by using the Docker fixed ip 192.168.65.1:
~~~ bash
$ docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io -b firefox http://192.168.65.1:4000/
~~~
## Troubleshooting ## Troubleshooting
### Inspect the container ### Inspect the container

View File

@ -1,14 +1,14 @@
--- ---
layout: default layout: default
title: Documentation for sitespeed.io 4.x title: Documentation sitespeed.io 5.x
description: Read about all you can do we with sitespeed.io. description: Read about all you can do with sitespeed.io.
keywords: tools, documentation, web performance keywords: tools, documentation, web performance
nav: documentation nav: documentation
image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png
twitterdescription: Documentation for the sitespeed.io. twitterdescription: Documentation for sitespeed.io.
--- ---
# Documentation v4 # Documentation v5
<img src="{{site.baseurl}}/img/logos/sitespeed.io.png" class="pull-right img-big" alt="Browsertime logo" width="200" height="214"> <img src="{{site.baseurl}}/img/logos/sitespeed.io.png" class="pull-right img-big" alt="Browsertime logo" width="200" height="214">

View File

@ -16,7 +16,7 @@ twitterdescription: Web performance dashboard using sitespeed.io.
* Lets place the TOC here * Lets place the TOC here
{:toc} {:toc}
We spent a lot of time making it easier in 4.x to install and run your own performance dashboard with pre made dashboards and a Docker compose file to rule them all. You can see the beauty [here](https://dashboard.sitespeed.io). In 4.4 and later you can also send the result (HTML/video) to S3 and add links in Grafana to go from you dashboard to the result pages. We spent a lot of time making it easier in version 4 to install and run your own performance dashboard with pre made dashboards and a Docker compose file to rule them all. You can see the beauty [here](https://dashboard.sitespeed.io). In 4.4 and later you can also send the result (HTML/video) to S3 and add links in Grafana to go from you dashboard to the result pages.
# What you need # What you need
You need [Docker](https://docs.docker.com/engine/installation/) and [Docker Compose](https://docs.docker.com/compose/install/). If you haven't used Docker before, you can read [Getting started](https://docs.docker.com/engine/getstarted/). And you can also read/learn more about [Docker Compose](https://docs.docker.com/compose/gettingstarted/) to get a better start. You need [Docker](https://docs.docker.com/engine/installation/) and [Docker Compose](https://docs.docker.com/compose/install/). If you haven't used Docker before, you can read [Getting started](https://docs.docker.com/engine/getstarted/). And you can also read/learn more about [Docker Compose](https://docs.docker.com/compose/gettingstarted/) to get a better start.
@ -33,7 +33,7 @@ You need [Docker](https://docs.docker.com/engine/installation/) and [Docker Comp
If you want to play with the dashboards the default login is sitespeedio and password is ...well checkout the docker-compose.yml file. If you want to play with the dashboards the default login is sitespeedio and password is ...well checkout the docker-compose.yml file.
## Docker compose file ## Docker compose file
We have prepared a Docker Compose file that downloads and setup Graphite/Grafana and sitespeed.io + a couple of example dashboards. It works perfect when you wanna try it out locally, but if you wanna run it in production you should modify it by making sure that the metrics are stored outside of your container/volumes. We have prepared a Docker Compose file that downloads and setup Graphite/Grafana and sitespeed.io + a couple of example dashboards. It works perfect when you wanna try it out locally, but if you wanna run it in production you should modify it by making sure that the metrics are stored outside of your container/volumes. If you prefer InfluxDB before Graphite, you can use that too, but right now we only have one ready made dashboard for InfluxDB.
## Pre made dashboards ## Pre made dashboards
We insert pre made dashboards with a Docker container using curl, that makes it easy for you to get started. You can check out the container with the dashboards here: [https://github.com/sitespeedio/grafana-bootstrap-docker](https://github.com/sitespeedio/grafana-bootstrap-docker) We insert pre made dashboards with a Docker container using curl, that makes it easy for you to get started. You can check out the container with the dashboards here: [https://github.com/sitespeedio/grafana-bootstrap-docker](https://github.com/sitespeedio/grafana-bootstrap-docker)
@ -195,7 +195,7 @@ tc qdisc add dev docker4 parent 1:12 netem delay 400ms
# Configure Graphite # Configure Graphite
We provide an example Graphite Docker container and you should probably change the configuration depending on how often you want to run your tests, how long you want to keep the result and how much disk space you want to use. We provide an example Graphite Docker container and you should probably change the configuration depending on how often you want to run your tests, how long you want to keep the result and how much disk space you want to use.
With 4.x we try to send a moderated number of metrics per URL but you can [change that yourself]({{site.baseurl}}/documentation/sitespeed.io/metrics/). With version 4 we tried to send a moderated number of metrics per URL but you can [change that yourself]({{site.baseurl}}/documentation/sitespeed.io/metrics/).
When you store metrics for a URL in Graphite you decide from the beginning how long time you want to store the data and how often in [storage-schemas.conf](https://github.com/sitespeedio/docker-graphite-statsd/blob/master/conf/graphite/storage-schemas.conf). In our example Graphite setup every key under sitespeed_io is caught by the configuration in storage-schemas.conf that looks like: When you store metrics for a URL in Graphite you decide from the beginning how long time you want to store the data and how often in [storage-schemas.conf](https://github.com/sitespeedio/docker-graphite-statsd/blob/master/conf/graphite/storage-schemas.conf). In our example Graphite setup every key under sitespeed_io is caught by the configuration in storage-schemas.conf that looks like:
<pre> <pre>

BIN
docs/img/download-log.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

BIN
docs/img/findthatrun.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 137 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 626 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 90 KiB

BIN
docs/img/video5.0.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 470 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 85 KiB

BIN
docs/img/wpt-5.0.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 56 KiB

View File

@ -10,14 +10,14 @@ image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png
## Welcome to the wonderful world of Web Performance ## Welcome to the wonderful world of Web Performance
Sitespeed.io is a set of Open Source tools that helps make your web pages faster. [The coach]({{site.baseurl}}/documentation/coach/) gives you performance advice based on best practices for your site. [Browsertime]({{site.baseurl}}/documentation/browsertime/) collects metrics and HAR files from your browser. [PageXray]({{site.baseurl}}/documentation/pagexray/) converts a HAR file to a usable JSON structure that tells you more about your page. [Chome-HAR](https://github.com/sitespeedio/chrome-har) creates a HAR file Chrome Debugging Protocol data. And finally [sitespeed.io]({{site.baseurl}}/documentation/sitespeed.io/) is the main tool that uses all the previously mentioned tools and add supports for testing multiple pages as well as adds the ability to report the metrics to a TSDB (currently Graphite and soon also InfluxDB). Sitespeed.io is a set of Open Source tools that helps make your web pages faster. [The coach]({{site.baseurl}}/documentation/coach/) gives you performance advice based on best practices for your site. [Browsertime]({{site.baseurl}}/documentation/browsertime/) collects metrics and HAR files from your browser. [PageXray]({{site.baseurl}}/documentation/pagexray/) converts a HAR file to a usable JSON structure that tells you more about your page. [Chome-HAR](https://github.com/sitespeedio/chrome-har) creates a HAR file Chrome Debugging Protocol data. And finally [sitespeed.io]({{site.baseurl}}/documentation/sitespeed.io/) is the main tool that uses all the previously mentioned tools and add supports for testing multiple pages as well as adds the ability to report the metrics to a TSDB (Graphite and InfluxDB).
Try out sitespeed.io by installing using [npm](https://www.npmjs.org/)/[yarn](https://yarnpkg.com/)/[Docker](https://hub.docker.com/r/sitespeedio/sitespeed.io/) ([need help?]({{site.baseurl}}documentation/sitespeed.io/installation/)): Try out sitespeed.io by installing using [Docker](https://hub.docker.com/r/sitespeedio/sitespeed.io/)/[npm](https://www.npmjs.org/)/[yarn](https://yarnpkg.com/) ([need help?]({{site.baseurl}}documentation/sitespeed.io/installation/)):
**Docker** **Docker**
~~~ bash ~~~ bash
$ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ $ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ --video --speedIndex
~~~ ~~~
**npm** **npm**