Last set of wording tweaks to docs for sitespeed.io
This commit is contained in:
Jonathan Lee
parent
40ccfa5a0b
commit
14cbe4514c
|
|
@ -17,44 +17,44 @@ twitterdescription: Use sitespeed.io in your Continuous Integration setup.
|
|||
* Lets place the TOC here
|
||||
{:toc}
|
||||
|
||||
Use sitespeed.io to keep track of what is happening with your site making sure that you don’t break the performance best practice rules before your change make it to production. You can even leverage budgets to break your build if your page has too many assets, they are too big or too slow. If you use WebPageTest you can even use those metrics to break a build.
|
||||
You can use sitespeed.io to keep track of what is happening with your site by making sure that you don’t break performance best practice rules before you push changes to production. You can leverage budgets to break your build if your page has too many assets, they are too big, or even too slow. You can even use WebPageTest metrics to break a build!
|
||||
|
||||
You can define your own [budget file](../performance-budget/#the-budget-file) with rules on when to break your build. This budget will return an error code status after the run or you can choose to output JUnit XML and TAP.
|
||||
To do this you define your own [budget file](../performance-budget/#the-budget-file) with rules on when to break your build. This budget will return an error code status after the run. You can also choose to output JUnit XML and TAP reports.
|
||||
|
||||
## Jenkins
|
||||
The easiest way to run in Jenkins is to use the pre built Docker containers. You can run an installed npm version too, but then you will need to setup browsers and use the [Xvfb plugin](https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin) to make the browsers run in headless mode.
|
||||
The most convenient way to run in Jenkins is to use the pre-built Docker containers. You can run an installed npm version too, but that method will require additional work as you will need to setup browsers and use the [Xvfb plugin](https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin) to make the browsers run in headless mode. Trust us use the Docker Images you will thnak us later. ;-)
|
||||
|
||||
### Setup
|
||||
* Choose *New Item* and create a new freestyle project.
|
||||
* Choose *Add build step* in the Build part and Execute shell you will have a box where you add your CLI magic. Remember that the Jenkins user needs to be able to run Docker or else you need to switch user.
|
||||
* We map the Jenkins workspace with the output folder in Docker so the HTML result is visible outside of the container.
|
||||
* Choose *Add build step* in the Build section and Execute shell. With this you will have a box where you can add your CLI magic. Remember that the Jenkins user needs to be able to run Docker.
|
||||
* We then map the Jenkins workspace's output folder in Docker to the Host, so that the HTML result is visible outside of the container.
|
||||
|
||||
~~~bash
|
||||
docker run --privileged -v ${WORKSPACE}:/sitespeed.io sitespeedio/sitespeed.io --outputFolder output https://www.sitespeed.io/ -n 1
|
||||
~~~
|
||||
|
||||
* You can then install the **Publish HTML Reports** plugin to make the reports easy available in Jenkins. Add it as a *Post-build Actions* and set the **HTML directory to archive** to *${WORKSPACE}/output/* and it will work fine.
|
||||
* You can then install the **Publish HTML Reports** plugin to make the reports easy available in Jenkins. You can add it as a *Post-build Actions* and set the **HTML directory to archive** to *${WORKSPACE}/output/*.
|
||||
|
||||
{: .img-thumbnail}
|
||||
|
||||
The HTML result pages runs Javascript so you need to change the [Jenkins Content Security Policy](https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy) for them to work with the plugin.
|
||||
The HTML result pages runs Javascript, so you need to change the [Jenkins Content Security Policy](https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy) for them to work with the plugin.
|
||||
|
||||
When you start Jenkins make sure to set the environment variable <code>-Dhudson.model.DirectoryBrowserSupport.CSP="sandbox allow-scripts; style-src 'unsafe-inline' *;script-src 'unsafe-inline' *;"</code>.
|
||||
|
||||
* If you want to break your build, you should generate a JUnit XML and use the built in post task *Publish JUnit test result report*. Make sure to make the budget file available inside the Docker container. In this example we have it inside the Jenkins workspace.
|
||||
* If you want to break your build, you should generate a JUnit XML and use the built-in post task *Publish JUnit test result report*. Make sure to make the budget file available inside the Docker container. In this example we have it inside the Jenkins workspace.
|
||||
|
||||
~~~bash
|
||||
docker run --privileged -v ${WORKSPACE}:/sitespeed.io sitespeedio/sitespeed.io --outputFolder output --budget /sitespeed.io/budget.json --budget.output junit https://www.sitespeed.io/ -n 1
|
||||
~~~
|
||||
|
||||
* Setup the JUnit report like this:
|
||||
* Setup the JUnit report:
|
||||
|
||||
{: .img-thumbnail}
|
||||
|
||||
Remember that you can send the metrics to Graphite to keep a closer look at all the metrics over time.
|
||||
Remember that you can also send the metrics to Graphite to keep a closer eye on all metrics over time.
|
||||
|
||||
## Travis
|
||||
We have an example project for setting up Travis [https://github.com/sitespeedio/travis/](https://github.com/sitespeedio/travis/blob/master/.travis.yml). Do not use timings in your budget because it will be highly unreliable. Use metrics that will be the same between runs like Coach score or number of requests.
|
||||
We have an example project for setting up Travis [https://github.com/sitespeedio/travis/](https://github.com/sitespeedio/travis/blob/master/.travis.yml). You should not try to use timings in your budget, simply because they tend to vary and be highly unreliable. We suggest using metrics that do not vary greatly and will be the same between runs like Coach score or number of requests.
|
||||
|
||||
## Grunt plugin
|
||||
Checkout the [grunt plugin](https://github.com/sitespeedio/grunt-sitespeedio)!
|
||||
|
|
|
|||
|
|
@ -17,30 +17,31 @@ twitterdescription: Hack on sitespeed.io
|
|||
{:toc}
|
||||
|
||||
## Start
|
||||
Start by looking at the image of [how it all works]({{site.baseurl}}/documentation/sitespeed.io/how-it-all-works/). It may seems like a lot, but it isn't that complicated.
|
||||
You can start by looking at the image of [how it all works]({{site.baseurl}}/documentation/sitespeed.io/how-it-all-works/). It may seems like a lot, but it isn't really that complicated.
|
||||
|
||||
## Setup
|
||||
On your local machine you need:
|
||||
* [Install NodeJS](https://nodejs.org/en/download/) latest LTS version
|
||||
* Fork [sitespeed.io](https://github.com/sitespeedio/sitespeed.io) and clone the forked repository
|
||||
* Go to the cloned directory and run *npm install*
|
||||
|
||||
Then you are ready. To run locally: *bin/sitespeed.io https://www.sitespeed.io -n 1* do changes to the pug and re-run.
|
||||
- [Install NodeJS](https://nodejs.org/en/download/) latest LTS version
|
||||
- Fork [sitespeed.io](https://github.com/sitespeedio/sitespeed.io) and clone the forked repository
|
||||
- Go to the cloned directory and run *npm install*
|
||||
- You are ready to go! To run locally: *bin/sitespeed.io https://www.sitespeed.io -n 1
|
||||
- Now make some changes to the pug templates and re-run.
|
||||
|
||||
To run the Docker version:
|
||||
* Install [Docker Community Edition](https://docs.docker.com/engine/installation/)
|
||||
* You need to fork and clone [sitespeed.io](https://github.com/sitespeedio/sitespeed.io).
|
||||
* Run *docker build sitespeedio/sitespeed.io .* in the cloned directory to build the container
|
||||
* Run *docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/*
|
||||
- Install [Docker Community Edition](https://docs.docker.com/engine/installation/)
|
||||
- You need to fork and clone [sitespeed.io](https://github.com/sitespeedio/sitespeed.io).
|
||||
- Run *docker build sitespeedio/sitespeed.io .* in the cloned directory to build the container
|
||||
- Run *docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/*
|
||||
|
||||
If you want to test and push to Graphite/InfluxDB:
|
||||
* Go to *development/* in the cloned dir and read the index.md file
|
||||
* Build the sitespeed.io container: *docker-compose build sitespeed*
|
||||
* Run: *docker-compose run sitespeed http://www.sitespeed.io --video --speedIndex -n 1 --graphite.host=graphite* to push the data to Graphite
|
||||
* Make your changes and rebuild the container *docker-compose build sitespeed*
|
||||
- Go to *development/* in the cloned dir and read the index.md file
|
||||
- Build the sitespeed.io container: *docker-compose build sitespeed*
|
||||
- Run: *docker-compose run sitespeed http://www.sitespeed.io --video --speedIndex -n 1 --graphite.host=graphite* to push the data to Graphite
|
||||
- Make your changes and rebuild the container *docker-compose build sitespeed*
|
||||
|
||||
## Plugins
|
||||
Everything in sitespeed.io (well almost everything) is a plugin. Each plugin will be called at startup, for each message sent in the application and then called when everything is finished.
|
||||
Everything in sitespeed.io (well almost everything) is a plugin. Each plugin will be called, for each message sent in the application and then called when everything is finished.
|
||||
|
||||
The [plugin structure]({{site.baseurl}}/documentation/sitespeed.io/plugins/#create-your-own-plugin) looks like that.
|
||||
|
||||
|
|
@ -49,12 +50,12 @@ The flow looks like this:
|
|||
|
||||
1. You start the application and feed it with a URL/URLs.
|
||||
2. The app will go through the configured plugins and start them while each plugin waits for messages.
|
||||
3. The app will send the URLs as URL messages and the plugins that listens to that type of messages will act on that. When a plugin is finished, it will post other messages on it's findings.
|
||||
3. The app will send the URLs as URL messages and the plugins that listens to that type of messages will recieve them. When a plugin is finished, it will post other messages on it's findings.
|
||||
4. When all URLs are finished, the plugins receive a "close" call to finalize and prepare their findings.
|
||||
5. Finish
|
||||
|
||||
## Using Pug
|
||||
We use [Pug](https://pugjs.org) as template for the HTML. If you are use to debug with console.log we have a special feature for you. We pass on JSON to the template, so if you want to output the data structure in the HTML you can do that by just adding:
|
||||
We use [Pug](https://pugjs.org) as template for the HTML. If you are use to debug with console.log we have a special feature for you. We pass on JSON to the templates, so if you want to output the data structure in the HTML you can easily do that by just adding:
|
||||
|
||||
~~~
|
||||
p #{JSON.stringify(pageInfo)}
|
||||
|
|
@ -68,7 +69,7 @@ If you want to integrate sitespeed.io into your NodeJS application you can check
|
|||
## Contributing to the Documentation
|
||||
First make sure you have Bundler: <code>gem install bundler</code>
|
||||
|
||||
You should probably upgrade your ruby gems too: <code>gem update --system</code>
|
||||
You should upgrade your ruby gems too: <code>gem update --system</code>
|
||||
|
||||
*If you run on a Mac OS make sure you have xcode-select installed: <code>xcode-select --install</code>*
|
||||
|
||||
|
|
@ -89,4 +90,4 @@ To start debugging, open the following URL in Chrome:
|
|||
|
||||
Then copy&paste the URL in chrome and you're in inspect mode. <code>--debug-brk</code> ensures a breakpoint as soon as the code is entered. From there, you can start any of the profiles under the Profile tab.
|
||||
|
||||
Use it when you wanna debug functionality or check memory usage.
|
||||
Use it when you want to debug functionality or check memory usage.
|
||||
|
|
|
|||
|
|
@ -16,11 +16,11 @@ twitterdescription: Use Docker to run sitespeed.io.
|
|||
{:toc}
|
||||
|
||||
## Containers
|
||||
Docker is the preferred installation method because you get everything for free :)
|
||||
Docker is the preferred installation method because almost every dependency is handled for you for all the features in sitespeed.io!
|
||||
|
||||
* [Chrome, Firefox & Xvfb](https://hub.docker.com/r/sitespeedio/sitespeed.io/)
|
||||
|
||||
It also contains FFMpeg, Imagemagick so we can record a video and get metrics like SpeedIndex using [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics).
|
||||
It also contains FFMpeg and Imagemagick, so we can record a video and get metrics like SpeedIndex using [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics).
|
||||
|
||||
### Structure
|
||||
The structure looks like this:
|
||||
|
|
@ -28,18 +28,14 @@ The structure looks like this:
|
|||
[NodeJS with Ubuntu 16](https://github.com/sitespeedio/docker-node) -> [VisualMetrics dependencies](https://github.com/sitespeedio/docker-visualmetrics-deps) ->
|
||||
[Firefox/Chrome/xvfb](https://github.com/sitespeedio/docker-browsers) -> [sitespeed.io](https://github.com/sitespeedio/sitespeed.io/blob/master/Dockerfile)
|
||||
|
||||
The first container installs NodeJS (latest LTS) on Ubuntu 16. The next one adds the dependencies (FFMpeg, ImageMagick and some Python libraries) needed to run [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics). Then we install specific version of Firefox, Chrome and then xvfb. It's important to lock down the browsers to specific versions because it has been a real mess using Firefox the last half year (to be fair Chrome/Selenium have also had issues in the past). Then in last step, we add sitespeed and tag it to the sitespeed.io version number.
|
||||
The first container installs NodeJS (latest LTS) on Ubuntu 16. The next one adds the dependencies (FFMpeg, ImageMagick and some Python libraries) needed to run [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics). We then install specific version of Firefox, Chrome and lastly xvfb. Then in last step, we add sitespeed and tag it to the sitespeed.io version number.
|
||||
|
||||
We lock down the browsers to specific versions for maximum compatibility and stability with sitespeed.io's current feature set; upgrading once we verify browser compatibiilty.
|
||||
{: .note .note-info}
|
||||
|
||||
## Running in Docker
|
||||
The simplest way to run using Firefox:
|
||||
|
||||
~~~ bash
|
||||
$ docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io -b firefox https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
That will map the current directory inside Docker and output the result directory there.
|
||||
|
||||
If you wanna use Chrome:
|
||||
The simplest way to run using Chrome:
|
||||
|
||||
~~~ bash
|
||||
$ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io -b chrome https://www.sitespeed.io/
|
||||
|
|
@ -47,46 +43,41 @@ $ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.
|
|||
|
||||
Note: The shm-size increases the memory for the GPU (default is 64mb and that is too small) see [https://github.com/elgalu/docker-selenium/issues/20](https://github.com/elgalu/docker-selenium/issues/20).
|
||||
|
||||
|
||||
If you want to feed sitespeed with a list of URLs in a file (here named *myurls.txt*), add the file to your current directory and do like this:
|
||||
In the real world you should always specify the exact version (tag) of the Docker container to make sure you use the same version for every run. If you use the latest tag you will download newer version of sitespeed.io as they become available, meaning you can have major changes between test runs (version upgrades, dependencies updates, browser versions, etc). So you should always specify a tag after the container name(X.Y.Z). Know that the tag/version number will be the same number as the sitespeed.io release:
|
||||
|
||||
~~~ bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io myurls.txt -b chrome
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:X.Y.Z -b chrome https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
In the real world you should always specify the exact version (tag) of the Docker container to make sure you use the same version everytime (else you will download the latest tag, meaning you can have major changes between test runs without you even knowing). Specify the tag after the container name(X.Y.Z) in this example. The tag/version number will be the same number as the sitespeed.io release:
|
||||
If you want to use Firefox:
|
||||
|
||||
~~~ bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:X.Y.Z https://www.sitespeed.io/ -b chrome
|
||||
$ docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:X.Y.Z -b firefox https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
Using `-v "$(pwd)":/sitespeed.io` will map the current directory inside Docker and output the result directory there.
|
||||
{: .note .note-info}
|
||||
|
||||
|
||||
|
||||
## More about volumes
|
||||
|
||||
If you want to feed sitespeed.io with a file with URLs or if you want the HTML result, you should setup a volume. Sitespeed.io will do all the work inside the container in a directory located */sitespeed.io*. To setup your current working directory add the *-v "$(pwd)":/sitespeed.io* to your parameter list. Using "$(pwd)" will default to the root user directory. In order to specify the location, simply define an absolute path: *-v /Users/user/path:/sitespeed.io*
|
||||
If you want to feed sitespeed.io with a file with URLs or if you want to store the HTML result, you should setup a volume. Sitespeed.io will do all the work inside the container in a directory located at */sitespeed.io*. To setup your current working directory add the *-v "$(pwd)":/sitespeed.io* to your parameter list. Using "$(pwd)" will default to the current directory. In order to specify a statci location, simply define an absolute path: *-v /Users/sitespeedio/html:/sitespeed.io*
|
||||
|
||||
If you run on Windows, it could be that you need to map a absolute path. If you have problems on Windows please check [https://docs.docker.com/docker-for-windows/](https://docs.docker.com/docker-for-windows/).
|
||||
|
||||
## Update (download a newer sitespeed.io)
|
||||
Updating to a newer version is easy, change X.Y.Z to the version you want to use:
|
||||
When using Docker upgrading to a newer version is super easy, change X.Y.Z to the version you want to use:
|
||||
|
||||
~~~ bash
|
||||
docker pull sitespeedio/sitespeed.io:X.Y.Z
|
||||
~~~
|
||||
|
||||
Or alternatively pull the latest version:
|
||||
|
||||
~~~ bash
|
||||
docker pull sitespeedio/sitespeed.io
|
||||
~~~
|
||||
|
||||
And then change your start script (or where you start your container) to use the new version number.
|
||||
|
||||
If you don't use version number (you should!) then just pull the container and your next run will use the latest version.
|
||||
Then change your start script (or where you start your container) to use the new version number.
|
||||
|
||||
## Synchronize docker machines time with host
|
||||
|
||||
If you want to make sure your container have the time as the host, you can do that by adding <code>-v /etc/localtime:/etc/localtime:ro</code> (but you need to be on Linux).
|
||||
If you want to make sure your containers have the same time as the host, you can do that by adding <code>-v /etc/localtime:/etc/localtime:ro</code> (Note: This is specific to Linux).
|
||||
|
||||
Full example:
|
||||
|
||||
|
|
@ -96,7 +87,7 @@ $ docker run --rm -v "$(pwd)":/sitespeed.io -v /etc/localtime:/etc/localtime:ro
|
|||
|
||||
## Change connectivity
|
||||
|
||||
To change connectvity you should use Docker networks, read all about it [here]({{site.baseurl}}/documentation/sitespeed.io/browsers/#change-connectivity).
|
||||
To change connectivity you should use Docker networks, read all about it [here]({{site.baseurl}}/documentation/sitespeed.io/browsers/#change-connectivity).
|
||||
|
||||
## Access localhost
|
||||
|
||||
|
|
@ -109,7 +100,7 @@ $ docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io -b firefox
|
|||
## Troubleshooting
|
||||
|
||||
### Inspect the container
|
||||
In 4.0 we autostart sitespeed.io. If you wanna check what's in the container, you can do that by changing the entry point.
|
||||
In 4.0 we autostart sitespeed.io. If you want to check what's in the container, you can do that by changing the entry point.
|
||||
|
||||
~~~ bash
|
||||
docker run -it --entrypoint bash sitespeedio/sitespeed.io:4.0.0
|
||||
|
|
@ -118,7 +109,7 @@ docker run -it --entrypoint bash sitespeedio/sitespeed.io:4.0.0
|
|||
### Visualize your test in XVFB
|
||||
The docker containers have `x11vnc` installed which enables visualization of the test running inside `Xvfb`. To view the tests, follow these steps:
|
||||
|
||||
- You will need to run the sitespeed.io image by exposing a PORT for vnc server . By default, it is 5900. If you plan to change your port for VNC server, then you need to expose that port.
|
||||
- You will need to run the sitespeed.io image by exposing a PORT for vnc server. By default this port is 5900. If you plan to change your port for VNC server, then you need to expose that port.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=512m --privileged --rm -v "$(pwd)":/sitespeed.io -p 5900:5900 sitespeedio/sitespeed.io https://www.sitespeed.io/ -b chrome
|
||||
|
|
@ -130,7 +121,7 @@ docker run --shm-size=512m --privileged --rm -v "$(pwd)":/sitespeed.io -p 5900:5
|
|||
docker ps
|
||||
~~~
|
||||
|
||||
- Enter into your running docker container for sitespeed.io by executing:
|
||||
- Now enter into your running docker container for sitespeed.io by executing:
|
||||
|
||||
~~~bash
|
||||
docker exec -it <container-id> bash
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ twitterdescription: Test your page using a mobile phone
|
|||
# Prerequisites
|
||||
|
||||
## Desktop
|
||||
* Install the [Android SDK](http://developer.android.com/sdk/index.html#downloads) on your desktop (just the command line tools!). If you are in Mac and use [Homebrew](http://brew.sh/) just run: <code>brew install android-platform-tools</code>
|
||||
* Install the [Android SDK](http://developer.android.com/sdk/index.html#downloads) on your desktop (just the command line tools!). If you are on a Mac and use [Homebrew](http://brew.sh/) just run: <code>brew install android-platform-tools</code>
|
||||
* Start the adb-server on your desktop: <code>adb start-server</code>
|
||||
|
||||
## On your phone
|
||||
|
|
@ -28,11 +28,11 @@ twitterdescription: Test your page using a mobile phone
|
|||
* Enable Stay awake
|
||||
* Enable USB debugging in the device system settings, under Developer options.
|
||||
* Install the [Stay Alive app](https://play.google.com/store/apps/details?id=com.synetics.stay.alive) and start it.
|
||||
* Plugin your phone using the USB port on your desktop computer.
|
||||
* Plug in your phone using the USB port on your desktop computer.
|
||||
* When you plugin your phone, click OK on the "Allow USB debugging?" popup.
|
||||
|
||||
# Run
|
||||
You are now ready to run your and test on your phone:
|
||||
You are now ready to test using your phone:
|
||||
|
||||
~~~bash
|
||||
$ sitespeed.io --browsertime.chrome.android.package com.android.chrome https://www.sitespeed.io
|
||||
|
|
@ -48,10 +48,10 @@ If you run by default, the phone will use the current connection. The connectivi
|
|||
3. Start TSProxy and bind it to your IP: <code>python tsproxy.py --bind 10.0.1.7 --rtt=200 --inkbps=1600 --outkbps=768</code>
|
||||
4. Run <code>$ sitespeed.io --browsertime.chrome.android.package com.android.chrome --browsertime.chrome.args proxy-server="socks://10.0.1.7:1080" https://www.sitespeed.io</code>
|
||||
|
||||
You could also use [phuedxs](https://github.com/phuedx) [Micro Device Lab](https://github.com/phuedx/micro-device-lab) but that is more work at the moment.
|
||||
You could also use [phuedxs](https://github.com/phuedx) [Micro Device Lab](https://github.com/phuedx/micro-device-lab), but using that requires additional work.
|
||||
|
||||
# Video and SpeedIndex
|
||||
You can also collect a video and get Visual Metrics from your run. The current version doesn't support Docker so you need to install the requirements for [VisualMetrics](https://github.com/sitespeedio/docker-visualmetrics-deps/blob/master/Dockerfile) yourself on your machine before you start. If you have everything setup you can run:
|
||||
You can also collect a video and get Visual Metrics. The current version doesn't support Docker so you need to install the requirements for [VisualMetrics](https://github.com/sitespeedio/docker-visualmetrics-deps/blob/master/Dockerfile) yourself on your machine before you start. If you have everything setup you can run:
|
||||
|
||||
~~~bash
|
||||
$ sitespeed.io --browsertime.chrome.android.package com.android.chrome --video --speedIndex https://www.sitespeed.io
|
||||
|
|
|
|||
|
|
@ -15,17 +15,17 @@ twitterdescription: Upgrade 3 -> 4
|
|||
* Lets place the TOC here
|
||||
{:toc}
|
||||
|
||||
Upgrading is just updating to the new version. There's a couple of important thing that has changed.
|
||||
Upgrading to the newest version from 3.x? There are a couple of important things that have changed.
|
||||
|
||||
## Graphite keys
|
||||
The keys in Graphite has a new structure. The reason is that we wants to have a generic solution where we can use the same dashboards for whatever site and we want to follow the new data structure. If old data is important to you, you need to run multiple instances for a while, one with 3.x and one with 4 and have multiple dashboards, and then when you have the history, make the switch to the 4.0 dashboards.
|
||||
The keys in Graphite have a new structure. The reason for this is that we wants to have a generic solution where we can use the same dashboards for any site. If old data is important to you, you will need to run multiple instances for a while, one with 3.x and one with 4/5.x and have multiple dashboards, once you are comfortable with the newer dashboards and have the history, make the switch to the 4/5.x dashboards.
|
||||
|
||||
## CLI mapping
|
||||
A lot changed in the CLI and the easiest way for you is just to run sitespeed.io with <code>--help</code> to see what you can use. You can also check this mapping.
|
||||
A lot has changed in the CLI and the easiest way for you to understand what options are available is to just run sitespeed.io with <code>--help</code>. You can also check this mapping to get an idea of what has changed.
|
||||
|
||||
<div id="upgradeTable" markdown="1">
|
||||
|
||||
| 3.x | 4.0 | Description |
|
||||
| 3.x | 4.x / 5.x | Description |
|
||||
|:------------|:-------------------|:-------------|
|
||||
| `-u <URL>, --url <URL>` | N/A | The start url that will be used when crawling. |
|
||||
| `-f <FILE>, --file <FILE>` | N/A | The path to a plain text file with one URL on each row. Each URL will be analyzed. |
|
||||
|
|
@ -96,7 +96,7 @@ A lot changed in the CLI and the easiest way for you is just to run sitespeed.io
|
|||
|
||||
## Docker
|
||||
|
||||
With the new container you don't need to tell it to start sitespeed.io, just do:
|
||||
With the 4/5.x containers you no longer need to tell it to start sitespeed.io:
|
||||
|
||||
~~~ bash
|
||||
$ docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/
|
||||
|
|
|
|||
|
|
@ -16,12 +16,15 @@ twitterdescription: Drive WebPageTest using sitespeed.io and include the metrics
|
|||
{:toc}
|
||||
|
||||
## Using WebPageTest
|
||||
We still love [WebPageTest](https://www.webpagetest.org/) (WPT), so you can drive WebPageTest through sitespeed.io. You will get a WebPageTest tab for each result and if you are using Graphite, WebPageTest metrics will be automagically sent.
|
||||
We still love [WebPageTest](https://www.webpagetest.org/) (WPT), so you can drive WebPageTest through sitespeed.io. When including WPT you will get a tab for each result and if you are using Graphite, WebPageTest metrics will be automatically sent.
|
||||
|
||||
To use WPT you can either get an [API key](https://www.webpagetest.org/getkey.php) (sponsored by Akamai) for the global version or follow Pat Meenans instructions on how to get [a private version up and running in 5 minutes](http://calendar.perfplanet.com/2014/webpagetest-private-instances-in-five-minutes/). Or read how [WikiMedia setup an instance using AWS](https://wikitech.wikimedia.org/wiki/WebPageTest).
|
||||
To use WPT you have a few options
|
||||
- You can get an [API key](https://www.webpagetest.org/getkey.php) (sponsored by Akamai) for the public version
|
||||
- Follow Pat Meenans instructions on how to get [a private version up and running in 5 minutes](http://calendar.perfplanet.com/2014/webpagetest-private-instances-in-five-minutes/).
|
||||
- Read how [WikiMedia setup an instance using AWS](https://wikitech.wikimedia.org/wiki/WebPageTest).
|
||||
|
||||
## Configuration
|
||||
Internally sitespeed.io uses the [WebPageTest API](https://github.com/marcelduran/webpagetest-api) so you can do almost all the same thing as with the standalone API.
|
||||
Internally sitespeed.io uses the [WebPageTest API](https://github.com/marcelduran/webpagetest-api), so you can do almost all the same thing as with the standalone API.
|
||||
|
||||
By default we have the following configuration options:
|
||||
|
||||
|
|
@ -38,7 +41,7 @@ By default we have the following configuration options:
|
|||
|
||||
If you need anything else adding your own CLI parameter will propagate to the WebPageTest API. Checkout the different [options](https://github.com/marcelduran/webpagetest-api#test-works-for-test-command-only) for the API.
|
||||
|
||||
Example: Say that you want to change the user agent of your test. In the API you can do that with <code>--useragent</code>. Pass the same to sitespeed.io by adding <code>--webpagetest.useragent</code> in the cli.
|
||||
Example: So say that you want to change the user agent of your test. In the API you can do that with <code>--useragent</code>. Pass the same to sitespeed.io by prefixing webpagetest like so <code>--webpagetest.useragent</code> in the cli.
|
||||
|
||||
~~~ bash
|
||||
$ sitespeed.io --webpagetest.host my.wpt.host.com --webpagetest.useragent "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36" https://www.sitespeed.io
|
||||
|
|
@ -65,7 +68,7 @@ You can override these with parameters. If you want to change the location, just
|
|||
|
||||
### WebPageTest scripting
|
||||
|
||||
WebPageTest has scripting capability where you can automate a multi-step test (login as a user and do some interaction). That is supported by sitespeed.io by supplying the script. You can do so like this:
|
||||
WebPageTest has scripting capability where you can easily automate a multi-step test (e.x. login as a user and do some interaction). That is supported by sitespeed.io by supplying the script. You can do so like this:
|
||||
|
||||
You can create your script file (checkout [WebPageTest documentation](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/scripting) for what you can do). It can look something like this (wptScript.txt):
|
||||
|
||||
|
|
@ -82,7 +85,7 @@ logData 1
|
|||
navigate news.aol.com/world
|
||||
~~~
|
||||
|
||||
Then change your URL you want test (probably the last one) to \{\{\{URL\}\}\} and then all occurrences of \{\{\{URL\}\}\} will then be replaced with the current URL that should be tested. Then run sitespeed.io (and add the parameters as you usually do):
|
||||
Then change your URL you want test (probably the last one) to \{\{\{URL\}\}\} and then all occurrences of \{\{\{URL\}\}\} will then be replaced with the current URL that should be tested. Now run sitespeed.io with the additional parameters:
|
||||
|
||||
~~~ bash
|
||||
sitespeed.io --webpagetest.file wptScript.txt --webpagetest.host my.wpt.host.com http://example.org
|
||||
|
|
@ -117,7 +120,7 @@ for (var i = 0; i < metaTags.length; i++) {
|
|||
return viewport;
|
||||
~~~
|
||||
|
||||
You can then run sitespeed.io like this to pick up the new custom metrics:
|
||||
You can then run sitespeed.io to pick up the new custom metrics:
|
||||
|
||||
~~~ bash
|
||||
$ sitespeed.io --webpagetest.custom myScriptFile.txt --webpagetest.host my.wpt.host.com https://www.sitespeed.io
|
||||
|
|
|
|||
Loading…
Reference in New Issue