diff --git a/.gitignore b/.gitignore index d66f54df18..2ec9390c97 100644 --- a/.gitignore +++ b/.gitignore @@ -5,3 +5,4 @@ node_modules .vscode sitespeed-result configs +docs/_site \ No newline at end of file diff --git a/docs/3.x/browsers/index.md b/docs/3.x/browsers/index.md new file mode 100644 index 0000000000..e4e976b6f4 --- /dev/null +++ b/docs/3.x/browsers/index.md @@ -0,0 +1,96 @@ +--- +layout: default +title: Browsers - Documentation - sitespeed.io +description: How to get browser timings using sitespeed.io for Firefox, Chrome, Safari and Internet Explorer. +keywords: browsers, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Browser timings for the sitespeed.io. +--- +[Documentation 3.x](/documentation/) / Browsers + +# Browsers +{:.no_toc} + +* Lets place the TOC here +{:toc} + +You can fetch timings and execute your own Javascript. The following browsers are supported: +Firefox, Chrome, Internet Explorer and Safari. + +## Firefox +Firefox will work out of the box, as long as you have Firefox installed on your machine. + +## Chrome +You need to install Chrome and the [Chromedriver](https://sites.google.com/a/chromium.org/chromedriver/) to be able to collect metrics from Chrome. + +## Internet Explorer +Windows only. To get Internet Explorer to work, follow the [instructions](https://code.google.com/p/selenium/wiki/InternetExplorerDriver#Required_Configuration). + +## Safari +You need Safari 8 to get timings from your browser (Mac only). To get it to work, you need to install the [SafariDriver extension - SafariDriver.safariextz](http://selenium-release.storage.googleapis.com/index.html?path=2.45/) in your browser. With the current version no HAR-file is created. + +# Fetching timings +You can fetch timings ([Navigation Timing](http://www.w3.org/TR/navigation-timing/) and [User Timings](http://www.w3.org/TR/user-timing/)) using using the **-b** flag. We use [Browsertime](https://github.com/tobli/browsertime) to collect the data. + +~~~ bash +$ sitespeed.io -u http://yoursite.com -b firefox +~~~ + +What we do is run a couple of [Javascripts](https://github.com/tobli/browsertime/tree/master/lib/scripts) that collects metrics from the browser. The browser stops collecting metrics when the *window.performance.timing.loadEventEnd* happens (but you can configure that yourself). + +## Simulate the connection speed +You can throttle the connection when you are fetching metrics using the browser. Choose between: + +* **mobile3g** - 1.6 Mbps/768 Kbps - 300 RTT +* **mobile3gfast** - 1.6 Mbps/768 Kbps - 150 RTT +* **cable** - 5 Mbps/1 Mbps - 28 RTT +* **native** - the current connection + +And run it like this: + +~~~ bash +$ sitespeed.io -u http://yoursite.com -b chrome --connection mobile3g +~~~ + +## Choose when to end your test +By default the browser will collect data until the *window.performance.timing.loadEventEnd* happens + aprox 2 seconds more. That is perfectly fine for most sites, but if you do ajax loading and you mark them with user timings, you probably want to include them in your test. Do that by changing the script that will end the test (*--waitScript*). When the scripts returns true the browser will close or if the timeout time (default 60 seconds) will be reached: + +~~~ bash +sitespeed.io -u https://www.sitespeed.io -b chrome --waitScript 'return window.performance.timing.loadEventEnd>0' +~~~ + + +## Custom metrics +You can collect your own metrics in the browser by supplying a directory with Javascript files. Each file need to return a metric/value and it will be picked up and returned in the JSON. If you return a number, statistics will automatically be generated for the value (like median/percentiles etc). Check out the [scripts](https://github.com/tobli/browsertime/tree/master/scripts) we use. + +Say we have a folder called *scripts* and in there we have one file called *scripts.js* that checks how many javascript that is loaded. The script looks like this: + +~~~ +return document.getElementsByTagName("script").length; +~~~ + +Then to pick up the script, run like this: + +~~~ bash +sitespeed.io -u https://www.sitespeed.io --customScripts scripts -b firefox +~~~ + +The basename of the file *script* will be used as the metric name. If the script return a number, the value will be sent to Graphite and will be summarized on the summary page. Other values will be shown on the specific result page. + +# Collected timing metrics +All the metrics are collected using an empty cache. + +* *backEndTime* - The time it takes for the network and the server to generate and start sending the HTML. Definition: responseStart - navigationStart +* *domContentLoadedTime* - The time the browser takes to parse the document and execute deferred and parser-inserted scripts including the network time from the users location to your server. Definition: domContentLoadedEventStart - navigationStart +* *domInteractiveTime* - The time the browser takes to parse the document, including the network time from the users location to your server. Definition: domInteractive - navigationStart +* *domainLookupTime* - The time it takes to do the DNS lookup. Definition: domainLookupEnd - domainLookupStart +* *frontEndTime* - The time it takes for the browser to parse and create the page. Definition: loadEventStart - responseEnd +* *pageDownloadTime* - How long time does it take to download the page (the HTML). Definition: responseEnd - responseStart +* *pageLoadTime* - The time it takes for page to load, from initiation of the page view (e.g., click on a page link) to load completion in the browser. Important: this is only relevant to some pages, depending on how you page is built. Definition: loadEventStart - navigationStart +* *redirectionTime* - Time spent on redirects. Definition: fetchStart - navigationStart +* *serverConnectionTime* - How long time it takes to connect to the server. Definition: connectEnd - connectStart +* *firstPaint* - This is when the first paint happens on the screen. If the browser support this metric, we use that. Else we use the time of the last non-async script or css from the head. You can easily verify if the first paint metrics is valid for you, by record a video using WebPageTest, and then check exactly when the first paint happens and compare that with the timing from the browser. +* [RUM-SpeedIndex](https://github.com/WPO-Foundation/RUM-SpeedIndex) - created by Pat Meenan +and calculate SpeedIndex measurements using Resource Timings. It iss not as perfect as Speed Index in WPT but a good start. diff --git a/docs/3.x/configuration/index.md b/docs/3.x/configuration/index.md new file mode 100644 index 0000000000..0fd7512190 --- /dev/null +++ b/docs/3.x/configuration/index.md @@ -0,0 +1,372 @@ +--- +layout: default +title: Configuration - Documentation - sitespeed.io +description: How to configure sitespeed.io +keywords: configuration, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Configuration for the sitespeed.io. +--- +[Documentation 3.x](/documentation/) / Configuration + +# Configuration +{:.no_toc} + +* Lets place the TOC here +{:toc} + +# Configuration +Sitespeed.io is highly configurable, let's check it out! + +## The options +You have the following options running sitespeed.io: + +~~~help +Usage: node sitespeed.js [options] + +Options: + -u , --url The start url that will be used when crawling. + -f , --file The path to a plain text file with one URL on each row. Each URL will be analyzed. + --sites The path to a plain text file with one URL on each row. You can use the parameter multiple times to point out many files + -V, --version Display the sitespeed.io version. + --silent Only output info in the logs, not to the console. + -v, --verbose Enable verbose logging. + --noColor Don't use colors in console output. [false] + -d , --deep How deep to crawl. [1] + -c , --containInPath Only crawl URLs that contains this in the path. + -s , --skip Do not crawl pages that contains this in the path. + -t , --threads The number of threads/processes that will analyze pages. [5] + --name Give your test a name, it will be added to all HTML pages. + --memory How much memory the Java processed will have (in mb). [256] + -r , --resultBaseDir The result base directory, the base dir where the result ends up. [sitespeed-result] + --outputFolderName Default the folder name is a date of format yyyy-mm-dd-HH-MM-ss + --suppressDomainFolder Do not use the domain folder in the output directory + --userAgent The full User Agent string, default is Chrome for MacOSX. [userAgent|ipad|iphone]. [Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36] + --viewPort The view port, the page viewport size WidthxHeight like 400x300. [1280x800] + -y , --yslow The compiled YSlow file. Use this if you have your own rules. + --headless Choose which backend to use for headless [phantomjs|slimerjs] [phantomjs] + --ruleSet Which ruleset to use. [sitespeed.io-desktop] + --limitFile The path to the limit configuration file. + --basicAuth Basic auth user & password. + -b , --browser Choose which browser to use to collect timing data. Use multiple browsers in a comma separated list (firefox|chrome|headless) + --connection Limit the speed by simulating connection types. Choose between mobile3g,mobile3gfast,cable,native [cable] + --waitScript Supply a javascript that decides when a browser run is finished. Use it to fetch timings happening after the loadEventEnd. [ if (window.performance && window.performance.timing){ return ((window.performance.timing.loadEventEnd > 0) && ((new Date).getTime() - window.performance.timing.loadEventEnd > 2000 ));} else { return true;}] + --customScripts The path to an extra script folder with scripts that will be executed in the browser. See https://www.sitespeed.io/documentation/browsers/#custom-metrics + --seleniumServer URL Configure the path to the Selenium server when fetching timings using browsers. If not configured the supplied NodeJS/Selenium version is used. + --btConfig Additional BrowserTime JSON configuration as a file + --profile Choose between testing for desktop or mobile. Testing for desktop will use desktop rules & user agents and vice verca. [desktop] + -n , --no The number of times you should test each URL when fetching timing metrics. Default is 3 times. [3] + --screenshot Take screenshots for each page (using the configured view port). + --junit Create JUnit output to the console. + --tap Create TAP output to the console. + --skipTest A comma separated list of rules to skip when generating JUnit/TAP/budget output. + --testData Choose which data to send test when generating TAP/JUnit output or testing a budget. Default is all available [rules,page,timings,wpt,gpsi] [all] + --budget A file containing the web perf budget rules. See https://www.sitespeed.io/documentation/performance-budget/ + -m , --maxPagesToTest The max number of pages to test. Default is no limit. + --storeJson Store all collected data as JSON. + -p , --proxy http://proxy.soulgalore.com:80 + --cdns A comma separated list of additional CDNs. + --postTasksDir The directory where you have your extra post tasks. + --boxes The boxes showed on site summary page, see https://www.sitespeed.io/documentation/configuration/#configure-boxes-on-summary-page + -c , --columns The columns showed on detailed page summary table, see https://www.sitespeed.io/documentation/configuration/#configure-columns-on-pages-page + --configFile The path to a sitespeed.io config.json file, if it exists all other input parameters will be overridden. + --aggregators The path to a directory with extra aggregators. + --collectors The path to a directory with extra collectors. + --graphiteHost The Graphite host. + --graphitePort The Graphite port. [2003] + --graphiteNamespace The namespace of the data sent to Graphite. [sitespeed.io] + --graphiteData Choose which data to send to Graphite by a comma separated list. Default all data is sent. [summary,rules,pagemetrics,timings,requests,domains] [all] + --graphiteUseQueryParameters Choose if you want to use query paramaters from the URL in the Graphite keys or not + --graphiteUseNewDomainKeyStructure Use the updated domain section when sending data to Graphite "http.www.sitespeed.io" to "http.www_sitespeed_io" (issue #651) + --gpsiKey Your Google API Key, configure it to also fetch data from Google Page Speed Insights. + --noYslow Set to true to turn off collecting metrics using YSlow. + --html Create HTML reports. Default to true. Set no-html to disable HTML reports. [true] + --wptConfig WebPageTest configuration, see https://github.com/marcelduran/webpagetest-api runTest method + --wptScript WebPageTest scripting. Every occurance of \{\{\{URL\}\}\} will be replaced with the real URL. + --wptCustomMetrics Fetch metrics from your page using Javascript + --wptHost The domain of your WebPageTest instance. + --wptKey The API key if running on webpagetest on the public instances. + --requestHeaders |
Any request headers to use, a file or a header string with JSON form of {"name":"value","name2":"value"}. Not supported for WPT & GPSI. + --postURL The full URL where the result JSON will be sent by POST. Warning: Testing many pages can make the result JSON massive. + --phantomjsPath The full path to the phantomjs binary, to override the supplied version +~~~ + +Yep, that was a lot, we know. Lets go into some standard use cases. + +## The basics +If you installed with the global option (-g), run the command *sitespeed.io* else run the script *lib/sitespeed.js*. In the examples we will use the script but you know what to do if you have it installed. + +You can analyze a site either by crawling or feed sitespeed.io with the URL:s you want to analyze. + +### Analyze by crawling +The crawler needs a start URL (the parameter **u**, from where it will start the crawl). It will fetch all links within the same domain as the URL that you provide. You can then choose how deep you want to crawl with the **d** parameter. Zero will fetch only the + URL that you provide. One will fetch all links on that page and analyze these, two will go one level deeper and so on. If you want to analyze a site and the links with a depth of two, you do like this: + +~~~ bash +$ sitespeed.io -u http://www.yoursite.com -d 2 +~~~ + +Remember that you can start your crawl deep into your path structure like http://yoursite.com/my/path +{: .note .note-info} + +### Analyze by URL:s +Instead of giving a start URL for the crawl, you can supply a plain text file with one URL on each row. Then each of these URL will be analyzed, no more or no less. A file like this will do: + +~~~ +http://www.yoursite.com/path/ +http://www.yoursite.com/my/really/important/page/ +http://www.yoursite.com/where/we/are/ +~~~ + +Then you feed the file to the script: + +~~~ bash +$ sitespeed.io -f myurls.txt +~~~ + +This is good for testing and keep tracks of your site in production and you have a LARGE site with many pages and a couple of them are more important than the rest. +{: .note .note-info} + +### Analyze sites and benchmark +If you want to test and benchmark sites you can do like this: + +~~~ +http://www.yoursite.com/path/ +http://www.mycompetition.com/ +http://www.mycompetition2.com/ +~~~ + +Then you feed the file to the script and each URL will be crawled. You can run the crawl the exact same way as usual, by feeding parameters. + +~~~ bash +$ sitespeed.io --sites mysitesurls.txt +~~~ + +If you instead want to compare a couple specific URL:s between sites (pre defined URL:s instead of crawling), do like this: Create multiple plain text files with URL:s on each line: + + +Here's theguardian.txt: + +~~~ +http://www.theguardian.com/uk +http://www.theguardian.com/uk/sport +http://www.theguardian.com/uk/culture +~~~ + +And nytimes.txt: + +~~~ +http://www.nytimes.com/ +http://www.nytimes.com/pages/sports/index.html +http://www.nytimes.com/pages/fashion/index.html +~~~ + +You can of course add how many URL:s and sites you want. Then you run the whole thing like this: + +~~~ bash +$ sitespeed.io --sites theguardian.txt --sites nytimes.txt -d 0 +~~~ + +Notice the -d 0 will tell sitespeed that we want to test the exact URL:s. + + +### Include/exclude URL:s when crawling +You want to make sure that parts of your site isn't included in your analyze, then you can add the parameter **s** and a keyword. Every URL with that keyword will not be included. + +~~~ bash +$./bin/sitespeed.io -u http://yoursite.com -s /monkey/ +~~~ +You can also do it the other way around, with the **c** and a keyword. In this case, the analyze will only include URL:s with the keyword. + +~~~ bash +$ ./bin/sitespeed.io -u http://yoursite.com -c /the/path/ +~~~ + +### Screenshots +You can get screenshots of every page that you analyze. These will end up on a screenshot page where you can check them all. The screenshots will be taken for the chosen viewport. + +~~~ bash +$ sitespeed.io -u http://yoursite.com --screenshot +~~~ + +### Shortcut: test as desktop or mobile +By default you test as desktop, if you turn on mobile by just setting the profile. If you do that, you will automatically test with +mobile rules, an IOS user agent, view port of 320x444 and on a throttled connection simulating a mobile 3g connection. + +~~~ bash +$ sitespeed.io -u http://yoursite.com --profile desktop +~~~ + +~~~ bash +$ sitespeed.io -u http://yoursite.com --profile mobile +~~~ + +### Viewport/user agent and mobile +You can set the viewport & user agent, so that you can fake testing a site as a mobile device. + +By default the viewport is 1280x800 with the following user agent for Chrome on MacOSX. + +~~~ bash +$ sitespeed.io -u http://yoursite.com --viewPort 400x300 --userAgent "My SUPER BROWSER" +~~~ + + +Mobile testing is always best on mobile devices. For tips on how to best do that, read Andy Davies [blog](http://andydavies.me/). +{: .note .note-warning} + +### Limit pages to test +Sometimes you want to limit the amount to test (I do that when I compare sites). That will test maximum the amount of pages you supply. + +~~~ bash +$ sitespeed.io -u http://yoursite.com -m 10 +~~~ + +### Set a name of your test +You can give your test run a name that will be showed on all the pages + +~~~ bash +$ sitespeed.io -u http://yoursite.com/ --name "Swedens top 100 sites" +~~~ + +### Collect timing metrics +Sitespeed.io collect timing metrics using the Navigation Timing API and the User Timing API. Today you can use Chrome, Firefox, PhantomJS 2.0 and SlimerJS. We also have exprimental support for Internet Explorer (ie) and Safari. + +Add the parameter **b** followed by the browser name. + +~~~ bash +$ sitespeed.io -u http://yoursite.com -b firefox +~~~ + +Each page is tested 3 times by default. You can change that with the **n** parameter. Test using Chrome and test each page 9 times, looks like this: + +~~~ bash +$ sitespeed.io -u http://yoursite.com -b chrome -n 9 +~~~ + +If you want to test in multiple browsers, you add them in a comma separated list + +~~~ bash +$ sitespeed.io -u http://yoursite.com -b firefox,chrome -n 7 +~~~ + +### Throttle the connection +You can throttle the connection when you are fetching metrics using the browser. Choose between: + +* **mobile3g** - 1.6 Mbps/768 Kbps - 300 RTT +* **mobile3gfast** - 1.6 Mbps/768 Kbps - 150 RTT +* **cable** - 5 Mbps/1 Mbps - 28 RTT +* **native** - the current connection + +And do like this: + +~~~ bash +$ sitespeed.io -u http://yoursite.com -b chrome --connection mobile3g +~~~ + +## A little more nerdy + +### Fetch data Google Page Speed Insights +To test each page using GPSI, you need to have a a Google API Key. You can get one [here](https://console.developers.google.com/project). Testing using GPSI will + include the GPSI score in the summary page and all individual data on the detailed page. + + +~~~ bash +$ sitespeed.io -u http://yoursite.com --gpsiKey MY_SECRET_KEY +~~~ + +### Fetch data from WebPageTest + +Yep, it is true! You can drive WebPageTest from sitespeed.io. You need to either have your own private instance or an API key. + +~~~ bash +$ sitespeed.io -u http://yoursite.com --wptHost www.webpagetest.org --wptKey MY_SECRET_API_KEY +~~~ + +In the background Marcel Durans WPT API is used, specific the [runTest](https://github.com/marcelduran/webpagetest-api#user-content-test-works-for-test-command-only) method. + You can pass all the parameters in the runTest through sitespeed.io by the **--wptConfig** parameter and supply a JSON file. + + +By default, the following values are passed to WPT: + +~~~ +pollResults: 10, +timeout: 600, +firstViewOnly: false, +runs: // the number of runs you configure by the n parameter +private: true, +aftRenderingTime: true, +location: 'Dulles:Chrome', +video: true +~~~ + +And if you configured basic auth, the login/password is also passed to WPT. + +If you pass your own **--wptConfig**, a fields matching will override the default configuration. + + +### Send your data to Graphite + +You can choose to send your data to Graphite, to keep track of your performance over time. +You configure four things: the host, port, the namespace and which data to send. Default value for the port is 2003, namespace (the start of the key) is sitespeed and send all collected data. + +~~~ bash +$ sitespeed.io -u https://www.sitespeed.io --graphiteHost localhost +~~~ + +### Set request headers +The headers can be set if you collect rules and timings. It will not work for WPT and GPSI. Supply a JSON file like this: + +~~~ +{ + "mysupercoolheader":"value", + "coolheader2":"value2" +} +~~~ + +And the run like this: + +~~~ bash +$ sitespeed.io -u https://www.sitespeed.io --requestHeaders myheaders.txt +~~~ + +### Configure boxes on summary page +You can choose which boxes you want to show on the summary page by configure them by their name. You can choose to show to configure them exactly as you want. Then you need to pass every name to the script: + +~~~ bash +$ sitespeed.io -u https://www.sitespeed.io --boxes thirdpartyversions,ycdn +~~~ + +Or if you want to add boxes to the already pre-configured ones, you can add a plus sign before the name(it is perfect + if you have your own User Timings that you want to show): + +~~~ bash +$ sitespeed.io -u https://www.sitespeed.io -b chrome --boxes +logoTime,headerTime +~~~ + +These boxes will then end up in the end of the list. + +### Configure columns on pages page +You can choose what kind of data you want to show in the column pages. The naming is far from perfect today or you could say it's broken, lets change that in coming major releases. + +If you want to show data that are collected from YSlow, like number of javascripts, you do that like this: + +~~~ bash +$ sitespeed.io -u https://www.sitespeed.io -c yslow.assets.js,yslow.assets.css,yslow.requests,yslow.pageWeight +~~~ + +If you want to fetch timings from your browser, they are following this pattern (headerTime is a User Timing): + +~~~ bash +$ sitespeed.io -u https://www.sitespeed.io -c timings.serverResponseTime.median,timings.domContentLoadedTime.median,timings.headerTime.median -b chrome +~~~ + +If you want to show metric collected from WebPageTest they are published under the following structure: wpt[location][browser][connectivity][view][timing] and the metrics names are the exact same they have in the WebPageTest API (we collect 'SpeedIndex', 'firstPaint', 'render', 'TTFB', 'visualComplete', 'domContentLoadedEventEnd' and 'loadTime'). + +So if you want to display speed index for first and repeated view tested from Dulles using Chrome and Cable, you need to configure the columns like this: + +~~~ bash +-c wpt.dulles.chrome.cable.firstView.SpeedIndex,wpt.dulles.chrome.cable.repeatView.SpeedIndex +~~~ + +If you have problem, [create an issue](https://github.com/sitespeedio/sitespeed.io/issues/new) and we will help you. diff --git a/docs/3.x/continuous-integration/add-build-step-jenkins.png b/docs/3.x/continuous-integration/add-build-step-jenkins.png new file mode 100644 index 0000000000..9c92d30dbb Binary files /dev/null and b/docs/3.x/continuous-integration/add-build-step-jenkins.png differ diff --git a/docs/3.x/continuous-integration/index.md b/docs/3.x/continuous-integration/index.md new file mode 100644 index 0000000000..e1dc5da31a --- /dev/null +++ b/docs/3.x/continuous-integration/index.md @@ -0,0 +1,153 @@ +--- +layout: default +title: Continuous integration - Documentation - sitespeed.io +description: Use sitespeed.io in your Continuous Integration setup with Jenkins, Grunt or Team City. +keywords: Continuous Integration, jenkins, grunt, team city, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Use sitespeed.io in your Continuous Integration setup. +--- +[Documentation 3.x](/documentation/) / Continous Intergration + +# Continuous integration +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Use sitespeed.io to keep track of what is happening with your site and make sure you know that you don't break the performance best practice rules **before** your changes are released. +Your build can also be broken if your page timings (choose whatever timing you need from the Navigation Timing API or your own custom timing) break your limits. And of course, if you use WebPageTest or Google Page Speed Insights, you can use the metrics from them to break your build. + +Sitespeed.io outputs [JUnit XML](http://help.catchsoftware.com/display/ET/JUnit+Format) and [TAP](http://testanything.org/) that test your metrics against your configured limits. + + +## Generating JUnit XML or TAP +Sitespeed can output **junit.xml** that works perfect with your continuous integration tool. Jenkins, Bamboo and others support it out of the box. + +~~~bash +$ sitespeed.io -u https://www.sitespeed.io --junit +~~~ + +Or if you rather prefer TAP: + +~~~bash +$ sitespeed.io -u https://www.sitespeed.io --tap +~~~ + +## Configure when to break a test +By default these are the values that are tested: + +~~~ +{ + "rules": { + "default": 90 + }, + "timings": { + "serverResponseTime": 300, + "domContentLoadedTime": 700, + "speedIndex": 1000 + }, + "wpt": { + "SpeedIndex": 1000 + }, + "gpsi": { + "score": 90 + } +} +~~~ + +This means that all rules must be 90 or better,serverResponseTime 300 ms or better, +domContentLoadedTime to be faster than 700 ms. If you use WebPageTest, the speed index need to be under 1000. And finally, if you use Goggle Page Speed Insights, the score must be 90 or better. + + +You can configure to point out a JSON file containing all the values: + +~~~bash +$ sitespeed.io -u https://www.sitespeed.io --tap --budget myBudget.json +~~~ + +## Skip rule tests +By default a all rules is tested against the default number you specify, meaning all rules needs to be 90 or better. Sometimes you have some rules you don't care about and can skip. You do that by feeding the rule names to the script. You find all the names [here](https://github.com/sitespeedio/yslow/blob/master/src/common/rulesets/ruleset_sitespeed.js). + +~~~bash +$ sitespeed.io -u https://www.sitespeed.io --skipTest ycdn,textcontent --tap +~~~ + +## Jenkins +You have can use sitespeed.io in [Jenkins](http://jenkins-ci.org/") either by running as a CLI (*Execute shell*) or by using the [sitespeed.io plugin](https://github.com/sitespeedio/jenkins.sitespeed.io). + +You want the browsers to run headless, use the [Xvfb plugin](https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin) to make it happen! + + +### Running as CLI + +* 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 sitespeed.io CLI magic. Remember that the Jenkins user needs to have NodeJS in the path. It can look like this (sending the data to a local Graphite instance): + +~~~ +sitespeed.io -u http://www.cybercom.com --graphiteHost localhost --graphiteNamespace cybercom-production -b chrome -n 11 +~~~ + +* If you want to break your build, you can either generate JUnit XML and use the built in post task **Publish JUnit test result report**. +* In the execute shell form: *sitespeed.io -u http://stage.cybercom.com --resultBaseDir ${WORKSPACE}/${BUILD_NUMBER} --junit > junit.xml* And in the post task **Test report XMLs** add: *junit.xml* +* Using TAP, you need to install the [TAP plugin](https://wiki.jenkins-ci.org/display/JENKINS/TAP+Plugin). +* Run the execute shell like this *sitespeed.io -u http://stage.cybercom.com --resultBaseDir ${WORKSPACE}/${BUILD_NUMBER} --tap > sitespeed.tap* +* And choose the post task **Publish TAP Results** and in the Test Results box add: *sitespeed.tap* + +### Jenkins plugin +The Jenkins plugin is not yet distributed within Jenkins, so you need to build and install it yourself. Follow [these](https://github.com/sitespeedio/jenkins.sitespeed.io#how-to-run-in-jenkins) instructions on how to do it. Remember that you need to have NodeJS in the path for the user running the plugin and make sure the user has the rights to execute the sitespeed.io executable. + +The plugin focus on breaking your build if your budget doesnt't match the real world. You can choose to output the result as JUnit XML (the file is named **sitespeed.io-junit.xml**), TAP (**sitespeed.io-junit.tap**) or a budget file. If you run *budget* the script will return with a error return code, if your budget breaks. JUnit & TAP will always return ok, so then you need to setup the **Test report XMLs** or the **Publish TAP Results** task to break your build. + + +Add sitespeed.io in your build step: + +![Add sitespeed.io as a build step](add-build-step-jenkins.png) +{: .img-thumbnail} + +You can configure the plugin like this: + +![Configure the plugin](jenkins-plugin-configuration.png) +{: .img-thumbnail} + +And remember, if you output TAP, use the [TAP plugin](https://wiki.jenkins-ci.org/display/JENKINS/TAP+Plugin) or JUnit use the built in **Publish JUnit test result report**. + +## TeamCity + +Here's an example of setting up Team City running sitespeed.io on Windows, thanks [Gustav Tonér](https://github.com/gazab)! + +### Running as CLI + +* Choose **Create build configuration** or edit an existing build configuration. +* Choose **Add build step** under Build Configuration Settings \ Build Step and add a **Command Line** build step. Add your call to sitespeed.io in the **Custom script** box. Remember that the build agent user needs to have NodeJS in their path and have sitespeed.io installed already. The command line could look like this: + +~~~ +sitespeed.io.cmd -u https://www.sitespeed.io +~~~ + +**Screenshot of adding a build step in TeamCity** +![Adding a build step in TeamCity](teamcity-build-step.png) +{: .img-thumbnail} + +### JUnit Reporting +* If you want to have sitespeed.io report back results to TeamCity so your build can break if tests fail you first need to edit your command line to make sitespeed.io generate a JUnit XML file like this: +~~~ +sitespeed.io.cmd -u https://www.sitespeed.io --junit > sitespeedio_result.xml +~~~ +* Then choose **Add build feature** under Build Configuration Settings \ Build Features and add **XML report processing** feature. Set **Report type** to **Ant JUnit** and specify the generated XML report filename in the **Monitoring rules** box. +* TeamCity should now run sitespeed.io and report back its results. + +**Screenshot of adding JUnit reporting in TeamCity** +![Adding JUnit reporting in TeamCity](teamcity-build-feature.png) +{: .img-thumbnail} + +## Travis integration +Coming soon! + + +## Grunt plugin +There's a Grunt plugin [grunt-sitespeedio](https://github.com/sitespeedio/grunt-sitespeedio) where you can do all the things you usually do with sitespeed.io. Use it create HTML-reports, send metrics to Graphite or test your performance budget. + +## Gulp plugin +Checkout the [gulp-sitespeedio](https://www.npmjs.com/package/gulp-sitespeedio) plugin created by [Ankit Singhal](https://github.com/dreamzmaster). diff --git a/docs/3.x/continuous-integration/jenkins-plugin-configuration.png b/docs/3.x/continuous-integration/jenkins-plugin-configuration.png new file mode 100644 index 0000000000..269f10de04 Binary files /dev/null and b/docs/3.x/continuous-integration/jenkins-plugin-configuration.png differ diff --git a/docs/3.x/continuous-integration/teamcity-build-feature.png b/docs/3.x/continuous-integration/teamcity-build-feature.png new file mode 100644 index 0000000000..22303ec480 Binary files /dev/null and b/docs/3.x/continuous-integration/teamcity-build-feature.png differ diff --git a/docs/3.x/continuous-integration/teamcity-build-step.png b/docs/3.x/continuous-integration/teamcity-build-step.png new file mode 100644 index 0000000000..9326d9419b Binary files /dev/null and b/docs/3.x/continuous-integration/teamcity-build-step.png differ diff --git a/docs/3.x/developers/index.md b/docs/3.x/developers/index.md new file mode 100644 index 0000000000..a595fe01cd --- /dev/null +++ b/docs/3.x/developers/index.md @@ -0,0 +1,199 @@ +--- +layout: default +title: Developers - Documentation - sitespeed.io +description: How to add your own post tasks, create rules and other cool stuff. +keywords: developers, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: How to add your own post tasks, create rules and other cool stuff. +--- +[Documentation 3.x](/documentation/) / Developers + +# Developers +{:.no_toc} + +* Lets place the TOC here +{:toc} + + +You can fork the project at [GitHub](https://github.com/sitespeedio/sitespeed.io) and create your own version or contribute to the existing one. The master branch is the latest release and/or in production-ready state. Clone that and you know it will always work. + +## The map + +![The sitespeed.io universe](the-sitespeed.io-universe2.png) +{: .img-thumbnail} + + + +## Add your own post tasks + +When sitespeed.io collected all the metrics, you have the possibility to add your own post tasks, meaning writing your own NodeJS code to take all the metrics and do whatever you want with it (store it to a database etc). + +You add your own post task (you can have multiple) in an directory and feed the directory name and path to sitespeed, like this: + +~~~bash +$ sitespeed.io -u https://www.sitespeed.io --postTasksDir myPostTaskDir +~~~ + +In that directory, create a file and follow the following standard: + +~~~javascript +exports.task = function(result, config, cb) { + console.log('yep this is my task running!') + cb(); +}; +~~~ + +The task will be called with the following: +* **result** - a JSON that contains all the metrics collected. Print it out to see exactly how it is constructed +* **config** - the sitespeed.io configuration object, contains info about the run and where to store the data +* **cb** - the callback to call when you are finished. + +All post tasks runs in parallell. + +## Create a new feature request +If you have ideas of how sitespeed.io can be improved or if you have any features that you think is missing, please add it to the [issue list](https://github.com/sitespeedio/sitespeed.io/issues?labels=&milestone=&page=1&state=open"). + +## Add your own rules +Sitspeed uses [YSlow](http://yslow.org/) as the engine for creating and managing the rules that decides how good the web page is optimized for performance. [Stoyan Stefanov](https://twitter.com/stoyanstefanov) has written three good blog posts of how you develop and write rules for YSlow: + +* [Getting started](http://www.phpied.com/yslow-development-getting-started/) +* [Setup](http://www.phpied.com/yslow-development-setup/) +* [Custom ruleset](http://www.phpied.com/yslow-development-custom-rulesets/) + +To do it for sitespeed, this is what you need: + +Clone the project + +~~~ +git clone git@github.com:sitespeedio/yslow.git +~~~ + +There are two files that you need to change, first the [rule file](https://github.com/sitespeedio/yslow/blob/master/src/common/rulesets/ruleset_sitespeed.js), where you add your own rule. + +You need to do two changes: Add your rule *YSLOW.registerRule(...)* and register your rule to the ruleset *YSLOW.registerRuleset(...)* + +In this example, I will add a rule called **cssprint** that will check for css files used only for printing the page: + +~~~ +YSLOW.registerRule({ +id: 'cssprint', +name: 'Do not load print stylesheets, use @media type print instead', +info: 'Loading a specific stylesheet for printing slows down the page, ' + +'even though it is not used', +category: ['css'], +config: {points: 20}, +url: 'http://sitespeed.io/rules/#cssprint', +lint: function (doc, cset, config) { +var i, media, score,url, +offenders = [], +hash = {}, +comps = cset.getComponentsByType('css'), +links = doc.getElementsByTagName('link'); + +for (i = 0, len = links.length; i < len; i += 1) { + if (links[i].media === 'print') { + url = links[i].href; + hash[url] = 1; + } +} + +for (var i = 0; i < comps.length; i++) { + if (hash[comps[i].url]) { + offenders.push(comps[i]); + } +} + +score = 100 - offenders.length * parseInt(config.points, 20); + +return { + score: score, + message: (offenders.length > 0) ? YSLOW.util.plural( + 'There %are% %num% print css files included on the page, that should be @media query instead', + offenders.length + ) : '', + components: offenders + }; +} +}); +~~~ + +When you have written your rule, register it to the ruleset and give it a proper weight (the lines with **cssprint** are the new ones, the rest exists already): + +~~~ +YSLOW.registerRuleset({ +id: 'sitespeed.io-X.Y', +name: 'Sitespeed.io rules vX.Y', +rules: { +... +cssprint: {}, +... +weights: { + ... + cssprint: 3, + ... +~~~ + +The next step is adding the documentation for the rule, you do that [here](https://github.com/soulgalore/yslow/blob/master/src/common/doc.js). You add one row where you put in the rule info: + +~~~ +YSLOW.doc.addRuleInfo('rulename','title','description') +~~~ + +For the **cssprint** rule, it looks like this: + +~~~ +YSLOW.doc.addRuleInfo('cssprint','Avoid loading specific css for print','Loading a specific stylesheet for print, can block rendering in your browser (depending on browser version) and will for almost all browsers, block the onload event to fire (even though the print stylesheet is not even used!).'); +~~~ + +It is used when you run sitespeed to create the rule definition HTML file that is put into the results, so you always can backtrack which rules you use. + +Create the new YSlow javascript file: + +~~~ +make phantomjs +~~~ + +Test that it works on one url (standing in root for YSlow): + +~~~ +phantomjs build/phantomjs/yslow.js d -r sitespeed.io-desktop -f xml http://yoururl.com +~~~ + +Move the newly created rulefile into a new directory: + +~~~ +cp build/phantomjs/yslow.js /tmp/myYslow.js +~~~ + +Run sitespeed in your folder: + +~~~ +sitespeed.io -u http://yoururl.com -y /tmp/myYslow.js +~~~ + +## Dependencies +Here are the dependencies for running sitespeed.io: + +* *NodeJS* - You need to have NodeJS installed to be able to run sitespeed.io +* *Java 1.7* - You need to have Java 1.7 (or higher) installed because the Crawler and Selenium (who drives the browsers) uses Java. + +## Component +The following components are used by sitespeed.io: + +* [PhantomJS](http://phantomjs.org/) by Ariya Hidayat. +* [Handlebars](http://handlebarsjs.com/). +* [FastStats](https://github.com/bluesmoon/node-faststats) to do statistical analysis of numeric datasets by Philip Tellis. +* [gpagespeed](https://www.npmjs.org/package/gpagespeed) - nalyze your web page by using Google Page Speed Insights by Geir Gåsodden. +* [YSlow](http://yslow.org) - Sitespeed.io uses the rule engine YSlow, because it is great! YSlow was originally developed by Yahoo and now maintained by **Marcel Duran**, a rule engine & browser plugin created to test your web page against best practices rules. +* [Bootstrap](http://getbootstrap.com/) is a front end framework to create nice looking HTML, all the front end of the result pages produced by sitespeed are built with Bootstrap. +* [Java crawler](https://github.com/soulgalore/crawler) that output all links within a domain to a file, it can follow a specific path or make sure urls containing X not will be fetched. +* [Stupid Table Plugin](https://github.com/joequery/Stupid-Table-Plugin) by Joseph McCullough is a really small table column sorter. +* [BrowserTime](https://github.com/tobli/browsertime) collects browser timings using the Navigation Timing API. +* [WebPageTest API wrapper](https://www.npmjs.org/package/webpagetest) for NodeJS by Marcel Duran to fetch metrics from WebPageTest +* [BrowserMobProxy](https://github.com/lightbody/browsermob-proxy) to collect HAR data. + + +## Report a bug +If you find a bug, please first make sure you run the [latest version](https://www.npmjs.com/package/sitespeed.io) of sitespeed.io. Then go through the current known [bug list](https://github.com/sitespeedio/sitespeed.io/issues?labels=bug&state=open). If it doesn't exist there, please add it! diff --git a/docs/3.x/developers/the-sitespeed.io-universe.png b/docs/3.x/developers/the-sitespeed.io-universe.png new file mode 100644 index 0000000000..b0a69db966 Binary files /dev/null and b/docs/3.x/developers/the-sitespeed.io-universe.png differ diff --git a/docs/3.x/developers/the-sitespeed.io-universe2.png b/docs/3.x/developers/the-sitespeed.io-universe2.png new file mode 100644 index 0000000000..7462ba8677 Binary files /dev/null and b/docs/3.x/developers/the-sitespeed.io-universe2.png differ diff --git a/docs/3.x/docker/index.md b/docs/3.x/docker/index.md new file mode 100644 index 0000000000..f549f4ec50 --- /dev/null +++ b/docs/3.x/docker/index.md @@ -0,0 +1,72 @@ +--- +layout: default +title: Docker - Documentation - sitespeed.io +description: Use Docker to run sitespeed.io. +keywords: docker, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Use Docker to run sitespeed.io. +--- +[Documentation 3.x](/documentation/) / Docker + +# Docker +{:.no_toc} + +* Lets place the TOC here +{:toc} + + +## Containers +We have a couple of Docker containers you can use to run sitespeed.io. We have separated them to try to keep the size as small as possible. + + * [The base box](https://hub.docker.com/r/sitespeedio/sitespeed.io-standalone/) - only including sitespeed.io. You can use this if you only want to check web performance best practice rules. And soon when PhantomJS 2 is released for Linux you will be able to fetch timing using Phantom. + * [Firefox & Xvfb](https://hub.docker.com/r/sitespeedio/sitespeed.io-firefox/) - makes it possible to fetch timings using Firefox. This it the smallest container using a real browser. + * [Chrome & Xvfb](https://hub.docker.com/r/sitespeedio/sitespeed.io-chrome/) - if you prefer Chrome this is the container to use. + * [Chrome, Firefox & Xvfb](https://hub.docker.com/r/sitespeedio/sitespeed.io/) - here you get all the things you need, the box gets quite large precisely over 1 gb. + + +## Running in Docker +The simplest way to run is like this fetching the box with Chrome and Firefox: + +~~~ bash +sudo docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io sitespeed.io -u https://www.sitespeed.io -b chrome +~~~ + +If you want to feed sitespeed with a list of URL:s in a file (here named *myurls.txt*), add the file to your current directory and do like this: + +~~~ bash +sudo docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io sitespeed.io -f myurls.txt -b chrome --seleniumServer http://127.0.0.1:4444/wd/hub +~~~ + +In the real world you should always specify the exact version (tag) of the Docker container to make sure you use the same version all the time (else you will download the latest tag, meaning you can have old and new versions running on the server and you don't know it). 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: + +~~~ bash +sudo docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:X.Y.Z sitespeed.io -u https://www.sitespeed.io -b chrome +~~~ + + + +## Setup the volume + +If you want to feed sitespeed.io with a file with URL:s 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* + +Note: running on Mac OS X and Windows Docker only has rights to write data in your */Users* or *C:\Users* directory. Read more [here](https://docs.docker.com/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume). +{: .note .note-warning} + +## Update version (download newer sitespeed.io version) +Updating to a newer version is 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 you will run the latest version. diff --git a/docs/3.x/gpsi/gpsi-detailed-page-info.png b/docs/3.x/gpsi/gpsi-detailed-page-info.png new file mode 100644 index 0000000000..4667e71d84 Binary files /dev/null and b/docs/3.x/gpsi/gpsi-detailed-page-info.png differ diff --git a/docs/3.x/gpsi/gpsi-pages.png b/docs/3.x/gpsi/gpsi-pages.png new file mode 100644 index 0000000000..0bb7cf79e2 Binary files /dev/null and b/docs/3.x/gpsi/gpsi-pages.png differ diff --git a/docs/3.x/gpsi/gpsi-summary.png b/docs/3.x/gpsi/gpsi-summary.png new file mode 100644 index 0000000000..3bf76e591a Binary files /dev/null and b/docs/3.x/gpsi/gpsi-summary.png differ diff --git a/docs/3.x/gpsi/index.md b/docs/3.x/gpsi/index.md new file mode 100644 index 0000000000..050d47c0c1 --- /dev/null +++ b/docs/3.x/gpsi/index.md @@ -0,0 +1,42 @@ +--- +layout: default +title: Run Google Page Speed Insights - Documentation - sitespeed.io +description: Fetch Google Page Speed Insights metrics and include them in your sitespeed.io report. +keywords: gpsi, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Fetch Google Page Speed Insights metrics and include them in your sitespeed.io report. +--- +[Documentation 3.x](/documentation/) / GPSI + +# Google Page Speed Insights +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Google Page Speed Insights (GPSI) is Google:s rule/best practices rules to build a web site that are as fast as possible. Follow the rules and your site will be fast. + +Sitespeed.io integrates GPSI so you can fetch how good your site is doing. Two things: Your site needs to reachable from the internet (and no basic authentication) and you need to supply your own [Google key](https://console.developers.google.com/project). + +Run it like this: + +~~~bash +$ sitespeed.io -u http://yoursite.com --gpsiKey MY_SECRET_KEY +~~~ + +Sitespeed.io will collect all available data from GPSI. On the summary page, the GPSI score will be shown. We also collect number of requests. You can check the implementation [here](https://github.com/sitespeedio/sitespeed.io/tree/master/lib/aggregators/gpsi) and add an issue if you want us to collect more data: + +![Google Page Speed Summary](gpsi-summary.png) +{: .img-thumbnail} + +On the pages summary, you will also automatically the GPSI score: + +![Google Page Speed Pages](gpsi-pages.png) +{: .img-thumbnail} + +And on the detailed summary page, we show all the data that are provided by GPSI, it looks like this: + +![Google Page Speed details](gpsi-detailed-page-info.png) +{: .img-thumbnail} diff --git a/docs/3.x/graphs/grafana-page-metrics.png b/docs/3.x/graphs/grafana-page-metrics.png new file mode 100644 index 0000000000..28b8b6f038 Binary files /dev/null and b/docs/3.x/graphs/grafana-page-metrics.png differ diff --git a/docs/3.x/graphs/grafana-swedish-newspapers.png b/docs/3.x/graphs/grafana-swedish-newspapers.png new file mode 100644 index 0000000000..a0495a0ee8 Binary files /dev/null and b/docs/3.x/graphs/grafana-swedish-newspapers.png differ diff --git a/docs/3.x/graphs/grafana-timing-metrics.png b/docs/3.x/graphs/grafana-timing-metrics.png new file mode 100644 index 0000000000..9caf082618 Binary files /dev/null and b/docs/3.x/graphs/grafana-timing-metrics.png differ diff --git a/docs/3.x/graphs/grafana-wpt-dark.png b/docs/3.x/graphs/grafana-wpt-dark.png new file mode 100644 index 0000000000..54fa394d55 Binary files /dev/null and b/docs/3.x/graphs/grafana-wpt-dark.png differ diff --git a/docs/3.x/graphs/index.md b/docs/3.x/graphs/index.md new file mode 100644 index 0000000000..57388d95d7 --- /dev/null +++ b/docs/3.x/graphs/index.md @@ -0,0 +1,72 @@ +--- +layout: default +title: Graphs - Documentation - sitespeed.io +description: Create graphs for your web performance metrics using Graphite and Grafana. +keywords: graphs, graphite, grafana, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Create graphs for your web performance metrics using Graphite and Grafana. +--- +[Documentation 3.x](/documentation/) / Graphs + +# Graphs +{:.no_toc} + +* Lets place the TOC here +{:toc} + +The easiest way to graph your data (and keep track how you are doing over time), is sending the data to [Graphite](http://graphite.wikidot.com/). And then use a tool to create the graphs. I like [Grafana](http://grafana.org/) because it is super simple and look nice. Here's how you do it: + +* Install Graphite - if you are on Mac OS X and want to test it out, use a Vagrant setup. +* Install Grafana - either by Vagrant or just download and install InfluxDb & ElasticSearch +* Send the data from sitespeed.io to Graphite +* Create the graphs in Grafana. We will soonish add a video of how to do it. + +Here are a couple of examples of what ut can look like. Here we test one site, something like this: + +~~~bash +sitespeed.io -u http://www.cybercom.com --graphiteHost localhost -m 5 --graphiteNamespace cybercom -b chrome -n 11 +~~~ + +And setup the following graphs: +![sitespeed.io page metrics sent to Graphite](grafana-page-metrics.png) +{: .img-thumbnail} + +![sitespeed.io timing metrics sent to Graphite](grafana-timing-metrics.png) +{: .img-thumbnail} + +![sitespeed.io page metrics sent to Graphite](grafana-page-metrics.png) +{: .img-thumbnail} + +In this example, we compare four Swedish newspapers, running it like this + +~~~bash +$ sitespeed.io --sites /Users/peter/swedish.txt --graphiteHost localhost --graphiteNamespace newspapers -b chrome -n 7 +~~~ + +and the result: + +![sitespeed.io comparing multiple sites](grafana-swedish-newspapers.png) +{: .img-thumbnail} + +And the last example, we fetch data from WebPageTest and create the following: + +![sitespeed.io running WebPageTest and graphing the data](grafana-wpt-dark.png) +{: .img-thumbnail} + +~~~bash +$ sitespeed.io -u http://www.cybercom.com --wptHost www.webpagetest.org --wptKey MY_SECRET_API_KEY --graphiteHost localhost --graphiteNamespace wpt +~~~ + +If you send all the metrics and don't need the other output (HTML/JSON, it can be quite extensive if you run it often), put all the output in **/tmp** with the **r** switch like this **-r /tmp**. +{: .note .note-info} + + Doesn't all values reach Graphite (are you missing values), then you should check your **carbon.conf** file. + The configuration **MAX_CREATES_PER_MINUTE** needs to be set to high (we have seen that 50 is too low). To make sure it works, set it like this: + +~~~ +MAX_CREATES_PER_MINUTE = inf +~~~ + +{: .note .note-warning} diff --git a/docs/3.x/headless/index.md b/docs/3.x/headless/index.md new file mode 100644 index 0000000000..86f91fef18 --- /dev/null +++ b/docs/3.x/headless/index.md @@ -0,0 +1,51 @@ +--- +layout: default +title: Headless - Documentation - sitespeed.io +description: Collect browser timings headless using sitespeed.io. +keywords: headless, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Collect browser timings headless using sitespeed.io. +--- +[Documentation 3.x](/documentation/) / Headless + +# Headless +{:.no_toc} + +* Lets place the TOC here +{:toc} + +## Headless using Xvfb + + If you run on Linux and want to emulate a screen (a.k.a running a browser without a screen), you need to do this before running: + +* Install [Xvfb](http://www.x.org/releases/current/doc/man/man1/Xvfb.1.xhtml). +* Setup a start script, checkout how we do it in our [Docker container](https://github.com/sitespeedio/sitespeed.io-docker/blob/master/all/scripts/start.sh). + + +## PhantomsJS 2 +[PhantomJS](http://phantomjs.org/) is used by default when validating the web performance best practice rules. Soon (!) we will upgrade to the (almost) released 2.0 version. If you want to try out the 2.0 and use it when you run sitespeed.io, do like this: + +* Follow [these](https://github.com/ariya/phantomjs/wiki/PhantomJS-2) instructions to build PhantomJS 2 or [download](https://bitbucket.org/ariya/phantomjs/downloads) the compiled versions. +* Run sitespeed.io and configure it to use your own version of PhantomJS + +~~~bash +sitespeed.io -u https://www.sitespeed.io --phantomjsPath /the/path/to/your/bin +~~~ + +* If you also want to collect timings using PhantomJS, run it like this: + +~~~bash +sitespeed.io -u https://www.sitespeed.io --phantomjsPath /the/path/to/your/bin -b headless +~~~ + +We have tested PhantomJS 2 on Mac OS X and it works really good when testing the site against the best practice rules. However, it seems to be a couple of timings that don't work as expected. If you have time to test and find things that don't work, please let us know and we will update the docs. We aim to give this more love when the stable 2.0 is released. +{: .note .note-warning} + +## SlimerJS +SlimerJS is kind of headless, but you will need Xvfb to have it real headless. Run it like this to collect timing metrics: + +~~~bash +sitespeed.io -u https://www.sitespeed.io --headless slimerjs -b headless +~~~ diff --git a/docs/3.x/index.md b/docs/3.x/index.md new file mode 100644 index 0000000000..bac80a8fa6 --- /dev/null +++ b/docs/3.x/index.md @@ -0,0 +1,28 @@ +--- +layout: default +title: Documentation 3.x - sitespeed.io +description: Here's the documentation of how to use sitespeed.io. +keywords: documentation, web performance, sitespeed.io, graphite, navigation timing api +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Documentation for the sitespeed.io. +--- +# Documentation 3.x + + * [Introduction](/3.x/introduction/) + * [Installation](/3.x/installation/) - install using npm, Vagrant or run our Docker containers. + * [Configuration](/3.x/configuration/) - there's alot of things you can do with sitespeed.io, lets checkout how! + * [The result](/3.x/result/) - get the result as HTML, TAP, JUnit XML or send the metrics to Graphite. + * [Rules and web performance best practice](/3.x/rules-and-best-practices/) - the rules used to create the sitespeed.io score. + * [Browsers](/3.x/browsers/) - collect timings using real browsers. We support Firefox, Chrome, Internet Explorer and Safari. + * [Headless](/3.x/headless/) - collect metrics using PhantomJS, SlimerJS or use Xvfb for your browser. + * [Use Cases](/3.x/use-cases/) - find out best practices for testing a site, compare with other sites. +* [Performance Dashboard](/3.x/performance-dashboard/) - keep track of your metrics and performance. + * [Performance Budget](/3.x/performance-budget/) - make sure you are within your performance budget. + * [Graphs](/3.x/graphs/) - graph you webperf metrics using Graphite and Grafana. + * [Continuous Integration](/3.x/continuous-integration/) - generate JUnit XML/TAP and use Jenkins, Team City, Grunt or the Gulp plugin. + * [Docker](/3.x/docker/) - how to use our Docker containers. + * [WebPageTest](/3.x/webpagetest/) - drive WebPageTest and fetch metrics and graph them. + * [Google Page Speed Insights](/3.x/gpsi/) - include GPSI metrics in your reports. + * [Developers](/3.x/developers/) - more info on how to create your own post tasks or use your own rules. diff --git a/docs/3.x/installation/index.md b/docs/3.x/installation/index.md new file mode 100644 index 0000000000..f473792e21 --- /dev/null +++ b/docs/3.x/installation/index.md @@ -0,0 +1,63 @@ +--- +layout: default +title: Installation - Documentation - sitespeed.io +description: How to to install sitespeed.io. Use npm, our Vagrant files or Docker. +keywords: installation, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: How to to install sitespeed.io. Use npm, our Vagrant files or Docker. +--- +[Documentation 3.x](/documentation/) / Installation + +# Installation +{:.no_toc} + +* Lets place the TOC here +{:toc} + +# Download and installation + +## Install on Mac, Linux & Windows + +Prerequisites: Install [NodeJS](http://nodejs.org/download/) ([Linux](https://github.com/creationix/nvm)) and make sure you have [npm](https://github.com/npm/npm) installed. + +~~~ bash +$ npm install sitespeed.io +~~~ + +If you want it installed globally (running it from wherever): + +~~~ bash +$ npm install -g sitespeed.io +~~~ + +Run + +~~~ bash +sitespeed.io -h +~~~ + +or on Windows: + +~~~ bash +$ sitespeed.io.cmd -h +~~~ + +## Vagrant + +We have a couple of [Vagrant](https://github.com/sitespeedio/sitespeed.io-vagrant) boxes to get you up and running fast (installing sitespeed.io and browsers). + +* [Ubuntu 14](https://github.com/sitespeedio/sitespeed.io-vagrant/tree/master/sitespeed-ubuntu14) +* [CentOS 7](https://github.com/sitespeedio/sitespeed.io-vagrant/tree/master/sitespeed-centos7) + +## Docker + +We have [Docker images](https://hub.docker.com/u/sitespeedio/) with sitespeed.io, Chrome, Firefox and Xvfb. They are super easy to use (Xvfb is started automatically when you start the container). Here's how to use the container with both Firefox & Chrome (install [Docker](https://docs.docker.com/installation/ubuntulinux/) or [Docker toolbox](https://www.docker.com/toolbox) first and start them). + +~~~ bash +$ sudo docker pull sitespeedio/sitespeed.io +$ sudo docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io sitespeed.io -u https://www.sitespeed.io -b firefox +~~~ + +That will output the data from the run in the current directory. You can read more about running the containers [here](/documentation/docker/). diff --git a/docs/3.x/introduction/index.md b/docs/3.x/introduction/index.md new file mode 100644 index 0000000000..45d74981ca --- /dev/null +++ b/docs/3.x/introduction/index.md @@ -0,0 +1,18 @@ +--- +layout: default +title: Introduction - Documentation - sitespeed.io +description: Introduction for sitespeed.io. +keywords: introduction, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Introduction for sitespeed.io. +--- +[Documentation 3.x](/documentation/) / Introduction + +# Introduction +Sitespeed.io is an open source tool that helps you understand if your site is fast or not. It tests your site against web performance best practice rules, get timings using Chrome/Firefox or PhantomJS 2 (using the Navigation Timing API and User Timing API). + +You can also drive [WebPageTest](http://www.webpagetest.org/) using sitespeed.io, collecting data from multiple URL:s tested using WebPageTest. + +Sitespeed.io outputs the information as HTML/JSON or JUnit XML or [TAP](http://testanything.org/). And can automatically send the collected metrics to [Graphite](http://graphite.wikidot.com/). diff --git a/docs/3.x/performance-budget/budget.png b/docs/3.x/performance-budget/budget.png new file mode 100644 index 0000000000..f6a376b05e Binary files /dev/null and b/docs/3.x/performance-budget/budget.png differ diff --git a/docs/3.x/performance-budget/index.md b/docs/3.x/performance-budget/index.md new file mode 100644 index 0000000000..ec7a442be2 --- /dev/null +++ b/docs/3.x/performance-budget/index.md @@ -0,0 +1,89 @@ +--- +layout: default +title: Performance Budget - Documentation - sitespeed.io +description: Performance budget with sitespeed.io. +keywords: performance, budget, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Performance budget with sitespeed.io. +--- +[Documentation 3.x](/documentation/) / Performance Budget + +# Performance Budget +{:.no_toc} + +* Lets place the TOC here +{:toc} + +## Performance budget +Have you heard of a performance budget? If not, please read the excellent posts by Tim Kadlec [Setting a performance budget](http://timkadlec.com/2013/01/setting-a-performance-budget/) and [Fast enough](http://timkadlec.com/2014/01/fast-enough/). Also read Daniel Malls [How to make a performance budget](http://danielmall.com/articles/how-to-make-a-performance-budget/). After that, continue setup sitespeed.io :) + +### How it works +When you run sitespeed.io configured with a budget, the script will exit with a exit status > 0 if the budget fails. It will log the budget items that are failing and the ones that are working, and create a HTML report for the budget. + +The log will look something like this: + +~~~ +error: The budget for js requests http://www.cybercom.com/da/Denmark/ failed. The number of js requests 10 the limit is 5 +error: The budget for css requests http://www.cybercom.com/da/Denmark/ failed. The number of css requests 2 the limit is 1 +error: The budget for requests per page http://www.cybercom.com/da/Denmark/ failed. The number of requests is 28 and the limit is 10 +info: The budget for image requests http://www.cybercom.com/da/Denmark/ passed [5] +error: The budget for js requests http://www.cybercom.com/Cases-and-clients/SF-BIO-app/ failed. The number of js requests 10 the limit is 5 +... +~~~ + +And the report looks like this. +![Example of the budget](budget.png) +{: .img-thumbnail} + +Lets see how you can configure your budgets. + + +### Testing timings +If you have a budget where you want to test the (RUM) speed index, you add a file like this: + +~~~ +{ + "timings": { + "speedIndex": 1000 + } +} +~~~ +Then run it like this: + +~~~bash +$ sitespeed.io -u https://www.sitespeed.io --budget myBudget.json -b chrome -n 11 +~~~ + +You can test all timings produced by BrowserTime like *domContentLoadedTime* or *backEndTime*. + +### Testing user timings +You can have a budget for your own User Timings metrics. For www.sitespeed.io we have two user timing metrics: *logoTime* and *headerTime*. You can add them to the budget like this: + +~~~ +{ + "timings": { + "headerTime": 800, + "logoTime": 500 + } +} +~~~ + +And they will be tested and matched against your configured value. + +### Using WebPageTest +If you are using WebPageTest, you can setup a budget matching almost whatever WPT fetches but the most useable things are testing the number of requests, size, TTFB and the speed index score. To test all these four things, you add a JSON file looking like this: + +~~~ +{ + "wpt" : { + "requests": 60, + "TTFB": 200, + "bytesIn": 1000000, + "SpeedIndex" : 1000 + } +} +~~~ + +And change the values to what you want to test. In this example the budget will blow if we have more that 60 requests on a page, a time to first byte larger than 200 ms, a page weight more than 1000 kb and a speed index score larger than 1000. diff --git a/docs/3.x/performance-dashboard/3rdparty.png b/docs/3.x/performance-dashboard/3rdparty.png new file mode 100644 index 0000000000..37912b0465 Binary files /dev/null and b/docs/3.x/performance-dashboard/3rdparty.png differ diff --git a/docs/3.x/performance-dashboard/compare.png b/docs/3.x/performance-dashboard/compare.png new file mode 100644 index 0000000000..bdb73bfc6b Binary files /dev/null and b/docs/3.x/performance-dashboard/compare.png differ diff --git a/docs/3.x/performance-dashboard/configure-grafana.jpg b/docs/3.x/performance-dashboard/configure-grafana.jpg new file mode 100644 index 0000000000..bee5e38c1b Binary files /dev/null and b/docs/3.x/performance-dashboard/configure-grafana.jpg differ diff --git a/docs/3.x/performance-dashboard/configure-grafana.png b/docs/3.x/performance-dashboard/configure-grafana.png new file mode 100644 index 0000000000..77f2c22210 Binary files /dev/null and b/docs/3.x/performance-dashboard/configure-grafana.png differ diff --git a/docs/3.x/performance-dashboard/custom-metrics.png b/docs/3.x/performance-dashboard/custom-metrics.png new file mode 100644 index 0000000000..1d140d3062 Binary files /dev/null and b/docs/3.x/performance-dashboard/custom-metrics.png differ diff --git a/docs/3.x/performance-dashboard/custom-metrics2.jpg b/docs/3.x/performance-dashboard/custom-metrics2.jpg new file mode 100644 index 0000000000..2af0a539e4 Binary files /dev/null and b/docs/3.x/performance-dashboard/custom-metrics2.jpg differ diff --git a/docs/3.x/performance-dashboard/dashboard-logo.jpg b/docs/3.x/performance-dashboard/dashboard-logo.jpg new file mode 100644 index 0000000000..821b5dd7c8 Binary files /dev/null and b/docs/3.x/performance-dashboard/dashboard-logo.jpg differ diff --git a/docs/3.x/performance-dashboard/dashboards.zip b/docs/3.x/performance-dashboard/dashboards.zip new file mode 100644 index 0000000000..26beeecdeb Binary files /dev/null and b/docs/3.x/performance-dashboard/dashboards.zip differ diff --git a/docs/3.x/performance-dashboard/index.md b/docs/3.x/performance-dashboard/index.md new file mode 100644 index 0000000000..dbbf3cee78 --- /dev/null +++ b/docs/3.x/performance-dashboard/index.md @@ -0,0 +1,331 @@ +--- +layout: default +title: Dashboard - Documentation - sitespeed.io +description: Web performance dashboard using sitespeed.io. +keywords: dashboard, docker, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Web performance dashboard using sitespeed.io. +--- + +[Documentation 3.x](/documentation/) / Performance Dashboard + +# Performance Dashboard +{:.no_toc} + +* Lets place the TOC here +{:toc} + + +## Background +We have put a lot of love into making it easy to create your own performance dashboard. To get it up and running you need [Docker](https://www.docker.com/). That's it :) + +The base is the Docker images: + + * To collect metrics, use one of the three images: [sitespeed.io with Chrome, Firefox & Xvfb](https://hub.docker.com/r/sitespeedio/sitespeed.io/), [sitespeed.io with Chrome & Xvfb](https://hub.docker.com/r/sitespeedio/sitespeed.io-chrome/) or [sitespeed.io with Firefox & Xvfb](https://hub.docker.com/r/sitespeedio/sitespeed.io-firefox/). + * [Store the metrics using Graphite ](https://hub.docker.com/r/sitespeedio/graphite/). If you have a Graphite server up and running already you can use that one, just make sure to configure *storage-schemas* and *storage-aggregations*. + * [Graph the metrics using Grafana](https://hub.docker.com/r/grafana/grafana/). + * You can also send your Google Analytics metrics to Grafana using [this container](https://hub.docker.com/r/sitespeedio/gatographite/). + +You can run these images on your own machine(s) or in the cloud. You only need Docker. But what will you get? We have set up an example site that you can try out yourself. We are proud to present +[dashboard.sitespeed.io](http://dashboard.sitespeed.io/). + +## Metrics and what you can graph + +There are lots of metrics collected, lets check what kind of views of the data you can create: + +* [In deep info about your most important pages](http://dashboard.sitespeed.io/dashboard/db/metrics-for-one-page-american-airlines-home-page) - you can graph and keep track how your page is built (things like number of requests, request types and sizes) and how fast your page is using the Navigation Timing and User Timings. +[![Metrics for one page example](one-page.png)](http://dashboard.sitespeed.io/dashboard/db/metrics-for-one-page-american-airlines-home-page) +{: .img-thumbnail} + +* [Keep track how your whole site is doing]((http://dashboard.sitespeed.io/dashboard/db/summary-of-a-site-america-airlines)) - summary for a whole site helps you see keep track of all tested pages. Use it to catch pages that are underperforming. And to keep track for your whole site over time. Do you see the red boxes in the image? That is budgets that haven't been met. You can configure budgets for all metrics making it super easy for all users to understand if the site is doing good or bad. +[![Summary](summary.png)](http://dashboard.sitespeed.io/dashboard/db/summary-of-a-site-america-airlines) +{: .img-thumbnail} + +* [Competition ain't nothing](http://dashboard.sitespeed.io/dashboard/db/compare-multiple-sites) - compare multiple sites and keep track of them. This is an awesome way to keep track of your competition, how fast they are and how they are building their web sites. +[![Compare](compare.png)](http://dashboard.sitespeed.io/dashboard/db/compare-multiple-sites) +{: .img-thumbnail} + +* [ WebPageTest](http://dashboard.sitespeed.io/dashboard/db/using-webpagetest) - yes we love WebPageTest and in this example we drive WebPageTest through sitespeed.io and graph the data. We use the free limited API key provided by Akamai and you should setup your own WebPageTest instance so you can test all your important pages, as often as you need. +[![WebPageTest](webpagetest.png)](http://dashboard.sitespeed.io/dashboard/db/using-webpagetest) +{: .img-thumbnail} + +* [Keep track of your third party content](http://dashboard.sitespeed.io/dashboard/db/3rd-party-america-airlines) - today most of the consumer web pages have about 40% of third party content. You don't want them to slow you down and so you need to keep track of how they are doing. Thanks Jeroen Vd Berghe for the help and inspiration with the graphs. +[![3rd party](3rdparty.png)](http://dashboard.sitespeed.io/dashboard/db/3rd-party-america-airlines) +{: .img-thumbnail} + +* [Collect Custom Metrics](http://dashboard.sitespeed.io/dashboard/db/user-timing-and-custom-metrics) - collect your own defined metrics using the User Timing API and running your own Javascript snippets in the browser and the values will automatically be sent to Graphite (both for ach page and a summary for all pages). This is perfect if there's a metric that is super important for your site or if there's a metric that is missing in sitespeed.io. You can add it yourself, as long as you can fetch it using Javascript. +[![Custom metrics](custom-metrics2.jpg)](http://dashboard.sitespeed.io/dashboard/db/user-timing-and-custom-metrics) +{: .img-thumbnail} + + +* [Keep track of every page and every request](http://dashboard.sitespeed.io/dashboard/db/load-timings-per-asset) - +this is maybe a little bit crazy but you can collect +timings per request You can graph things like time spent in *blocked*, *dns*, *connect*, *ssl*, *send*, *wait*, *receive* and *total* time. It will generate a lot of data but is extremely good to find slow loading assets from a 3rd party. +[![Timings per asset](perasset.png)](http://dashboard.sitespeed.io/dashboard/db/load-timings-per-asset) +{: .img-thumbnail} + +## Setup the containers + +It is easy to setup the containers. The only thing you need to do is set up directories where you store the data and start the containers. + +### Graphite +First we want to have have Graphite to store the metrics. You want to store the data outside of your containers, so create an directory where you store the data. In this example we put it in */data/graphite/storage/whisper* + +~~~ +sudo mkdir -p /data/graphite/storage/whisper +~~~ + +Then start the image. + +~~~ +sudo docker run -d \ + --name graphite \ + -p 8080:80 \ + -p 2003:2003 \ + --restart="always" \ + -v /data/graphite/storage/whisper:/opt/graphite/storage/whisper \ + sitespeedio/graphite +~~~ + +Your Graphite instance will be behind Basic Auth (*guest/guest*), if your server is public you should change that by generating your own .htpasswd file. You can do that with [apache2-utils](http://httpd.apache.org/docs/2.2/programs/htpasswd.html). You run it like this: + +~~~ +sudo apt-get install apache2-utils +sudo htpasswd -c .htpasswd YOUR_USERNAME +~~~ + +And add this line when you start the Graphite docker image: + +~~~ +-v /your/path/.htpasswd:/etc/nginx/.htpasswd \ +~~~ + +The full startup would then look like this: + +~~~ +sudo docker run -d \ + --name graphite \ + -p 8080:80 \ + -p 2003:2003 \ + --restart="always" \ + -v /data/graphite/storage/whisper:/opt/graphite/storage/whisper \ + -v /your/path/.htpasswd:/etc/nginx/.htpasswd \ + sitespeedio/graphite +~~~ + + +### Grafana +Before you start Grafana you want to make sure that the dashboard data is stored on disk. Create a directory that will hold the Grafana database: + +~~~ +sudo mkdir -p /data/grafana +~~~ + +And then start Grafana, map the directory, and add a new admin user & password. + +~~~ +sudo docker run -d -p 3000:3000 \ +-v /data/grafana:/var/lib/grafana \ +-e "GF_SECURITY_ADMIN_USER=myuser" \ +-e "GF_SECURITY_ADMIN_PASSWORD=MY_SUPER_STRONG_PASSWORD" \ +--name grafana \ +--restart="always" \ +grafana/grafana +~~~ + +The next step is to access your Grafana instance and configure it to use your Graphite instance as backend. Choose *Grafana admin* > *Data Sources* > *Add new*. And then make sure to set it as default and enable Basic Auth. + +![Configure Grafana to use Graphite](configure-grafana.jpg) +{: .img-thumbnail} + + +### Collect metrics +Now we need to collect that precious metrics. Do it by the old crontab. But first create a data dir where you can put the input/output files for sitespeed.io: + +~~~ +sudo mkdir /sitespeed.io +~~~ + +Then edit your crontab: + +~~~ +sudo crontab -e +~~~ + +And add something like this (make sure to change the URL and the host). In this example we run every 15 minutes, but you can of course change it: + +~~~ +SHELL=/bin/bash +PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin +0,15,30,45 * * * * docker run --privileged --rm -v /sitespeed.io:/sitespeed.io sitespeedio/sitespeed.io sitespeed.io -u http://mysite.com -b firefox -n 5 --connection cable -r /tmp/ --graphiteHost YOUR_GRAPHITE_HOST --seleniumServer http://127.0.0.1:4444/wd/hub >> /tmp/sitespeed-run.txt 2>&1 +~~~ + +You can of course fetch URL:s from a file and store the output if you want. To do that add a file in you */sitespeed.io/* directory containing all the URL:s and run it like this: + +~~~ +SHELL=/bin/bash +PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin +0,15,30,45 * * * * docker run --privileged --rm -v /sitespeed.io:/sitespeed.io sitespeedio/sitespeed.io sitespeed.io -f urls.txt -b firefox -n 11 --connection cable -r /tmp/ --graphiteHost YOUR_GRAPHITE_HOST --seleniumServer http://127.0.0.1:4444/wd/hub >> /tmp/sitespeed-run.txt 2>&1 +~~~ + +Note: You need to configure the selenium server to use (there are bugs running it straight with NodeJS and Linux). You do that by adding --**seleniumServer http://127.0.0.1:4444/wd/hub** to your run. Using the selenium server will make your runs more stable. +{: .note .note-warning} + +#### Collect from multiple locations +It works perfectly to collect data from different servers/locations and send the data to the same Graphite server. What you need to do is give the keys in Graphite different names so that they don't collide. You do that by setting the *graphiteNamespace* when you run sitespeed and you'll have unique namespaces. + +~~~ +sitespeed.io -u http://mysite.com -b firefox --graphiteHost YOUR_GRAPHITE_HOST --graphiteNamespace sitespeed.io.newyork +~~~ + +## Setup your dashboards +To get up and running fast we have a [zip file](dashboards.zip) with example JSON:s that you can use to. Remember though that you need to change the keys to match your keys so you can see values. + +If you need help, checkout the [Grafana documentation](http://docs.grafana.org/). + +## Limit the amount of data in Graphite +If you test many pages you will have a lot of data stored in Graphite, make sure you set it up correctly for what you need. + +### Configure sitespeed.io what metrics to send + +You can choose to send the following metrics to Graphite: + +* *summary* - the summary of a whole sites, it's the same data as shown on the summary HTML page +* *rules* - how each and every tested page match against the web performance best practice rules +* *pagemetrics* - how each and every page is built, like the number of javascripts, css etc +* *timings* - the timings for every page fetched using the Navigation Timing API and User Timings +* *requests* - send the timings and size data for each and every request: *blocked*, *dns*, *connect*, *ssl*, *send*, *wait*, *receive* and *total* time. This will generate a lot of data. +* *domains* - send the usage and timings per domain. + +By default all timings are sent. If you want to change that, remove the metrics you don't need: + +~~~ +--graphiteData summary,rules,pagemetrics,timings,requests +~~~ + +### Configure Graphite what data to keep + +By default the metrics are stored for 60 days (except request timings they are only stored for 7 days by default) and you can change that. First [read](https://github.com/etsy/statsd/blob/master/docs/graphite.md) Etsy's nice write-up on how you configure Graphite. Create your own [storage-schemas.conf](https://github.com/sitespeedio/docker-graphite-statsd/blob/master/conf/graphite/storage-schemas.conf) file and feed it to the image on startup like this: + +~~~ +-v /path/to/storage-schemas.conf:/opt/graphite/conf/storage-schemas.conf +~~~ + +You can also configure how data is aggregated over time. Check out the default configuration [storage-aggregation.conf](https://github.com/sitespeedio/docker-graphite-statsd/blob/master/conf/graphite/storage-aggregation.conf) and reread Etsy's nice write-up :) + +## Add events/annotations to the graphs + +Graphite comes with an [event API](http://obfuscurity.com/2014/01/Graphite-Tip-A-Better-Way-to-Store-Events) so you can mark specific events like releases. You can simply do that with a curl! + +~~~ +curl -u LOGIN:PASSWORD -X POST "http://HOSTNAME:8080/events/" -d '{"what": "Deploy", "tags": "production deploy example", "data": "deploy of master branch, version 1.0.0"}' +~~~ + +Change the LOGIN and PASSWORD to the Basic Auth you are using for Graphite and the HOSTNAME to your host. Then for each dashboard choose *Annotations* and the one you use by the tag(s). + +## Memcached (optional) +If you setup a dashboard and you collect many different graphs on one page, it is good to add *memcached* in your setup, that will cache queries done to Graphite. Download and start it. In this example we just open the port, if you have a system reachable from the outside you should link the containers. + +~~~ +sudo docker pull memcached +sudo docker run --name memcache -p 11211:11211 -d memcached +~~~ + +The next step is to configure Graphite. You do that by changing your *local_settings.py*. Take a copy of the default one located [here](https://github.com/sitespeedio/docker-graphite-statsd/blob/master/scripts/local_settings.py) and edit it. You can add multiple *memcached* instances, if you want but lets start with one, change *$MY_IP* to the IP of your server running memcached. + +~~~ +# Array of memcache hosts. domain/ip and port ['10.10.10.10:11211', '10.10.10.11:11211'] +MEMCACHE_HOSTS = ['$MY_IP:11211'] +# Cache for 1 minute +DEFAULT_CACHE_DURATION = 60 +~~~ + +And then when you start Graphite, make sure to link in the new file. + +~~~ +-v /my/path/local_settings.py:/opt/graphite/webapp/graphite/local_settings.py \ +~~~ + +## Known problems +Modern browsers uses a lot of CPU and memory, so to avoid browser problems, run the browsers on a dedicated machine or instance. That works best. + +Internet can fail. Yep I guess you may know that already. Today we have a fail fast setup, meaning if we get an error when we fetch a page that we can't handle or was prepared for, we fail and stop the run. That's good in a way because we will try it the next run. But it's bad because if we have a problem, we don't retry (it could be a problem that only exists for a second). In coming releases we will add retry and even better error handling. + +We use [Loggly](http://loggly.com/) to keep track of errors, you should use something like that to make sure everything works fine. + +## Crontab setup for dashboard.sitespeed.io +How do we run the jobs on dashboard.sitespeed.io? We have setup the crontab for the root user like this. + +~~~ +SHELL=/bin/bash +PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin +0,30 * * * * docker run --privileged --rm -v /sitespeed.io:/sitespeed.io sitespeedio/sitespeed.io sitespeed.io --sites urls/united.txt --sites urls/aa.txt --sites urls/ryanair.txt --sites urls/lufthansa.txt -b firefox -n 3 --connection cable -r /tmp/ -d 0 --graphiteHost MY_SECRET_HOST --no-html --seleniumServer http://127.0.0.1:4444/wd/hub --phantomjsPath /usr/local/phantomjs/bin/phantomjs >> /tmp/sitespeed-run.txt 2>&1 +15 * * * * docker run --privileged --rm -v /sitespeed.io:/sitespeed.io sitespeedio/sitespeed.io-standalone sitespeed.io -f urls/nytimes.txt --wptHost www.webpagetest.org --wptKey MY_SUPER_SECRET_KEY --graphiteNamespace webpagetest -d 0 -r /tmp/ --graphiteHost MY_SECRET_HOST --noYslow --wptConfig wpt.json >> /tmp/sitespeed-run-wpt.txt 2>&1 +45 * * * * docker run --privileged --rm -v /sitespeed.io:/sitespeed.io sitespeedio/sitespeed.io sitespeed.io -u https://www.sitespeed.io -d 0 -n 3 -b chrome --connection mobile3g -r /tmp/ -d 0 --graphiteHost MY_SECRET_HOST --no-html --customScripts scripts --graphiteNamespace sitespeed.io.custom.mobile3g --seleniumServer http://127.0.0.1:4444/wd/hub --phantomjsPath /usr/local/phantomjs/bin/phantomjs >> /tmp/sitespeed.io-run.txt 2>&1 +~~~ + +# Example setup: Digital Ocean + +In this example we will use [Digital Ocean](https://www.digitalocean.com/), because they are super fast. Today they have data centers in San Francisco, New York, London, Amsterdam and Singapore. You can choose to deploy on one or all of them. + +When we've been testing, we have seen that you can Firefox or Chrome on a $5 instance (remember to setup the swap space!). In this example we will use a $20 instance and put everything on that. + +* Create a new droplet, choose the one with *2 GB / 2 CPUs 40 GB SSD Disk* and the region you want. +Click on the *Application* tab and choose *Docker on 14.04* +* Remember to add the **SSH keys** for your user. Follow the [tutorial](https://www.digitalocean.com/community/tutorials/how-to-use-ssh-keys-with-digitalocean-droplets) of how to create your SSH keys. +* Start your droplet. +* When it is up and running, log into your server *ssh root@YOUR_IP* +* Setup the server following Digital Oceans [Initial Server Setup Guide](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04) to make your server a little more secure. +* [Add swap space](https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04) and avoid out of memory errors. +* Pull the Docker images: +*sudo docker pull sitespeedio/sitespeed.io* , +*sudo docker pull sitespeedio/graphite* and *sudo docker pull grafana/grafana* +* Create the directories: + +~~~ +sudo mkdir -p /data/graphite/storage/whisper +sudo mkdir -p /data/grafana +sudo mkdir /sitespeed.io +~~~ +* Start Grafana & Graphite (first create your own .htpasswd file and change the user and admin user password): + +~~~ +sudo docker run -d \ + --name graphite \ + -p 8080:80 \ + -p 2003:2003 \ + --restart="always" \ + -v /data/graphite/storage/whisper:/opt/graphite/storage/whisper \ + -v /your/path/.htpasswd:/etc/nginx/.htpasswd \ + sitespeedio/graphite + +sudo docker run -d -p 3000:3000 \ +-v /data/grafana:/var/lib/grafana \ +-e "GF_SECURITY_ADMIN_USER=myuser" \ +-e "GF_SECURITY_ADMIN_PASSWORD=MY_SUPER_STRONG_PASSWORD" \ +--name grafana \ +--restart="always" \ +grafana/grafana +~~~ + +* Create a file with the URL:s you want to test by *sudo nano /sitespeed.io/urls.txt*: + +~~~ +http://www.myfirsturl.com +http://www.myfirsturl.com/1/ +http://www.myfirsturl.com/2/ +http://www.myfirsturl.com/3/ +~~~ + +* **sudo crontab -e** (choose nano and make sure to edit your YOUR_GRAPHITE_HOST to the IP of your server). + +~~~ +SHELL=/bin/bash +PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin +0,15,30,45 * * * * docker run --privileged --rm -v /sitespeed.io:/sitespeed.io sitespeedio/sitespeed.io sitespeed.io -f urls.txt -b firefox -n 11 --connection cable -r /tmp/ --graphiteHost YOUR_GRAPHITE_HOST --seleniumServer http://127.0.0.1:4444/wd/hub >> /tmp/sitespeed-run.txt 2>&1 +~~~ + + +* The next step is to log in to your Grafana instance and configure Graphite as your backend. Then you can start creating your own dashboards. diff --git a/docs/3.x/performance-dashboard/one-page.png b/docs/3.x/performance-dashboard/one-page.png new file mode 100644 index 0000000000..e4abb6c634 Binary files /dev/null and b/docs/3.x/performance-dashboard/one-page.png differ diff --git a/docs/3.x/performance-dashboard/perasset.png b/docs/3.x/performance-dashboard/perasset.png new file mode 100644 index 0000000000..697e2bc562 Binary files /dev/null and b/docs/3.x/performance-dashboard/perasset.png differ diff --git a/docs/3.x/performance-dashboard/summary.png b/docs/3.x/performance-dashboard/summary.png new file mode 100644 index 0000000000..2196d0b869 Binary files /dev/null and b/docs/3.x/performance-dashboard/summary.png differ diff --git a/docs/3.x/performance-dashboard/webpagetest.png b/docs/3.x/performance-dashboard/webpagetest.png new file mode 100644 index 0000000000..13b0d7619c Binary files /dev/null and b/docs/3.x/performance-dashboard/webpagetest.png differ diff --git a/docs/3.x/result/assets-report-3.png b/docs/3.x/result/assets-report-3.png new file mode 100644 index 0000000000..0fed52f3a6 Binary files /dev/null and b/docs/3.x/result/assets-report-3.png differ diff --git a/docs/3.x/result/detailed-site-report-3.png b/docs/3.x/result/detailed-site-report-3.png new file mode 100644 index 0000000000..3ad167b604 Binary files /dev/null and b/docs/3.x/result/detailed-site-report-3.png differ diff --git a/docs/3.x/result/detailed-site-summary-3.png b/docs/3.x/result/detailed-site-summary-3.png new file mode 100644 index 0000000000..7df937b19c Binary files /dev/null and b/docs/3.x/result/detailed-site-summary-3.png differ diff --git a/docs/3.x/result/domains-report-3.png b/docs/3.x/result/domains-report-3.png new file mode 100644 index 0000000000..32a0a64ce0 Binary files /dev/null and b/docs/3.x/result/domains-report-3.png differ diff --git a/docs/3.x/result/full-page-report-3.png b/docs/3.x/result/full-page-report-3.png new file mode 100644 index 0000000000..25562966cc Binary files /dev/null and b/docs/3.x/result/full-page-report-3.png differ diff --git a/docs/3.x/result/hotlist-report-3.png b/docs/3.x/result/hotlist-report-3.png new file mode 100644 index 0000000000..0fb3dc33f4 Binary files /dev/null and b/docs/3.x/result/hotlist-report-3.png differ diff --git a/docs/3.x/result/index.md b/docs/3.x/result/index.md new file mode 100644 index 0000000000..5fe55f862f --- /dev/null +++ b/docs/3.x/result/index.md @@ -0,0 +1,84 @@ +--- +layout: default +title: The result - Documentation - sitespeed.io +description: Result from an analyze using sitespeed.io. +keywords: configuration, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Result from an analyze using sitespeed.io. +--- +[Documentation 3.x](/documentation/) / Result + +# The Result +{:.no_toc} + +* Lets place the TOC here +{:toc} + +# HTML +The result of an analyze can be a couple of HTML pages, JUnit XML/TAP and you can +send the metrics to [Graphite](#graphite). Lets first checkout the different HTML pages. + +## Site summary page + +The summary page is a executive summary page where green is good, yellow means that you should look into it and red is bad (sometimes really bad). The page shows a summary of best practices for good web site performance (and site speed metrics if configured). You can choose which boxes/best practices that will be shown on this page, so you can create different views for different use cases. + +![Site summary page](site-summary-3.png) +{: .img-thumbnail} + + +## The detailed summary page + +The detailed summary page will give you almost all the metrics you want for you site. You will get the average, 10th percentile, median, 95th percentile, min, max and standard deviation value for each metrics (this page is based on the **summary.json** file, where you also will find the variance and the 90th percentile, if ever needed when comparing metrics). + +![Detailed site summary page](detailed-site-summary-3.png) +{: .img-thumbnail} + + +## Detailed site report + +The detailed site report page shows data collected for each page. You can configure which metrics/data that you want to show in the columns, so you can choose what is extra important for you. + +![Detailed site report](detailed-site-report-3.png) +{: .img-thumbnail} + +## Full page analyzes + +Every page that is tested, also get a corresponding HTML page, where all in deep data is shown. Checkout the [examples](/example/) section to see what it looks like. + +![Full page report](full-page-report-3.png) +{: .img-thumbnail} + +## Most used assets report +The most used assets report show you the most used assets (a.k.a which asset should you start to change to get the most bang for the money). + +You will see the following for each asset: the type, the time since last modification, the cache time, the weight and the number of times the asset has been used. + +![Assets report](assets-report-3.png) +{: .img-thumbnail} + +## Hotlist +The hotlist is a way of trying to find bad pages/assets that you should focus on to get better performance. + +![Hotlist report](hotlist-report-3.png) +{: .img-thumbnail} + +## Domains +If you fetch timings using your browser, the domains page will be created, that shows timings per domain, making it easier to spot 3rd party domains that is slow. + +![Domains report](domains-report-3.png) +{: .img-thumbnail} + +## Screenshots + +You can choose to take screenshots of every tested page for the used viewport. + +# JSON +All collected data will be stored as a fat JSON file in your data directory if you add *storeJson* when you run sitespeed.io. That is good if you yourself want to harvest the data from the result. + +# Graphite +Most of the collected metrics can be stored in Graphite, making it easy for you to graph the metrics. Checkout the [Graph section](/documentation/graphs/). + +# TAP and JUnit XML +You can create TAP or JUnit XML from your analyze, head over to the [Continuous Integration section](/documentation/continuous-integration/#generating-junit-xml-or-tap). diff --git a/docs/3.x/result/site-summary-3.png b/docs/3.x/result/site-summary-3.png new file mode 100644 index 0000000000..b9f049118f Binary files /dev/null and b/docs/3.x/result/site-summary-3.png differ diff --git a/docs/3.x/rules-and-best-practices/index.md b/docs/3.x/rules-and-best-practices/index.md new file mode 100644 index 0000000000..f5b07a861a --- /dev/null +++ b/docs/3.x/rules-and-best-practices/index.md @@ -0,0 +1,185 @@ +--- +layout: default +title: The performace best practices rules used by Sitespeed.io +description: Here are the list of performance best practices rules used by sitespeed.io when analyzing your website. It will check for SPOF, synchronously loaded javascripts inside head and a lot of more things. +author: Peter Hedenskog +keywords: sitespeed.io, rules, wpo, fast, speed, web performance optimization, best practices +nav: documentation + +--- +[Documentation 3.x](/documentation/) / Rules and best practices + +# The rules +{:.no_toc} + +Sitespeed.io uses performance best practices rules to decide if a page is optimized for performance. The idea of rules for performance was started by Steve Souders +[14 rules for faster loading websites](http://stevesouders.com/hpws/rules.php) in 2007. Those rules and a couple of more is implemented in YSlow. Sitespeed.io uses these rules and approx. 20 more (it has happened things since 2007). You can see all rules used [here](#allrules). There are two set of rules; desktop & mobile. Desktop is the default one and described on this page. The mobile rules are the same rules, but they have different weight. + You can see the exact implementation [here](https://github.com/soulgalore/yslow/blob/master/src/common/rulesets/ruleset_sitespeed.js). + +## Don't break the rules! +{:.no_toc} + +Sitespeed.io is very demanding on your site, it will test/analyze and punish hard if you have broken the most important rules. + +Sitespeed.io uses about 20 of the basic rules from YSlow (read about them + [here](http://yslow.org#web_performance_best_practices_and_rules) and [here](https://github.com/marcelduran/yslow/wiki/Ruleset-Matrix) and then there are the sitespeed.io specific rules. + +## The rules +{:.no_toc} + +* Lets place the TOC here +{:toc} + +### Critical Rendering Path +Every request fetched inside of HEAD, will postpone the rendering of the page! Do not load javascript synchronously inside of head, load files from the same domain as the main document (to avoid DNS lookups) and inline CSS for a really fast rendering path. The scoring system for this rule, will give you minus score for synchronously loaded javascript inside of head, CSS files requested inside of head and minus for every DNS lookup inside of head. If you want to have a really fast first paint (and you always want that), make sure to score high on this rule. + + +You can read more about the critical rendering path in [this](http://calendar.perfplanet.com/2012/deciphering-the-critical-rendering-path/) article by Ilya Grigorik and [this](http://www.phpied.com/css-and-the-critical-path/) post by Stoyan Stefanov. +{: .note .note-info} + + +### Never scale images in HTML +Images should always be sent with the correct size else the browser will download an image that is larger than necessary. This is more important today with responsive web design, meaning you want to avoid downloading non scaled images to a mobile phone or tablet. Note: This rule doesn't check images with size 0 (images in carousels etc), so they will be missed by the rule. + + +Set the viewport size when you analyze a page and you will get the real image size & the image screen size with this rule! +{: .note .note-info} + +### Frontend single point of failure (SPOF) +A page can be stopped to be loaded in the browser, if a single script, css and in some cases a font couldn't be fetched or loading slow (the white screen of death!). You really want to avoid that. Never load 3rd party components inside of head! One important note, right now this rule treats domain and subdomains as ok, that match the document domain, all other domains is treated as a SPOF. The score is calculated like this: Synchronously loaded javascripts inside of head, hurts you the most & then CSS files inside of head hurts a little less. You can also look for Font Face inside of CSS files and inline font face files, but they are considered minor and not turned on by default. One rule SPOF rule missing is the IE specific feature, that a font face will be SPOF if a script is requested before the font face file. + + + +Read more about SPOF in [this](http://www.stevesouders.com/blog/2010/06/01/frontend-spof/") nice blog post by Steve Souders. +{: .note .note-info} + + +### Low number of total requests +Avoid have too many requests on your page. The more requests, the slower the page will be. This is extremely important on mobile devices, keep the requests as few as possible. But remember that using SPDY and the forthcoming HTTP 2.0, requests to the same domain will be done at the same time, meaning the total number of requests will be less important. + +### Do not load specific CSS file for print +Loading a specific stylesheet for print, can block rendering in your browser (depending on version) and will for almost all browsers, block the onload event to fire (even though the print stylesheet isn't even used). In the old times, it was ok to have own print styles, but nowadays you can keep them in the same CSS file. + + +You can read more about it [here](http://www.phpied.com/5-years-later-print-css-still-sucks/). +{: .note .note-info} + +### Load CSS in HEAD from document domain +CSS files inside of the HEAD tag, should be loaded from the same domain as the main document, in order to avoid DNS lookups. This is extra important for mobile. This rule exist in YSLow don't work on PhantomJS. This modified version do. + +### Never load JS synchronously in HEAD +Javascript files should never be loaded synchronously inside the HEAD tag, because it will block the rendering of the page. This rule exist in YSLow don't work on PhantomJS. This modified version do. + +### Avoid use of web fonts +Avoid use of web fonts because they will decrease the performance of the page. Web fonts are faster today then they ever has been, but still they will decrease performance. + + +Read [more](http://www.stevesouders.com/blog/2009/10/13/font-face-and-performance/) about avoiding web fonts. +{: .note .note-info} + +### Have expire headers for static components +This is a modified version of YSlow expire rule, it will look for assets without any expire headers, meaning all assets without any expire headers will be reported. + +### Have expires headers equals or longer than one year +Having really long cache headers are beneficial for caching. + +### Avoid DNS lookups when the page has few request +If you have few requests on a page, they should all be on the same domain to avoid DNS lookups, because the lookups will cost much. This rule only kicks in if you have fewer request than 10 on the page. + +### Do not load stylesheet files when the page has few request +When a page has few requests (or actually maybe always if you don't have a massive amount of CSS), it is better to inline the CSS, to make the page to start render as early as possible. + +### Have a reasonable percentage of textual content compared to the rest of the page +Make sure you don't have too much styling etc that hides the text you want to deliver. + + +### Load third party JS asynchronously +Always load third party javascript asynchronously. Third parties that will be checked are Twitter, Facebook, Google (api, analytics, ajax), LinkedIn, Disqus, Pinterest & JQuery. + + +Read more about asynchronously third party scripts [here](http://www.phpied.com/3PO#async). This rule is borrowed from Stoyan Stefanov :) +{: .note .note-info} + + + +

The rules

+

The rules are a mashup between classic YSlow rules & new sitespeed.io rules, all are based on performance best practices. The current version of the rules is sitespeed.io-desktop. + +

Avoid slowing down the critical rendering path (criticalpath)

+

Every request fetched inside of HEAD, will postpone the rendering of the page! Do not load javascript synchronously inside of head, load files from the same domain as the main document (to avoid DNS lookups) and inline CSS for a really fast rendering path. The scoring system for this rule, will give you minus score for synchronously loaded javascript inside of head, css files requested inside of head and minus score for every DNS lookup inside of head.Weight: 15

+

Frontend single point of failure (spof)

+

A page can be stopped to be loaded in the browser, if a single script, css and in some cases a font couldn't be fetched or loading slow (the white screen of death), and that is something you really want to avoid. Never load 3rd party components inside of head! One important note, right now this rule treats domain and subdomains as ok, that match the document domain, all other domains is treated as a SPOF. The score is calculated like this: Synchronously loaded javascripts inside of head, hurts you the most, then CSS files inside of head hurts a little less, font face inside of css files further less, and least inline font face files. One rule SPOF rule missing is the IE specific feature, that a font face will be SPOF if a script is requested before the font face file.Weight: 5

+

Make fewer HTTP requests for CSS files (cssnumreq)

+

Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Combine your CSS files into as few as possible.Weight: 8

+

Make fewer HTTP requests for CSS image files (cssimagesnumreq)

+

Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Combine your CSS images files into as few CSS sprites as possible.Weight: 8

+

Make fewer synchronously HTTP requests for Javascript files (jsnumreq)

+

Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Combine your Javascript files into as few as possible (and load them asynchronously).Weight: 8

+

Avoid empty src or href (yemptysrc)

+

You may expect a browser to do nothing when it encounters an empty image src. However, it is not the case in most browsers. IE makes a request to the directory in which the page is located; Safari, Chrome, Firefox 3 and earlier make a request to the actual page itself. This behavior could possibly corrupt user data, waste server computing cycles generating a page that will never be viewed, and in the worst case, cripple your servers by sending a large amount of unexpected traffic.Weight: 30

+

Compress components with gzip (ycompress)

+

Compression reduces response times by reducing the size of the HTTP response. Gzip is the most popular and effective compression method currently available and generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip.Weight: 8

+

Put CSS at top (ycsstop)

+

Moving style sheets to the document HEAD element helps pages appear to load quicker since this allows pages to render progressively.Weight: 4

+

Put JavaScript at bottom (yjsbottom)

+

JavaScript scripts block parallel downloads; that is, when a script is downloading, the browser will not start any other downloads. To help the page load faster, move scripts to the bottom of the page if they are deferrable.Weight: 4

+

Avoid CSS expressions (yexpressions)

+

CSS expressions (supported in IE beginning with Version 5) are a powerful, and dangerous, way to dynamically set CSS properties. These expressions are evaluated frequently: when the page is rendered and resized, when the page is scrolled, and even when the user moves the mouse over the page. These frequent evaluations degrade the user experience.Weight: 3

+

Reduce DNS lookups (ydns)

+

The Domain Name System (DNS) maps hostnames to IP addresses, just like phonebooks map people's names to their phone numbers. When you type URL www.yahoo.com into the browser, the browser contacts a DNS resolver that returns the server's IP address. DNS has a cost; typically it takes 20 to 120 milliseconds for it to look up the IP address for a hostname. The browser cannot download anything from the host until the lookup completes.Weight: 3

+

Minify JavaScript and CSS (yminify)

+

Minification removes unnecessary characters from a file to reduce its size, thereby improving load times. When a file is minified, comments and unneeded white space characters (space, newline, and tab) are removed. This improves response time since the size of the download files is reduced.Weight: 4

+

Never do redirects (redirects)

+

Redirects is bad for performance, specially for mobile.Weight: 4

+

Remove duplicate JavaScript and CSS (noduplicates)

+

Duplicate JavaScript and CSS files hurt performance by creating unnecessary HTTP requests (IE only) and wasted JavaScript execution (IE and Firefox). In IE, if an external script is included twice and is not cacheable, it generates two HTTP requests during page loading. Even if the script is cacheable, extra HTTP requests occur when the user reloads the page. In both IE and Firefox, duplicate JavaScript scripts cause wasted time evaluating the same scripts more than once. This redundant script execution happens regardless of whether the script is cacheable.Weight: 4

+

Configure entity tags (ETags) (yetags)

+

Entity tags (ETags) are a mechanism web servers and the browser use to determine whether a component in the browser's cache matches one on the origin server. Since ETags are typically constructed using attributes that make them unique to a specific server hosting a site, the tags will not match when a browser gets the original component from one server and later tries to validate that component on a different server.Weight: 2

+

Make AJAX cacheable (yxhr)

+

One of AJAX's benefits is it provides instantaneous feedback to the user because it requests information asynchronously from the backend web server. However, using AJAX does not guarantee the user will not wait for the asynchronous JavaScript and XML responses to return. Optimizing AJAX responses is important to improve performance, and making the responses cacheable is the best way to optimize them.Weight: 4

+

Use GET for AJAX requests (yxhrmethod)

+

When using the XMLHttpRequest object, the browser implements POST in two steps: (1) send the headers, and (2) send the data. It is better to use GET instead of POST since GET sends the headers and the data together (unless there are many cookies). IE's maximum URL length is 2 KB, so if you are sending more than this amount of data you may not be able to use GET.Weight: 3

+

Reduce the number of DOM elements (mindom)

+

A complex page means more bytes to download, and it also means slower DOM access in JavaScript. Reduce the number of DOM elements on the page to improve performance.Weight: 3

+

Avoid HTTP 404 (Not Found) error (yno404)

+

Making an HTTP request and receiving a 404 (Not Found) error is expensive and degrades the user experience. Some sites have helpful 404 messages (for example, "Did you mean ...?"), which may assist the user, but server resources are still wasted.Weight: 4

+ +

HTTP cookies are used for authentication, personalization, and other purposes. Cookie information is exchanged in the HTTP headers between web servers and the browser, so keeping the cookie size small minimizes the impact on response time.Weight: 3

+ +

When the browser requests a static image and sends cookies with the request, the server ignores the cookies. These cookies are unnecessary network traffic. To workaround this problem, make sure that static components are requested with cookie-free requests by creating a subdomain and hosting them there.Weight: 3

+

Avoid AlphaImageLoader filter (ynofilter)

+

The IE-proprietary AlphaImageLoader filter attempts to fix a problem with semi-transparent true color PNG files in IE versions less than Version 7. However, this filter blocks rendering and freezes the browser while the image is being downloaded. Additionally, it increases memory consumption. The problem is further multiplied because it is applied per element, not per image.Weight: 4

+

Never scale images in HTML (avoidscalingimages)

+

Images should always be sent with the correct size else the browser will download an image that is larger than necessary. This is more important today with responsive web design, meaning you want to avoid downloading non scaled images to a mobile phone or tablet. Note: This rule doesn check images with size 0 (images in carousels etc), so they will be missed by the rule.The rule also skip images where the difference between the sizes are less than a configurable value (default 100 pixels).Weight: 5

+

Make favicon small and cacheable (yfavicon)

+

A favicon is an icon associated with a web page; this icon resides in the favicon.ico file in the server's root. Since the browser requests this file, it needs to be present; if it is missing, the browser returns a 404 error (see "Avoid HTTP 404 (Not Found) error" above). Since favicon.ico resides in the server's root, each time the browser requests this file, the cookies for the server's root are sent. Making the favicon small and reducing the cookie size for the server's root cookies improves performance for retrieving the favicon. Making favicon.ico cacheable avoids frequent requests for it.Weight: 2

+

Load third party javascript asynchronously (thirdpartyasyncjs)

+

Always load third party javascript asynchronously. Third parties that will be checked are twitter, facebook, google (api, analythics, ajax), linkedin, disqus, pinterest & jquery.Weight: 10

+

Avoid loading specific css for print (cssprint)

+

Loading a specific stylesheet for print, can block rendering in your browser (depending on browser version) and will for almost all browsers, block the onload event to fire (even though the print stylesheet is not even used!).Weight: 3

+

Load CSS in head from document domain (cssinheaddomain)

+

CSS files inside of HEAD should be loaded from the same domain as the main document, in order to avoid DNS lookups, because you want to have the HEAD part of the page finished as fast as possible, for the browser to be abe to start render the page. This is extra important for mobile.Weight: 8

+

Never load JS synchronously in head (syncjsinhead)

+

Javascript files should never be loaded synchronously in HEAD, because it will block the rendering of the page.Weight: 20

+

Avoid use of web fonts (avoidfont)

+

Avoid use of webfonts because they will decrease the performance of the page.Weight: 1

+

Reduce number of total requests (totalrequests)

+

Avoid to have too many requests on your page. The more requests, the slower the page will be for the end user.Weight: 10

+

Have expire headers for static components (expiresmod)

+

By adding HTTP expires headers to your static files, the files will be cached in the end users browser.Weight: 10

+

Have expires headers equals or longer than one year (longexpirehead)

+

Having really long cache headers are beneficial for caching.Weight: 5

+

Avoid DNS lookups when a page has few requests (nodnslookupswhenfewrequests)

+

If you have few requests on a page, they should all be on the same domain to avoid DNS lookups, because the lookups will cost much.Weight: 8

+

Do not load css files when the page has few request (inlinecsswhenfewrequest)

+

When a page has few requests (or actually maybe always if you dont have a massive amount of css), it is better to inline the css, to make the page to start render as early as possible.Weight: 7

+

Have a reasonable percentage of textual content compared to the rest of the page (textcontent)

+

Make sure the amount of HTML elements are too many compared to text content.Weight: 1

+

Always use latest versions of third party javascripts (thirdpartyversions)

+

Always use the latest & greatest versions of third party javascripts, this is really important for JQuery, since the latest versions is always faster & better.Weight: 5

+

Use a Content Delivery Network (CDN) (ycdn)

+

User proximity to web servers impacts response times. Deploying content across multiple geographically dispersed servers helps users perceive that pages are loading faster.Weight: 6

+

Do not close the connection (connectionclose)

+

Check if the site closes a connection to a domain, where we have multiple requests. Use Keep-Alive headers and never close a connectionWeight: 7

+

Do not use private headers on static assets (privateheaders)

+

Make all static assets cacheable for everyone and don't set private cache headers. Will check for private headers for css, images, cssimages, fonts, flash & favicon.Weight: 3

diff --git a/docs/3.x/use-cases/index.md b/docs/3.x/use-cases/index.md new file mode 100644 index 0000000000..a79e546974 --- /dev/null +++ b/docs/3.x/use-cases/index.md @@ -0,0 +1,85 @@ +--- +layout: default +title: Use Cases - Documentation - sitespeed.io +description: Use Cases for running sitespeed.io. +keywords: use case, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Use Cases for running sitespeed.io. +--- +[Documentation 3.x](/documentation/) / Use Cases + +# Use Cases +{:.no_toc} + +* Lets place the TOC here +{:toc} + +## Crawl and test one site +One of the most common use case is to crawl a site and analyze and measure the URL:s. Crawling a site is good because it will find new pages that are linked for the pages you crawl. + +I use this for sites where the content team creates new pages directly in the CMS and I as developer are out of control of which pages that exist. Crawling will make sure we pick up new pages and measure them. I usually use this in production to pick up pages that could/should be faster. + +Crawling too deep can take long time. One way to handle that is to test specific sections one at a time. Say we want to test sport pages for New York Times: + +~~~bash +sitespeed.io -u http://www.nytimes.com/pages/sports/ -c /sports/ -d 2 +~~~ + +Will make sure we only pick up pages under /sports/. + +## Test specific URL:s for one site +Testing the same URL over and over again is good so you can benchmark it. I use it in my continuous integration tool (to check the performance before changes is released) and when I compare sites to its competitors (matching start pages, product pages, purchase flows etc). + + +### How do I choose which URL:s to test? +I usually use Google Analytics to check which are the most pages or talk to the business to check that we have the same understanding of which pages are the most important of our site. If we going to test the URL:s in our continuous integration, I try to keep the list of URL:s small, max 10, so we can test each URL many times to get timings that consistent between runs. + +### Setup +I create a text file named amazon.txt with all the URL:s + +~~~ +http://www.amazon.com/ +http://www.amazon.com/gp/site-directory/ +http://www.amazon.com/dp/B00I15SB16/ref=ods_gw_comb_xmas_kindle +~~~ + +And run it like this + +~~~bash +sitespeed.io -f amazon.txt -b chrome -n 11 +~~~ + +## Compare and benchmark your site against other sites +Comparing your site against competitors is often very interesting. I usually use it to compare how fast pages are loaded and also how the pages are built (how many requests, how much javascript etc). + +### Setup the files +I create one file containing the urls for each site that I want to test. Testing apple.com I create file named **apple.txt** with the URL:s I want to test: + +~~~ +http://www.apple.com/ +http://www.apple.com/iphone/ +http://www.apple.com/iphone-6/ +~~~ + +and I compare it to Sony Mobile. I create a new text file named **sony.txt** with the following content: + +~~~ +http://www.sonymobile.com/se/ +http://www.sonymobile.com/se/products/phones/ +http://www.sonymobile.com/se/products/phones/xperia-z3-compact/ +~~~ + +### Run the test +Then I run it like this: + +~~~bash +sitespeed.io --sites apple.txt --sites sony.txt -d 0 +~~~ + +Of course you can add all the parameters as usual to sitespeed, testing your site using Chrome, test 11 times and also test with WebPageTest and Google Page Speed Insights and sending the data to Graphite looks like this: + +~~~bash +sitespeed.io --sites apple.txt --sites sony.txt -d 0 -b chrome -n 11 --wptHost your.webpagetest.com --gpsiKey YOUR_GOOGLE_KEY --graphiteHost mygraphitehost.com +~~~ diff --git a/docs/3.x/webpagetest/index.md b/docs/3.x/webpagetest/index.md new file mode 100644 index 0000000000..98fbc46c6d --- /dev/null +++ b/docs/3.x/webpagetest/index.md @@ -0,0 +1,152 @@ +--- +layout: default +title: WebPageTest - Documentation - sitespeed.io +description: Drive WebPageTest using sitespeed.io and include the teh metrics in your sitespeed.io report. +keywords: webpagetest, wpt, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Drive WebPageTest using sitespeed.io and include the teh metrics in your sitespeed.io report. +--- +[Documentation 3.x](/documentation/) / WebPageTest + +# WebPageTest +{:.no_toc} + +* Lets place the TOC here +{:toc} + +# Using WebPageTest +Yep we all love [WebPageTest](http://www.webpagetest.org) (WPT), so we made it possible to drive an instance of and collect the data from it. + +To use WPT you can either get an [API key](http://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/). + +Out of the it will collect [these](https://github.com/sitespeedio/sitespeed.io/tree/master/lib/aggregators/webpagetest) metrics that can be displayed on the summary page. By default, these will be shown: + +![WebPageTest summary](wpt-summary.png) +{: .img-thumbnail} + +On the pages summary, you will also automatically get the SpeedIndex score: +![WebPageTest pages](wpt-pages.png) +{: .img-thumbnail} + +And on the detailed summary page, we show some interesting metrics and the waterfalls +for the median result of both first and repeated view: + +![WebPageTest page info](wpt-detailed-page-info.png) +{: .img-thumbnail} + +## Configuration +There is some default configuration that is passed to WebPageTest. It looks like this: + +~~~ +{ + pollResults: 10, + timeout: 600, + firstViewOnly: false, + runs: n, // the number of times passed by -n, default 3 + private: true, + aftRenderingTime: true, + location: 'Dulles:Chrome', + video: true +} +~~~ + +And if basic auth is set, it is passed as basic auth. + + +In the background the test method in Marcel Durans webpagetest-api is used, so you can configure almost everything. Checkout the docs [here](https://github.com/marcelduran/webpagetest-api#user-content-test-works-for-test-command-only). You configure your own stuff by feeding sitespeed.io with a JSON file. Say you want to test form Dulles using a throttled 3G connection: + +~~~ +{ + "location": "Dulles:Firefox", + "connectivity": "3G" +} +~~~ +The default location will be overidden and the connectivity will be set to 3G. +Feed it with: *--wptConfig yourFile.json* + + +If you want to test from multiple locations, browsers or different connectivity, pass an array as configuration: + +~~~ +[ + { + "location": "Dulles:Firefox", + "connectivity": "3G" + }, + { + "location": "Dulles:Chrome", + "connectivity": "Cable" + } +] +~~~ + +### WebPageTest scripting +WebPageTest has scripting capability where you can automate a multi-step test (=login the user and do stuff). That is supported by sitespeed.io by supplying the script. Do like this. Create your script file (checkout WebPageTest [documentation](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/scripting)). It can look something like this (wptScript.txt): + +~~~ +logData 0 + +// put any urls you want to navigate +navigate www.aol.com +navigate news.aol.com + +logData 1 + +// this step will get recorded +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 (and add the parameters as you usually do): + +~~~ +sitespeed.io --wptScript wptScript.txt --wptHost my.wpt.host.com -u http://example.org +~~~ + + +### Custom metrics +Hey we love custom metrics and you can fetch them using WPT. Checkout the [metrics docs](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/custom-metrics) for WPT and then create a file containing your metrics: + +~~~ +[iframe-count] +return document.getElementsByTagName("iframe").length; + +[script-tag-count] +return document.getElementsByTagName("script").length; + +[meta-viewport] +var viewport = undefined; +var metaTags=document.getElementsByTagName("meta"); +for (var i = 0; i < metaTags.length; i++) { + if (metaTags[i].getAttribute("name") == "viewport") { + viewport = metaTags[i].getAttribute("content"); + break; + } +} +return viewport; +~~~ + +Then run sitespeed.io like this: + +~~~ +sitespeed.io --wptCustomMetrics myScriptFile.txt --wptHost my.wpt.host.com +~~~ + +The custom metrics will show up on the individual page and sent to Graphite. + +## Graph the WPT metrics +The data collected and showed can also be sent to Graphite. Checkout the Graphite [section](#graphite-full). + +## WPT performance budget +The timings and metrics collected by WebPageTest can also be used in you performance budget. More info [budget](#budget). + +## Timing metrics collected using WPT +All the metrics are collected both for first and repeated view. + +* *firstPaint* - the time from the start of navigation until the first non-white content was painted to the screen +* *loadTime* - the time from the start of the initial navigation until the beginning of the window load event (onload) +* *TTFB* - the time from the start of navigation until the first byte of the base page is returned (after following any redirects) +* *SpeedIndex* - is the average time at which visible parts of the page are displayed. It is expressed in milliseconds and dependent on size of the view port. You need to [read more](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index) to fully understand how it works. +* *VisualComplete* diff --git a/docs/3.x/webpagetest/wpt-detailed-page-info.png b/docs/3.x/webpagetest/wpt-detailed-page-info.png new file mode 100644 index 0000000000..d56b17e92a Binary files /dev/null and b/docs/3.x/webpagetest/wpt-detailed-page-info.png differ diff --git a/docs/3.x/webpagetest/wpt-pages.png b/docs/3.x/webpagetest/wpt-pages.png new file mode 100644 index 0000000000..9c48872eba Binary files /dev/null and b/docs/3.x/webpagetest/wpt-pages.png differ diff --git a/docs/3.x/webpagetest/wpt-summary.png b/docs/3.x/webpagetest/wpt-summary.png new file mode 100644 index 0000000000..075dfe9065 Binary files /dev/null and b/docs/3.x/webpagetest/wpt-summary.png differ diff --git a/docs/404.md b/docs/404.md new file mode 100644 index 0000000000..4ca0d4bc44 --- /dev/null +++ b/docs/404.md @@ -0,0 +1,6 @@ +--- +layout: notfound +title: 404 Page not found - sitespeed.io +permalink: /404.html +--- +
\ No newline at end of file diff --git a/docs/Gemfile b/docs/Gemfile new file mode 100644 index 0000000000..7434b39d2a --- /dev/null +++ b/docs/Gemfile @@ -0,0 +1,2 @@ +source "https://rubygems.org" +gem 'github-pages', group: :jekyll_plugins diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock new file mode 100644 index 0000000000..5288179334 --- /dev/null +++ b/docs/Gemfile.lock @@ -0,0 +1,139 @@ +GEM + remote: https://rubygems.org/ + specs: + activesupport (4.2.7) + i18n (~> 0.7) + json (~> 1.7, >= 1.7.7) + minitest (~> 5.1) + thread_safe (~> 0.3, >= 0.3.4) + tzinfo (~> 1.1) + addressable (2.4.0) + coffee-script (2.4.1) + coffee-script-source + execjs + coffee-script-source (1.10.0) + colorator (1.1.0) + ethon (0.9.1) + ffi (>= 1.3.0) + execjs (2.7.0) + faraday (0.9.2) + multipart-post (>= 1.2, < 3) + ffi (1.9.14) + forwardable-extended (2.6.0) + gemoji (2.1.0) + github-pages (98) + activesupport (= 4.2.7) + github-pages-health-check (= 1.2.0) + jekyll (= 3.2.1) + jekyll-coffeescript (= 1.0.1) + jekyll-feed (= 0.5.1) + jekyll-gist (= 1.4.0) + jekyll-github-metadata (= 2.1.1) + jekyll-mentions (= 1.2.0) + jekyll-paginate (= 1.1.0) + jekyll-redirect-from (= 0.11.0) + jekyll-sass-converter (= 1.3.0) + jekyll-seo-tag (= 2.0.0) + jekyll-sitemap (= 0.10.0) + jekyll-swiss (= 0.4.0) + jemoji (= 0.7.0) + kramdown (= 1.11.1) + liquid (= 3.0.6) + listen (= 3.0.6) + mercenary (~> 0.3) + minima (= 1.2.0) + rouge (= 1.11.1) + terminal-table (~> 1.4) + github-pages-health-check (1.2.0) + addressable (~> 2.3) + net-dns (~> 0.8) + octokit (~> 4.0) + public_suffix (~> 1.4) + typhoeus (~> 0.7) + html-pipeline (2.4.2) + activesupport (>= 2) + nokogiri (>= 1.4) + i18n (0.7.0) + jekyll (3.2.1) + colorator (~> 1.0) + jekyll-sass-converter (~> 1.0) + jekyll-watch (~> 1.1) + kramdown (~> 1.3) + liquid (~> 3.0) + mercenary (~> 0.3.3) + pathutil (~> 0.9) + rouge (~> 1.7) + safe_yaml (~> 1.0) + jekyll-coffeescript (1.0.1) + coffee-script (~> 2.2) + jekyll-feed (0.5.1) + jekyll-gist (1.4.0) + octokit (~> 4.2) + jekyll-github-metadata (2.1.1) + jekyll (~> 3.1) + octokit (~> 4.0) + jekyll-mentions (1.2.0) + activesupport (~> 4.0) + html-pipeline (~> 2.3) + jekyll (~> 3.0) + jekyll-paginate (1.1.0) + jekyll-redirect-from (0.11.0) + jekyll (>= 2.0) + jekyll-sass-converter (1.3.0) + sass (~> 3.2) + jekyll-seo-tag (2.0.0) + jekyll (~> 3.1) + jekyll-sitemap (0.10.0) + jekyll-swiss (0.4.0) + jekyll-watch (1.5.0) + listen (~> 3.0, < 3.1) + jemoji (0.7.0) + activesupport (~> 4.0) + gemoji (~> 2.0) + html-pipeline (~> 2.2) + jekyll (>= 3.0) + json (1.8.3) + kramdown (1.11.1) + liquid (3.0.6) + listen (3.0.6) + rb-fsevent (>= 0.9.3) + rb-inotify (>= 0.9.7) + mercenary (0.3.6) + mini_portile2 (2.1.0) + minima (1.2.0) + minitest (5.9.1) + multipart-post (2.0.0) + net-dns (0.8.0) + nokogiri (1.6.8.1) + mini_portile2 (~> 2.1.0) + octokit (4.3.0) + sawyer (~> 0.7.0, >= 0.5.3) + pathutil (0.14.0) + forwardable-extended (~> 2.6) + public_suffix (1.5.3) + rb-fsevent (0.9.7) + rb-inotify (0.9.7) + ffi (>= 0.5.0) + rouge (1.11.1) + safe_yaml (1.0.4) + sass (3.4.22) + sawyer (0.7.0) + addressable (>= 2.3.5, < 2.5) + faraday (~> 0.8, < 0.10) + terminal-table (1.7.3) + unicode-display_width (~> 1.1.1) + thread_safe (0.3.5) + typhoeus (0.8.0) + ethon (>= 0.8.0) + tzinfo (1.2.2) + thread_safe (~> 0.1) + unicode-display_width (1.1.1) + +PLATFORMS + ruby + +DEPENDENCIES + github-pages + +BUNDLED WITH + 1.13.2 diff --git a/docs/README.md b/docs/README.md new file mode 100644 index 0000000000..18913712f1 --- /dev/null +++ b/docs/README.md @@ -0,0 +1,7 @@ +Documentation for sitespeed.io +================ + + +To run it locally: bundle install && bundle exec jekyll serve --baseurl ''. + +Checkout https://localhost:4000/ diff --git a/docs/_config.yml b/docs/_config.yml new file mode 100644 index 0000000000..8455912725 --- /dev/null +++ b/docs/_config.yml @@ -0,0 +1,15 @@ +permalink: /:title/ +baseurl: /sitespeed.io +markdown: kramdown +compress_html: + clippings: all + endings: all +kramdown: + enable_coderay: false + coderay: + coderay_wrap: div + coderay_line_numbers: inline + coderay_line_number_start: 1 + coderay_tab_width: 4 + coderay_bold_every: 10 + coderay_css: style diff --git a/docs/_includes/analythics.js b/docs/_includes/analythics.js new file mode 100644 index 0000000000..e69de29bb2 diff --git a/docs/_includes/css/404.css b/docs/_includes/css/404.css new file mode 100644 index 0000000000..58dde4121d --- /dev/null +++ b/docs/_includes/css/404.css @@ -0,0 +1,14 @@ +html { + background-color:#5c90c4; +} + +.data { +text-align: center +} + +.cent { +margin: 20px auto; +max-width: 100%; +display:block; +height: auto; +} \ No newline at end of file diff --git a/docs/_includes/css/default.css b/docs/_includes/css/default.css new file mode 100644 index 0000000000..1a85a583ec --- /dev/null +++ b/docs/_includes/css/default.css @@ -0,0 +1,4 @@ +{% include css/normalize.css %} +{% include css/grid.css %} +{% include css/navigation.css %} +{% include css/sitespeed.css %} diff --git a/docs/_includes/css/grid.css b/docs/_includes/css/grid.css new file mode 100644 index 0000000000..cc59068619 --- /dev/null +++ b/docs/_includes/css/grid.css @@ -0,0 +1,280 @@ +/* + Simple Grid + Project Page - http://thisisdallas.github.com/Simple-Grid/ +*/ + +*, *:after, *:before { + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; +} + +body { + margin: 0px; +} + +[class*='col-'] { + float: left; + padding-right: 20px; + padding-left: 20px; +} + +.grid { + width: 100%; + max-width: 1140px; + min-width: 755px; + margin: 0 auto; + overflow: hidden; +} + +.grid:after { + content: ""; + display: table; + clear: both; +} + +.grid-pad { + padding-top: 20px; + padding-left: 20px; + padding-right: 0px; +} + +.push-right { + float: right; +} + + + +.col-1-1 { + width: 100%; +} +.col-2-3, .col-8-12 { + width: 66.66%; +} + +.col-1-2, .col-6-12 { + width: 50%; +} + +.col-1-3, .col-4-12 { + width: 33.33%; +} + +.col-1-4, .col-3-12 { + width: 25%; +} + +.col-1-5 { + width: 20%; +} + +.col-1-6, .col-2-12 { + width: 16.667%; +} + +.col-1-7 { + width: 14.28%; +} + +.col-1-8 { + width: 12.5%; +} + +.col-1-9 { + width: 11.1%; +} + +.col-1-10 { + width: 10%; +} + +.col-1-11 { + width: 9.09%; +} + +.col-1-12 { + width: 8.33% +} + + +.col-11-12 { + width: 91.66% +} + +.col-10-12 { + width: 83.333%; +} + +.col-9-12 { + width: 75%; +} + +.col-5-12 { + width: 41.66%; +} + +.col-7-12 { + width: 58.33% +} + + + +.push-2-3, .push-8-12 { + margin-left: 66.66%; +} + +.push-1-2, .push-6-12 { + margin-left: 50%; +} + +.push-1-3, .push-4-12 { + margin-left: 33.33%; +} + +.push-1-4, .push-3-12 { + margin-left: 25%; +} + +.push-1-5 { + margin-left: 20%; +} + +.push-1-6, .push-2-12 { + margin-left: 16.667%; +} + +.push-1-7 { + margin-left: 14.28%; +} + +.push-1-8 { + margin-left: 12.5%; +} + +.push-1-9 { + margin-left: 11.1%; +} + +.push-1-10 { + margin-left: 10%; +} + +.push-1-11 { + margin-left: 9.09%; +} + +.push-1-12 { + margin-left: 8.33% +} + + +@media handheld, only screen and (max-width: 767px) { + .grid { + width: 100%; + min-width: 0; + margin-left: 0px; + margin-right: 0px; + padding-left: 20px; + padding-right: 10px; + } + + [class*='col-'] { + width: auto; + float: none; + margin-left: 0px; + margin-right: 0px; + margin-top: 10px; + margin-bottom: 10px; + padding-left: 0px; + padding-right: 10px; + } + + + [class*='mobile-col-'] { + float: left; + margin-left: 0px; + margin-right: 0px; + margin-top: 0px; + margin-bottom: 10px; + padding-left: 0px; + padding-right: 10px; + padding-bottom: 0px; + } + + .mobile-col-1-1 { + width: 100%; + } + .mobile-col-2-3, .mobile-col-8-12 { + width: 66.66%; + } + + .mobile-col-1-2, .mobile-col-6-12 { + width: 50%; + } + + .mobile-col-1-3, .mobile-col-4-12 { + width: 33.33%; + } + + .mobile-col-1-4, .mobile-col-3-12 { + width: 25%; + } + + .mobile-col-1-5 { + width: 20%; + } + + .mobile-col-1-6, .mobile-col-2-12 { + width: 16.667%; + } + + .mobile-col-1-7 { + width: 14.28%; + } + + .mobile-col-1-8 { + width: 12.5%; + } + + .mobile-col-1-9 { + width: 11.1%; + } + + .mobile-col-1-10 { + width: 10%; + } + + .mobile-col-1-11 { + width: 9.09%; + } + + .mobile-col-1-12 { + width: 8.33% + } + + .mobile-col-11-12 { + width: 91.66% + } + + .mobile-col-10-12 { + width: 83.333%; + } + + .mobile-col-9-12 { + width: 75%; + } + + .mobile-col-5-12 { + width: 41.66%; + } + + .mobile-col-7-12 { + width: 58.33% + } + + .hide-on-mobile { + display: none !important; + width: 0; + height: 0; + } +} diff --git a/docs/_includes/css/navigation.css b/docs/_includes/css/navigation.css new file mode 100644 index 0000000000..84e5f82cfe --- /dev/null +++ b/docs/_includes/css/navigation.css @@ -0,0 +1,134 @@ +body { + margin: 0; + padding: 0; + background: #fff; + font-family: Tahoma, Verdana,sans-serif; + font-size: 19px; + line-height: 1.618em; + word-wrap: break-word; +} + +.nav { + background: #0095d2; +} + +.nav ul { + list-style: none; + text-align: center; + padding: 0; + margin: 0; + background-color: #0095d2; +} +.nav li { + font-size: 1em; + line-height: 40px; + height: 40px; + border-bottom: 1px solid #0073b0; +} + +.nav a { + text-decoration: none; + color: #fff; + display: block; +} + +.nav a:hover { + background-color: #0073b0; +} + +.nav a.active { + background-color: #0073b0; + color: #fff; + cursor: default; +} + +.logo { + text-align: center; + background-color: #0095d2; +} + +.navbar-brand { +padding: 0px 0px; +font-size: 18px; +max-width: 250px; +} + +.nav li ul { + position: absolute; + display: none; + width: inherit; +} + +@media screen and (min-width: 820px) { + + body + { padding-top: 50px; } + + .nav { + height: 50px; + width: 100%; + z-index: 1000; + position: fixed; + top: 0; + } + + .navbar-brand { + padding: 0px 0px; + font-size: 18px; + float: left; + max-width: 250px; + } + + .nav a { + padding-left: 20px; + padding-right: 20px; + + } + + .nav { + z-index: 10; + top: 0; + background-color: #0095d2; + } + + .nav li { + border-bottom: none; + height: 50px; + line-height: 50px; + font-size: 1em; + float: left; + display: inline-block; + margin-right: 0px; + } + + .nav a { + text-decoration: none; + color: #fff; + display: block; + } + + .nav ul { + list-style: none; + text-align: center; + padding: 0; + margin: 0; + background-color: #0095d2; + } + + /* Sub Menus */ + .nav li ul { + position: absolute; + display: none; + width: inherit; + } + + .nav li:hover ul { + display: block; + } + + .nav li ul li { + display: block; + float: none; + } + +} diff --git a/docs/_includes/css/normalize.css b/docs/_includes/css/normalize.css new file mode 100644 index 0000000000..c1cefe24c1 --- /dev/null +++ b/docs/_includes/css/normalize.css @@ -0,0 +1,289 @@ +/*! normalize.css v3.0.2 | MIT License | git.io/normalize */ + +html { + font-family: sans-serif; + -ms-text-size-adjust: 100%; + -webkit-text-size-adjust: 100%; +} + + +body { + margin: 0; +} + + +article, +aside, +details, +figcaption, +figure, +footer, +header, +hgroup, +main, +menu, +nav, +section, +summary { + display: block; +} + + + +audio, +canvas, +progress, +video { + display: inline-block; /* 1 */ + vertical-align: baseline; /* 2 */ +} + + + +audio:not([controls]) { + display: none; + height: 0; +} + + +[hidden], +template { + display: none; +} + + + +a { + background-color: transparent; +} + + + +a:active, +a:hover { + outline: 0; +} + + + +abbr[title] { + border-bottom: 1px dotted; +} + + + +b, +strong { + font-weight: bold; +} + + + +dfn { + font-style: italic; +} + + + +h1 { + font-size: 2em; + margin: 0.67em 0; +} + + + +mark { + background: #ff0; + color: #000; +} + + + +small { + font-size: 80%; +} + + + +sub, +sup { + font-size: 75%; + line-height: 0; + position: relative; + vertical-align: baseline; +} + +sup { + top: -0.5em; +} + +sub { + bottom: -0.25em; +} + + + +img { + border: 0; +} + + + +svg:not(:root) { + overflow: hidden; +} + + + +figure { + margin: 1em 40px; +} + + + +hr { + -moz-box-sizing: content-box; + box-sizing: content-box; + height: 0; +} + + + +pre { + overflow: auto; +} + + + +code, +kbd, +pre, +samp { + font-family: monospace, monospace; + font-size: 1em; +} + + +button, +input, +optgroup, +select, +textarea { + color: inherit; /* 1 */ + font: inherit; /* 2 */ + margin: 0; /* 3 */ +} + + + +button { + overflow: visible; +} + + + +button, +select { + text-transform: none; +} + + + +button, +html input[type="button"], /* 1 */ +input[type="reset"], +input[type="submit"] { + -webkit-appearance: button; /* 2 */ + cursor: pointer; /* 3 */ +} + + + +button[disabled], +html input[disabled] { + cursor: default; +} + + + +button::-moz-focus-inner, +input::-moz-focus-inner { + border: 0; + padding: 0; +} + + + +input { + line-height: normal; +} + + + +input[type="checkbox"], +input[type="radio"] { + box-sizing: border-box; /* 1 */ + padding: 0; /* 2 */ +} + + + +input[type="number"]::-webkit-inner-spin-button, +input[type="number"]::-webkit-outer-spin-button { + height: auto; +} + + + +input[type="search"] { + -webkit-appearance: textfield; /* 1 */ + -moz-box-sizing: content-box; + -webkit-box-sizing: content-box; /* 2 */ + box-sizing: content-box; +} + + + +input[type="search"]::-webkit-search-cancel-button, +input[type="search"]::-webkit-search-decoration { + -webkit-appearance: none; +} + + + +fieldset { + border: 1px solid #c0c0c0; + margin: 0 2px; + padding: 0.35em 0.625em 0.75em; +} + + + +legend { + border: 0; /* 1 */ + padding: 0; /* 2 */ +} + + + +textarea { + overflow: auto; +} + + + +optgroup { + font-weight: bold; +} + + + +table { + border-collapse: collapse; + border-spacing: 0; +} + +td, +th { + padding: 0; +} diff --git a/docs/_includes/css/sitespeed.css b/docs/_includes/css/sitespeed.css new file mode 100644 index 0000000000..c520782f43 --- /dev/null +++ b/docs/_includes/css/sitespeed.css @@ -0,0 +1,180 @@ +.blue { + background-color: #e1f6fd; + padding-bottom: 20px; +} + +.copy { + padding-top: 20px; +} + +.flogo { + padding-top: 10px; +} + +footer h3 { + margin-bottom:10px; +} + +.pull-left { +float: left!important; +} + +.pull-right { +float: right!important; +} + +.img-big { +margin-right: 20px; +} + +.img-footer { +margin-top: 15px; +} + +.middle { +vertical-align: middle; +width: 32px; +} + +.fastly { +vertical-align: middle; +height: 32px; +} + +hr { +margin-top: 20px; +margin-bottom: 20px; +border: 0; +border-top: 1px solid #eee; +box-sizing: content-box; +height: 0; +} + +footer p { +text-align: center; +margin: 0; +} + +a { +color: #428bca; +text-decoration: none; +} + +.language-bash { +color: #fff; +background-color: #555; +font-size: 80%; +} + +pre code { +display: block; +padding: 9.5px; +margin: 0 0 10px; +font-size: 13px; +line-height: 1.428571429; +word-break: break-all; +word-wrap: break-word; +color: #333; +background-color: #f5f5f5; +border: 1px solid #ccc; +border-radius: 4px; +font-family: Monaco,Menlo,Consolas,"Courier New",monospace; +white-space: pre-wrap; +} + +.note-info { +background-color: #f0f7fd; +border-color: #d0e3f0; +} +.note { +margin: 20px 0; +padding: 15px 30px 15px 15px; +border-left: 10px solid #eee; +} + +.note-warning { +background-color: #fcf2f2; +border-color: #dfb5b4; +} + +.img-thumbnail img { +padding: 4px; +line-height: 1.428571429; +background-color: #fff; +border: 1px solid #ddd; +border-radius: 4px; +-webkit-transition: all .2s ease-in-out; +transition: all .2s ease-in-out; +display: inline-block; +max-width: 100%; +height: auto; +} + +.small { + font-size: 0.8em; + line-height: 1.2em; +} + +footer ul { + list-style: none; + padding: 0; + margin: 0; +} + +footer li { + padding-bottom: 4px; +} + +footer a { + color: #0095d2; +} + +a btn { + margin-top: 10px; +} + +.photo { +border-radius: 10px; +margin-right: 20px; +margin-bottom: 10px; +} + +.language-help { + overflow: auto; + word-wrap: normal; + white-space: pre; +} + +@media screen and (max-width: 820px) { + .small { + text-align: center; + font-size: 19px; + } + + h1 { + line-height: 1em; + } + + ul { + padding-left: 10px; + margin-left: 10px; + } +} + +.video-container { + position: relative; + padding-bottom: 56.25%; + padding-top: 30px; height: 0; overflow: hidden; + margin-right: 5%; + margin-left: 5%; +} + +.video-container iframe, +.video-container object, +.video-container embed { + position: absolute; + top: 0; + left: 0; + width: 100%; + height: 100%; +} diff --git a/docs/_includes/footer.html b/docs/_includes/footer.html new file mode 100644 index 0000000000..5557d19b76 --- /dev/null +++ b/docs/_includes/footer.html @@ -0,0 +1,60 @@ +
+ + diff --git a/docs/_includes/header.html b/docs/_includes/header.html new file mode 100644 index 0000000000..f5cdad5555 --- /dev/null +++ b/docs/_includes/header.html @@ -0,0 +1,32 @@ +
+
+
+ + +
+
+
diff --git a/docs/_includes/index/box1.md b/docs/_includes/index/box1.md new file mode 100644 index 0000000000..be13cfefdc --- /dev/null +++ b/docs/_includes/index/box1.md @@ -0,0 +1,10 @@ + +{% for post in site.posts limit:1 %} +## {{ post.title }} +* * * + +{{ post.intro }} +[Read the blog post to find out more.]({{ post.url }}) + +{% endfor %} + diff --git a/docs/_includes/index/box2.md b/docs/_includes/index/box2.md new file mode 100644 index 0000000000..959e05ac36 --- /dev/null +++ b/docs/_includes/index/box2.md @@ -0,0 +1,6 @@ +## Be a performance hero! +* * * + +Sitespeed.io logo + +With sitespeed.io it's easy to be a performance hero! Check out our [example dashboard](https://dashboard.sitespeed.io), it's the best example that shows you what you can do. diff --git a/docs/_includes/index/box3.md b/docs/_includes/index/box3.md new file mode 100644 index 0000000000..2595cfafc5 --- /dev/null +++ b/docs/_includes/index/box3.md @@ -0,0 +1,3 @@ +## 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 in a couple of minutes. diff --git a/docs/_includes/index/box4.md b/docs/_includes/index/box4.md new file mode 100644 index 0000000000..72a75198d3 --- /dev/null +++ b/docs/_includes/index/box4.md @@ -0,0 +1,8 @@ +## Why we love sitespeed.io +* * * + + * Uses real browsers (Firefox and Chrome) + * Understand and speaks HTTP/2 + * Plugin support (write your own plugins that handles the data) + * Runs on Linux + * Works great with Graphite and Grafana diff --git a/docs/_includes/index/box5.md b/docs/_includes/index/box5.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/docs/_includes/index/box6.md b/docs/_includes/index/box6.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/docs/_includes/index/box7.md b/docs/_includes/index/box7.md new file mode 100644 index 0000000000..14ebcdb06c --- /dev/null +++ b/docs/_includes/index/box7.md @@ -0,0 +1,9 @@ +## Thank you! +* * * +Sitespeed.io is built upon a couple Open Source tools, massive love to those projects: + + * [Selenium](http://www.seleniumhq.org/) + * [TSProxy](https://github.com/WPO-Foundation/tsproxy) + * [PerfCascade](https://github.com/micmro/PerfCascade) + * [Skeleton](http://getskeleton.com) + * [Simple crawler](https://github.com/cgiffard/node-simplecrawler) diff --git a/docs/_includes/index/box8.md b/docs/_includes/index/box8.md new file mode 100644 index 0000000000..9a7a53ad74 --- /dev/null +++ b/docs/_includes/index/box8.md @@ -0,0 +1,3 @@ +## Contribute +* * * +You can help us making sitespeed.io better! Check the [help section](https://github.com/sitespeedio/sitespeed.io/blob/master/HELP.md) of how you can help us. [These people](https://github.com/sitespeedio/sitespeed.io/blob/master/CONTRIBUTORS.md) has already helped us with pull requests or ideas (massive love!). diff --git a/docs/_includes/userTimings.js b/docs/_includes/userTimings.js new file mode 100644 index 0000000000..1b6e6fc678 --- /dev/null +++ b/docs/_includes/userTimings.js @@ -0,0 +1,4 @@ +/* Thanks Nic Jansma https://github.com/nicjansma/usertiming.js */ +/*! usertiming v0.1.6 */ + +!function(a){"use strict";"undefined"==typeof a&&(a={}),"undefined"==typeof a.performance&&(a.performance={}),a._perfRefForUserTimingPolyfill=a.performance,a.performance.userTimingJsNow=!1,a.performance.userTimingJsNowPrefixed=!1,a.performance.userTimingJsUserTiming=!1,a.performance.userTimingJsUserTimingPrefixed=!1,a.performance.userTimingJsPerformanceTimeline=!1,a.performance.userTimingJsPerformanceTimelinePrefixed=!1;var b,c,d=[],e=[],f=null;if("function"!=typeof a.performance.now){for(a.performance.userTimingJsNow=!0,e=["webkitNow","msNow","mozNow"],b=0;b{% endcapture %}{% assign _content = _content | remove: _end %}{% endfor %}{% if site.compress_html.comments.size == 2 %}{% assign _comment_befores = _content | split: site.compress_html.comments.first %}{% for _comment_before in _comment_befores %}{% assign _comment_content = _comment_before | split: site.compress_html.comments.last | first %}{% if _comment_content %}{% capture _comment %}{{ site.compress_html.comments.first }}{{ _comment_content }}{{ site.compress_html.comments.last }}{% endcapture %}{% assign _content = _content | remove: _comment %}{% endif %}{% endfor %}{% endif %}{% assign _pre_befores = _content | split: "" %}{% case _pres.size %}{% when 2 %}{% capture _content %}{{ _content }}{{ _pres.last | split: " " | join: " " }}{% endcapture %}{% when 1 %}{% capture _content %}{{ _content }}{{ _pres.last | split: " " | join: " " }}{% endcapture %}{% endcase %}{% endfor %}{% if site.compress_html.clippings == "all" %}{% assign _clippings = "html head title base link meta style body article section nav aside h1 h2 h3 h4 h5 h6 hgroup header footer address p hr blockquote ol ul li dl dt dd figure figcaption main div table caption colgroup col tbody thead tfoot tr td th" | split: " " %}{% else %}{% assign _clippings = site.compress_html.clippings %}{% endif %}{% for _element in _clippings %}{% assign _edges = " ;; ;" | replace: "e", _element | split: ";" %}{% assign _content = _content | replace: _edges[0], _edges[1] | replace: _edges[2], _edges[3] | replace: _edges[4], _edges[5] %}{% endfor %}{{ _content }}{% endif %} diff --git a/docs/_layouts/default.html b/docs/_layouts/default.html new file mode 100644 index 0000000000..97526e6249 --- /dev/null +++ b/docs/_layouts/default.html @@ -0,0 +1,63 @@ +--- +layout: compress +--- + + + + + {{ page.title }} + + + + + + + + + + + + + + {% if page.twitterdescription %} + + {% else %} + + {% endif %} + + {% if page.image %} + + {% endif %} + + + + + + + + + + + + + + + + {% include analythics.js %} + + + {% include header.html %} +
+
+ {{ content }} +
+
+
+
+
+ {% include footer.html %} +
+
+
+ + diff --git a/docs/_layouts/notfound.html b/docs/_layouts/notfound.html new file mode 100644 index 0000000000..7ee5d08408 --- /dev/null +++ b/docs/_layouts/notfound.html @@ -0,0 +1,14 @@ +--- +layout: 404 +--- + + + + + {{ page.title }} + + + + {{ content }} + + \ No newline at end of file diff --git a/docs/_layouts/startpage.html b/docs/_layouts/startpage.html new file mode 100644 index 0000000000..d2ba8b44d4 --- /dev/null +++ b/docs/_layouts/startpage.html @@ -0,0 +1,107 @@ +--- +layout: compress +--- + + + + + {{ page.title }} + + + + + + + + + + + + + + {% if page.twitterdescription %} + + {% else %} + + {% endif %} + + {% if page.image %} + + {% endif %} + + + + + + + + + + + + + + + + {% include analythics.js %} + + + {% include header.html %} +
+
+
+ {{ content }} +
+
+
+
+
+ {% capture box1 %}{% include index/box1.md %}{% endcapture %} + {{ box1 | markdownify }} +
+
+ {% capture box2 %}{% include index/box2.md %}{% endcapture %} + {{ box2 | markdownify }} +
+
+
+
+ {% capture box3 %}{% include index/box3.md %}{% endcapture %} + {{ box3 | markdownify }} +
+
+ {% capture box4 %}{% include index/box4.md %}{% endcapture %} + {{ box4 | markdownify }} +
+
+
+
+ {% capture box5 %}{% include index/box5.md %}{% endcapture %} + {{ box5 | markdownify }} +
+
+ {% capture box6 %}{% include index/box6.md %}{% endcapture %} + {{ box6 | markdownify }} +
+
+
+
+ {% capture box7 %}{% include index/box7.md %}{% endcapture %} + {{ box7 | markdownify }} +
+
+ {% capture box8 %}{% include index/box8.md %}{% endcapture %} + {{ box8 | markdownify }} +
+
+ +
+
+
+ {% include footer.html %} +
+
+
+ + + diff --git a/docs/_posts/2016-08-27-4.0-beta-1.md b/docs/_posts/2016-08-27-4.0-beta-1.md new file mode 100644 index 0000000000..a1c9deb191 --- /dev/null +++ b/docs/_posts/2016-08-27-4.0-beta-1.md @@ -0,0 +1,15 @@ +--- +layout: default +title: Welcome sitespeed.io 4.0 beta +description: Finally sitespeed.io 4.0 is here! +author: Peter Hedenskog +authorimage: /img/aboutus/peter.jpg +intro: We have released the first beta version of 4.0 of sitespeed.io. Finally! +keywords: sitespeed.io, sitespeed, site, speed, webperf, performance, web, wpo +nav: blog +--- + +# Sitespeed.io 4.0 beta +Yes finally we have released the first beta of 4.0. We plan to do at least one beta before final. + +We have a have some great changes in 4.0 but let pause those for the 4.0 final post and let me go through what missing this release and what's coming in 4.0 final. diff --git a/docs/aboutus/index.md b/docs/aboutus/index.md new file mode 100644 index 0000000000..f1a3c13ae8 --- /dev/null +++ b/docs/aboutus/index.md @@ -0,0 +1,30 @@ +--- +layout: default +title: About Us +description: The team behind sitespeed.io +author: Peter Hedenskog +keywords: sitespeed.io, about, peter hedenskog, tobias lidskog, jonathan Lee +nav: aboutus +--- + +# About Us + +We are a three member team that works on sitespeed.io in our free time. New contributors and team members are very welcomed! + +## Jonathan Lee + I discovered sitespeed.io version 3 in 2015 while exploring the latest trending tools in web performance. I was intrigued by this tool and decided to learn more. Wanting to contribute back to the open source community that has giving me so much over the last decade, I reached out to Peter and Tobias to assist with the development of version 4.0. + +As a performance engineer at [CBSi](http://www.cbsinteractive.com/) I am able to offer real-world feedback to the team to make improvements that will benefit others. I love talking about web performance so feel free connect or reach out to me on [LinkedIn](https://www.linkedin.com/in/jonathanlee20) or [Twitter](https://twitter.com/beenanner). + + +## Tobias Lidskog + Having been supporter of sitespeed.io from the sidelines for some time, I joined Peter as we started working on version 3.0. I've been working professionally with the web for about 15 years, and open source tools have been an indispensable help all along. Now it's nice to be able to give something back. + +In my work at [iZettle](https://www.izettle.com/) I spend most of my time enabling the dev teams to shine. Working on sitespeed.io is a great complement, letting me get my hands dirty with range of tools and techniques; from [controlling browsers with WebDriver](http://www.browsertime.net) to [learning how to use Docker](https://github.com/sitespeedio/sitespeed.io-docker). + +## Peter Hedenskog + I created sitespeed.io late 2012. It's been a lot of work and incredibly [fun](http://www.peterhedenskog.com/blog/2015/02/building-a-new-sitespeed.io/)! I'm a web performance geek, love the web and think Open Source is the way forward. I work in the performance team at [Wikimedia](https://www.wikimedia.org/). + +In early 2015 I was awarded for building sitespeed.io by [The Swedish Internet Infrastructure Foundation](https://www.iis.se/english/about-se/) making it possible for me to work full time on the project for three months. + +I'm one of the organizers of the [Stockholm Web Performance meetup group](http://www.meetup.com/Stockholm-Web-Performance-Group/). We are 600+ members and are always looking for new speakers. If you are in Stockholm and have something to share, ping me on Twitter and see if we can make it happen. diff --git a/docs/blog/index.md b/docs/blog/index.md new file mode 100644 index 0000000000..a7ce5ccc85 --- /dev/null +++ b/docs/blog/index.md @@ -0,0 +1,24 @@ +--- +layout: default +title: The sitespeed.io blog +description: The team behind sitespeed.io +author: Peter Hedenskog +keywords: sitespeed.io, peter hedenskog, tobias lidskog +nav: blog +--- + +# Blog + +{% for post in site.posts %} + + +## [{{ post.title }}]({{site.baseurl}}{{ post.url }}) + +**{{ post.date | date: '%Y' }}-{{ post.date | date: '%m' }}-{{ post.date | date: '%d' }}** - + {{ post.intro }} + + [>> Read more]({{site.baseurl}}{{ post.url }}) + + * * * + +{% endfor %} diff --git a/docs/documentation/browsertime/documentation/index.md b/docs/documentation/browsertime/documentation/index.md new file mode 100644 index 0000000000..83b86c59eb --- /dev/null +++ b/docs/documentation/browsertime/documentation/index.md @@ -0,0 +1,17 @@ +--- +layout: default +title: Browsertine Documentation +description: +keywords: browsertime, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: +--- +[Documentation]({{site.baseurl}}/documentation/browsertime/) / + +# Browsertime - Documentation +{:.no_toc} + +* Lets place the TOC here +{:toc} diff --git a/docs/documentation/browsertime/index.md b/docs/documentation/browsertime/index.md new file mode 100644 index 0000000000..2ee77feb1e --- /dev/null +++ b/docs/documentation/browsertime/index.md @@ -0,0 +1,56 @@ +--- +layout: default +title: Browsertime +description: +keywords: tools, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: +--- +# Browsertime + +Browsertime logo + +Access the Web Performance Timeline, from your browser, in your terminal! + +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/), +[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 + * Run custom Javascript scripts in the browser and get statistics for each run. + +## A simple example + +~~~ +$ 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/ + +## I want more examples +Checkout the [examples](https://github.com/sitespeedio/browsertime/tree/master/docs/examples). + +## Browsers +Browsertime supports Firefox and Chrome on desktop. On Android we support Chrome. Yep that's it for now. + +But we want to support Opera (on Android) https://github.com/sitespeedio/browsertime/issues/150 and when Safari 10 is availible, we will add it too. And when(?!) it iOS Safari supports WebDriver we will add that too. + +## How does it work +Browsertime uses Selenium NodeJS to drive the browser. It starts the browser, load a URL, executes configurable Javacsripts 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. + +Oh and you can run your own Selenium script before (--preScript) and after (--postScript) a URL is accessed so you can login/logout or do whatever you want. + + +## The rewrite to 1.0 +The master is to a large degree a re-write of the internal implementation, the cli interface, and the node API. It's +based on 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 dropped BrowsermobProxy so you don't need Java :smile: to run anymore and each run will be 1000% faster. Also we now support HTTP/2 and pre and post selenium scripts, if you want to do things before the URL is tested. + +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. diff --git a/docs/documentation/coach/developers/index.md b/docs/documentation/coach/developers/index.md new file mode 100644 index 0000000000..bd53859b8b --- /dev/null +++ b/docs/documentation/coach/developers/index.md @@ -0,0 +1,204 @@ +--- +layout: default +title: Coach +description: +keywords: coach, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: +--- +[Documentation]({{site.baseurl}}/documentation/coach/) / Developers guide + +# The Coach - Developers guide +{:.no_toc} + +* Lets place the TOC here +{:toc} + +## Prerequisites + +You need install [Node.js](https://nodejs.org/en/), [npm](https://nodejs.org/en/), [Firefox](https://www.mozilla.org/en-US/firefox/new/) and [Chrome](https://www.google.com/chrome/browser/desktop/). + +When you got them installed you can clone the project (or rather first fork it and clone your fork). + +``` +$ git clone git@github.com:sitespeedio/coach.git +``` + +Inside your coach folder install the dependencies and run the tests to check that everything works: + +``` +$ cd coach +$ npm install +$ npm test +``` +If the test works you are ready start! + +## Advice +The coach helps you with web performance and gives you advice about things you can do better. The advice needs to follow the following structure: + +```javascript +return { + id: 'uniqueid', // a uniqie id + title: 'The title of the advice', + description: 'More information of the advice', + advice: 'Information of what the user should do to fix the problem', + score: 100, // a number between 0-100, 100 means the page don't need any advice + weight: 5, // a number between 0-10, how important is this advice in this category? 10 means super important + offending: [], // an array of assets that made the score less than perfect + tags: ['performance','html'] +}; +``` + +Does it look familiar? Yep it is almost the same structure as an YSlow rule :) + + +### DOM vs HAR advice +The coach analyze a page in two steps: First it executes Javascript in the browser to do checks that are a perfect fit for Javascript: examine the rendering path, check if images are scaled in the browser and more. + +Then the coach take the HAR file generated from the page and analyze that too. The HAR is good if you want the number of responses, response size and check cache headers. + +In the last step the coach merges the advice into one advice list and creates an overall score. + +Isn't that cool? We got one more thing that we [intend to implement](https://github.com/sitespeedio/coach/issues/13)): the combination of the two: A HAR advice that takes input from a DOM. This is cool because the coach will then have the power to know it all. + +#### DOM advice + +Each DOM advice needs to be a [IIFE](https://en.wikipedia.org/wiki/Immediately-invoked_function_expression) and return an object that holds the data. + +A simple example is the cssPrint advice that looks for a print stylesheet. + +```javascript +(function(util) { + 'use strict'; + var offending = []; + + var links = document.getElementsByTagName('link'); + for (var i = 0, len = links.length; i < len; i += 1) { + if (links[i].media === 'print') { + offending.push(util.getAbsoluteURL(links[i].href)); + } + } + + var score = offending.length * 10; + + return { + id: 'cssPrint', + title: 'Do not load print stylesheets, use @media type print instead', + description: 'Loading a specific stylesheet for printing slows down the page, even though it is not used', + advice: offending.length > 0 ? 'The page has ' + offending.length + ' print stylesheets. You should include that stylesheet using @media type print instead.':'', + score: Math.max(0, 100 - score), + weight: 1, + offending: offending, + tags: ['performance', 'css'] + }; + +})(util); +``` + + +#### HAR advice +We use [PageXray](https://github.com/sitespeedio/pagexray) to convert the HAR file into a Page object that are easier to work with. + +Each HAR advice needs to implement a processPage function. The function will be called once for each page. + +Lets look at a simple advice that checks if the total page size is too large. + +```javascript +'use strict'; +let util = require('../util'); + +module.exports = { + id: 'pageSize', + title: 'Total page size shouldn\'t be too big', + description: 'Avoid having pages that have transfer size over the wire of more than 2 MB (desktop) and 1 MB (mobile) because that is really big and will hurt performance. ', + weight: 3, + tags: ['performance', 'mobile'], + processPage: function(page, domAdvice, options) { + // in options we have the input parameters + // so we can do specific advice for devices like + let sizeLimit = options.mobile ? 1000000 : 2000000; + if (page.transferSize > sizeLimit) { + return { + score: 0, + offending: [], + advice: 'The page total transfer size is ' + util.formatBytes(page.transferSize) + ', which is more than the coach limit of ' + util.formatBytes(sizeLimit) + '. That is really big and you should check what you can do to make it smaller.' + }; + } + + // and the domAdvice is the data we got from running the DOM advice + // we can get things like what assets are loaded inside of HEAD + // knowing which Javascripts that are loaded synchronous + // if (domAdvice.coachAdvice.results.info.head.jssync.length > 0) + + return { + score: 100, + offending: [], + advice: '' + }; + } +}; +``` +What's extra cool is that a HAR advice can both act on input (specific advice for device or browser) and on the result from the DOM advice running in the browser (=you can let the HAR advice know which assets are loaded inside of head etc). + +#### The best of two worlds +As an extra feature, the HAR advice override the DOM advice if the advice has the same id. This means you can easily combine data from the two and still output one advice. + +There's no advice that use that functionality today but be sure it will soon be. + +It also means we can use information from the resource timing API v2 (where we can get response size) making the DOM advice even more powerful, but when you combine the HAR & DOM advice we can get all the values from the HAR (or some if we want that). + +## Testing HTTP/2 vs HTTP/1 +Both DOM and HAR advice have help methods that makes it easy to give different advice depending on the protocol. + +### DOM +```javascript +if (util.isHTTP2()) { + // special handling for H2 connections +} +``` + +### HAR +```javascript +if (util.isHTTP2(page)) { + // special handling for H2 connections +} +``` + + +## Test in your browser +You can and should test your advice in your browser. It's easy. Just copy/paste your advice into the browser console. If you use the [utility methods](https://github.com/sitespeedio/coach/blob/master/lib/dom/util.js) you need to copy/paste that too inside your console before you test your advice. + +## Add a test case +When you create a new advice you also need to create unit tests. We run the tests in both Firefox & Chrome. + +We create a new unique HTML page for each rule (or two if you want to test different behavior). If you only have one page, name it the same as the advice + '.html' and it will be picked up. + +A simple test run for the print CSS advice looks like this: + +```javascript +it('We should find out if we load an print CSS', function() { + return runner.run('cssPrint.js') + .then((result) => { + assert.strictEqual(result.offending.length, 1); + }); +}); +``` + +Right now all these tests run in https://github.com/sitespeedio/coach/blob/master/test/dom/performance/indexTest.js + +Each test case runs against a specific HTML page located in [test/http-server](test/http-server) Create a suitable HTML page with the structure you want to test. Create the test case in [test/dom](test/dom) or [test/har](test/har) and run it with npm test + +## Test your changes against a web page +The coach uses Browsertime as runner for browsers. When you done a change, make sure to build a new version of the combined Javascript and then test against a url. + +```bash +npm run combine +bin/index.js https://www.sitespeed.io firefox +``` + +# Add a new category +When you browse the code you will see that the coach knows more things than performance. + +We have accessibility best practice, performance, and info today. Do the coach need to know something else? Let us know and we can create that category (it's as easy as create a new folder) and we can start add new advice there. diff --git a/docs/documentation/coach/how-to/index.md b/docs/documentation/coach/how-to/index.md new file mode 100644 index 0000000000..0d3cce32f8 --- /dev/null +++ b/docs/documentation/coach/how-to/index.md @@ -0,0 +1,189 @@ +--- +layout: default +title: Coach +description: +keywords: coach, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: +--- +[Documentation]({{site.baseurl}}/documentation/coach/) / How to + +# The Coach - How to use the coach +{:.no_toc} + +* Lets place the TOC here +{:toc} + +You can use the coach in a couple of different ways. + +### Standalone + +You need Node.js 4.3.0 or later to run. And you need Firefox and/or Chrome installed. + +If you want to use Firefox (Firefox is default): + +```bash +webcoach https://www.sitespeed.io +``` + +Try it with Chrome: + +```bash +npm install webcoach -g +webcoach https://www.sitespeed.io --browser chrome +``` + +If you also want to show the offending assets/details and the description of the advice: + +```bash +webcoach https://www.sitespeed.io --details --description +``` + +By default, the coach only tells you about advice where you don't get the score 100. You can change that. If you want to see all advice, you can do that too: + +```bash +webcoach https://www.sitespeed.io --limit 101 +``` + +If you want to test as a mobile device, that's possible too, by faking the user-agent. + +```bash +webcoach https://www.sitespeed.io --mobile -b chrome +``` + + +> ... but hey, I want to see the full JSON? + +Yes, you can do that! + +```bash +webcoach https://www.sitespeed.io -f json +``` +This will get you the full JSON, the same as if you integrate the coach into your tool. + + +### sitespeed.io 4.0 + +The coach is a part of the forthcoming [sitespeed.io 4.0](https://www.sitespeed.io). It will be released this summer, hallelujah! + +### Bookmarklet + +We also produce a bookmarklet. The bookmarklet only uses advice that you can run inside the browser (it doesn't have HAR file to analyze even though maybe possible in the future with the Resource Timing API). + +The bookmarklet is really rough right now and logs the info to the browser console. Help us make a cool front-end :) + +You can generate the bookmarklet by running + +```bash +grunt bookmarklet +``` + +and then you will find it in the dist folder. + +### Include in your own tool +The coach uses Browsertime to start the browser, execute the Javascript and fetch the HAR file. You can use that functionality too inside your tool or you can use the raw scripts if you have your own browser implementation. + +#### Use built in browser support + +In the simplest version you use the default configuration (default DOM and HAR advice and using Firefox): + +```javascript +const api = require('webcoach'); +const result = api.run('https://www.sitespeed.io'); +``` + +The full API method: + +```javascript +// get the API +const api = require('webcoach'); +const result = api.run(url, domScript, harScript, options); +``` + +#### Use the scripts +Say that your tool run on Windows, you start the browsers yourself and you generate your own HAR file. Create your own wrapper to get the coach to help you. + +First you need the Javascript advice, you can get the raw script either by generating it yourself or through the API. + +Generate the script + +```bash +grunt combine +``` +and it will be in the dist folder. + +Or you just get it from the API: + +```javascript +// get the API +const api = require('webcoach'); +// get the DOM scripts, it's a promise +const domScriptPromise = api.getDomAdvice(); +``` + +Take the domScript and run it in your browser and take care of the result. + +To test the HAR you need to generate the HAR yourself and then run it against the advice. + +```javascript +const api = require('webcoach'); +// You read your HAR file from disk or however you get hold of it +const harJson = // +// if your har contains multiple pages (multiple runs etc) you can use the API +// to get the page that you want +const firstPageHar = api.pickAPage(harJson, 0); +// the result is a promise +const myHarAdviceResultPromise = api.runHarAdvice(firstPageHar, api.getHarAdvice()); + +``` + +When you got the result from both the DOM and the HAR you need to merge the result to get the full coach result: + +```javascript +// Say that you got the result from the browser in domAdviceResult +// and the HAR result in harAdviceResult +const coachResult = api.merge(domAdviceResult, harAdviceResult); +``` + +Now you have the full result (as JSON) as a coachResult. + +## What do the coach do +The coach will give you advice on how to do your page better. You will also get a score between 0-100. If you get 100 the page is great, if you get 0 you can do much better! + +## How does it all work? + +The coach tests your site in two steps: + + * Executes Javascript in your browser and check for performance, accessibility, best practice and collect general info about your page. + * Analyze the [HAR file](http://www.softwareishard.com/blog/har-12-spec/) for your page together with relevant info from the DOM process. + +You can run the different steps standalone but for the best result run them together. + +![What the coach do](https://github.com/sitespeedio/coach/blob/master/img/coach-explained.png) + +## Bonus +The coach knows more than just performance. She also knows about accessibility and web best practice. + +### Accessibility +Make sure your site is accessible and useable for every one. You can read more about making the web accessible [here](https://www.marcozehe.de/2015/12/14/the-web-accessibility-basics/). + +### Best practice +You want your page to follow best practices, right? Making sure your page is set up for search engines, have good URL structure and so on. + +### General information +The world is complex. Some things are great to know but hard for the coach to give advice about. + +The coach will then just tell you how the page is built and you can draw your own conclusions if something should be changed. + +### Timings +The coach has a clock and knows how to use it! You will get timing metrics and know if you are doing better or worse than the last run. + +# Developers guide +Checkout the [developers guide](../developers/) to get a better feeling how the coach works. + +# Browser support +The coach is automatically tested in latest Chrome and Firefox. To get best results you need Chrome or Firefox 48 (or later) to be able to know if the server is using HTTP/2. + +We hope that the coach work in other browsers but we cannot guarantee it right now. diff --git a/docs/documentation/coach/index.md b/docs/documentation/coach/index.md new file mode 100644 index 0000000000..17ffbf323f --- /dev/null +++ b/docs/documentation/coach/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: Coach +description: +keywords: tools, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: +--- +# The coach - Clear Eyes. Full Hearts. Can’t Lose! + +I'm the coach + +The coach helps you find performance problems on your web page. Think of the coach as a modern version of [YSlow](http://yslow.org/). The coach will give advice of how your page can be faster. You can run the coach standalone, include it in your own tool or get the data when you run sitespeed.io. + +* [Introduction](introduction/) +* [How to use the coach](how-to/) +* [Developers](developers/) diff --git a/docs/documentation/coach/introduction/index.md b/docs/documentation/coach/introduction/index.md new file mode 100644 index 0000000000..05cffed86e --- /dev/null +++ b/docs/documentation/coach/introduction/index.md @@ -0,0 +1,40 @@ +--- +layout: default +title: Coach +description: +keywords: coach, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: +--- +[Documentation]({{site.baseurl}}/documentation/coach/) / Introduction + +# The Coach - Introduction +{:.no_toc} + +* Lets place the TOC here +{:toc} + + +## Do my page need coaching? + +You know, it's hard to get everything right! The world is complex: HTTP/1 vs HTTP/2. Some of the previous performance best practices are now worst practices. The coach will detect that the page is accessed using HTTP/2, and adjust its advice accordingly. + + +## Why we love the coach +Ten reasons why we love the coach: + + - The coach gives you advice on how to make your page faster. The coach aims to NEVER give you bad advice. Follow the advice and you will WIN! + - HTTP/1 or HTTP/2? That's no problem, the coach adjust the advice accordingly. + - The coach uses real browsers to see your page exactly like your users do. + - Every advice has one or more unit-tests to make sure it's easy to change advice in the future. + - The coach knows about more than just performance: Accessibility and web best practice are other things that the coach can help you with. + - You can integrate the coach with your own web performance tool. It's easy: your tool only need to be able to run JavaScript in the browser and produce a HAR file. Or you can use the built-in functionality of the coach to run the browser. + - The coach is open-source. The advice is public, you can check it and change it yourself. Help us make the coach even better! + - The coach can combine knowledge from the DOM with HAR to give you super powerful advice. + - The CLI output is pretty nice. You can configure how much you want to see. Use it as fast way to check the performance of your page. + - The coach is a part of sitespeed.io 4.0 and it will be awesome! + +## Work in progress! +We know you want the coach to help you but right now YOU need to help the coach! The coach is new and need more advice. Send a PR with a new advice, so the coach gets more knowledge! Check out the [issues](https://github.com/sitespeedio/coach/issues), try the project and give us feedback! In a couple of months we will release 1.0. diff --git a/docs/documentation/index.md b/docs/documentation/index.md new file mode 100644 index 0000000000..727caaecbd --- /dev/null +++ b/docs/documentation/index.md @@ -0,0 +1,18 @@ +--- +layout: default +title: Tools +description: Here's the documentation of how to use sitespeed.io. +keywords: tools, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Documentation for the sitespeed.io. +--- +# Documentation + +At the moment we have four different tools: + + * [sitespeed.io]({{site.baseurl}}/documentation/sitespeed.io/) + * [Coach]({{site.baseurl}}/documentation/coach/) + * [Browsertime]({{site.baseurl}}/documentation/browsertime/) + * [PageXray]({{site.baseurl}}/documentation/pagexray/) diff --git a/docs/documentation/pagexray/index.md b/docs/documentation/pagexray/index.md new file mode 100644 index 0000000000..02d34f7b78 --- /dev/null +++ b/docs/documentation/pagexray/index.md @@ -0,0 +1,141 @@ +--- +layout: default +title: PageXray +description: +keywords: tools, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: +--- +# PageXray + +PageXray logo + +We love HAR file but it's hard to actually see what the page includes only looking at the file. The PageXray converts a HAR file to a JSON format that is easier to read. We use the format internally in the coach and sitespeed.io. + +## What do we collect? + + * The size and the number of requests per content type + * The size and requests per domain + * The number of requests per response code + * The base domain and the httpVersion used for the base asset (the main HTML document) + * All assets (responses) with the following data: type, url, size, expires (a normalized expires converting max-age/expires to just expires in seconds), status (response code), timeSinceLastModified (using the last modified field in the repsonse header and normalizing to seconds), httpVersion and all request and response headers. + +## Install + +```bash +npm install pagexray -g +``` + +## Run + +```bash +pagexray /path/to/my.har +``` + +Or if you want to prettify the HAR + +```bash +pagexray --pretty /path/to/my.har +``` +And if you want to get info per request/response: + +```bash +pagexray -includeAssets /path/to/my.har +``` + +If you want to use it in node, use it like this: + +```node +let pagexray = require('pagexray'); +let har = // your HAR +let pages = pagexray.convert(har); +``` +## Output +All sizes are in bytes. Expires and timeSinceLastModified are in seconds. + +```json +[ + { + "url": "https://run.sitespeed.io/", + "finalUrl": "https://run.sitespeed.io/", + "baseDomain": "run.sitespeed.io", + "documentRedirects": -1, + "redirectChain": [], + "transferSize": 102069, + "contentSize": 102069, + "headerSize": 6480, + "requests": 11, + "httpType": "h2", + "httpVersion": "HTTP/2.0", + "contentTypes": { + "html": { + "transferSize": 12311, + "contentSize": 12311, + "headerSize": 582, + "requests": 1 + }, + "javascript": { + "transferSize": 26285, + "contentSize": 26285, + "headerSize": 347, + "requests": 1 + }, + "image": { + "transferSize": 11855, + "contentSize": 11855, + "headerSize": 984, + "requests": 2 + }, + "svg": { + "transferSize": 45100, + "contentSize": 45100, + "headerSize": 3923, + "requests": 6 + }, + "favicon": { + "transferSize": 6518, + "contentSize": 6518, + "headerSize": 644, + "requests": 1 + } + }, + "assets": [], + "responseCodes": { + "200": 11 + }, + "domains": { + "run.sitespeed.io": { + "requests": 9, + "transferSize": 75749, + "contentSize": 75749, + "headerSize": 5788 + }, + "www.google-analytics.com": { + "requests": 2, + "transferSize": 26320, + "contentSize": 26320, + "headerSize": 692 + } + }, + "expireStats": { + "min": "0", + "p10": "0", + "median": "31536000", + "p90": "31536000", + "p99": "31536000", + "max": "31536000" + }, + "lastModifiedStats": { + "min": "15293097", + "p10": "18613493", + "median": "18613493", + "p90": "566681353", + "p99": "566681353", + "max": "566681353" + } + } +] + +``` diff --git a/docs/documentation/sitespeed.io/browsers/index.md b/docs/documentation/sitespeed.io/browsers/index.md new file mode 100644 index 0000000000..b1cd8125b3 --- /dev/null +++ b/docs/documentation/sitespeed.io/browsers/index.md @@ -0,0 +1,75 @@ +--- +layout: default +title: Browsers - Documentation - sitespeed.io +description: How to get browser timings using sitespeed.io for Firefox and Chrome. +keywords: browsers, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Browser timings for sitespeed.io. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Browsers + +# Browsers +{:.no_toc} + +* Lets place the TOC here +{:toc} + +You can fetch timings and execute your own Javascript. The following browsers are supported: Firefox, Chrome and Chrome on Android. + +## Firefox +You will need Firefox 48+. We use the new [Geckodriver](https://github.com/mozilla/geckodriver) and it works only version 48 or later. + +## Chrome +Chrome should work out of the box. + +## Change connectivity +You can throttle the connection when you are fetching metrics using the browser. Choose between: + +* 3g - 1600/768 300 RTT +* 3gfast - 1600/768 150 RTT +* 3gslow - 780/330 200 RTT +* 2g - 35/328 1300 RTT +* cable - 5000/1000 280 RTT +* native - your current connection + +We use [TSProxy](https://github.com/WPO-Foundation/tsproxy) by default so you need Python 2.7 to be able tho throttle the connection. + +~~~bash +$ sitespeed.io https://www.sitespeed.io -c cable +~~~ + +We plan to implement support for other connectivity engines in the future. You can try out our tc implementation by setting --connectivity.engine tc + +## Choose when to end your test +By default the browser will collect data until [window.performance.timing.loadEventEnd happens + aprox 2 seconds more](https://github.com/sitespeedio/browsertime/blob/d68261e554470f7b9df28797502f5edac3ace2e3/lib/core/seleniumRunner.js#L15). That is perfectly fine for most sites, but if you do Ajax loading and you mark them with user timings, you probably want to include them in your test. Do that by changing the script that will end the test (–waitScript). When the scripts returns true the browser will close or if the timeout time (default 60 seconds) will be reached. + +In this we wait 10 seconds until loadEventEnd happens but you can also choose to trigger it at a specific event. + +~~~bash +$ sitespeed.io https://www.sitespeed.io --browsertime.pageCompleteCheck 'return (function() {try { return (Date.now() - window.performance.timing.loadEventEnd) > 10000;} catch(e) {} return true;})()' +~~~ + +## Custom metrics + +You can collect your own metrics in the browser by supplying Javascript file(s). Each file need to return a metric/value and it will be picked up and returned in the JSON. If you return a number, statistics will automatically be generated for the value (like median/percentiles etc). + +Say we have a folder called scripts and in there we have one file called scripts.js that checks how many javascript that is loaded. The script looks like this: + +~~~bash +return document.getElementsByTagName("script").length; +~~~ + +Then to pick up the script, run like this: + +~~~bash +sitespeed.io https://www.sitespeed.io --browsertime.script scripts.js -b firefox +~~~ + +## More browser goodness +Everything you can do in Browsertime, you can also do in sitespeed.io. Add browsertime to the CLI parameter and it will be passed on to Browsertime. + +You can check what Browsertime can do [here](https://github.com/sitespeedio/browsertime/blob/master/lib/support/cli.js). + +Say for example that you wanna pass on extra Chrome arguments to Chrome. In standalone Browsertime you do that with --chrome.args. If you wanna do that in sitespeed.io you add browsertime to the param: --browsertime.chrome.args. Yes we know, it is sweat :) diff --git a/docs/documentation/sitespeed.io/configuration/index.md b/docs/documentation/sitespeed.io/configuration/index.md new file mode 100644 index 0000000000..2af56079ca --- /dev/null +++ b/docs/documentation/sitespeed.io/configuration/index.md @@ -0,0 +1,180 @@ +--- +layout: default +title: Browsers - Documentation - sitespeed.io +description: How to configure sitespeed.io +keywords: configuration, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Configuration for sitespeed.io. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Configuration + +# Configuration +{:.no_toc} + +* Lets place the TOC here +{:toc} + +# Configuration +Sitespeed.io is highly configurable, let's check it out! + +## The options +You have the following options running sitespeed.io (we will add more as we are coming to the stable 4.0 release): + +~~~help +bin/sitespeed.js [options] / + +Browser + --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.delay Delay between runs, in milliseconds [number] [default: 0] + --browsertime.connectivity.profile, -c, --connectivity The connectivity profile. Default connectivity engine is tsproxy + [choices: "3g", "3gfast", "3gslow", "2g", "cable", "native", "custom"] [default: "native"] + --browsertime.connectivity.config This option requires --connectivity.profile be set to "custom". Takes a JSON object with the keys downstreamKbps, + upstreamKbps and latency. "{\"downstreamKbps\":6000, \"upstreamKbps\": 6000, \"latency\": 200}" + --browsertime.connectivity.tsproxy.port The port used for ts proxy [default: 1080] + --browsertime.connectivity.engine The engine for connectivity. Tsproxy needs Python 2.7. TC needs tc, modprobe and ip installed to work. Running tc + inside Docker needs modprobe to run outside the container. [choices: "tc", "tsproxy"] [default: "tsproxy"] + --browsertime.pageCompleteCheck Javascript snippet is repeatedly queried to see if page has completed loading (indicated by the script returning true) + --browsertime.script, --script Add custom Javascript to run on page (that returns a number). Note that --script can be passed multiple times if you + want to collect multiple metrics. The metrics will automatically be pushed to the summary/detailed summary and each + individual page + sent to Graphite/InfluxDB. + --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 view port, the page viewport 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.preScript, --preScript Task(s) to run before you test your URL (use it for login etc). Note that --preScript can be passed multiple times. + --browsertime.postScript, --postScript Path to JS file for any postTasks that need to be executed. + +Crawler + --crawler.depth, -d How deep to crawl (1=only one page, 2=include links from first page, etc.) + --crawler.maxPages, -m The max number of pages to test. Default is no limit. + +Graphite + --graphite.host The Graphite host used to store captured metrics. + --graphite.port The Graphite port used to store captured metrics. [default: 2003] + --graphite.namespace The namespace key added to all captured metrics. [default: "sitespeed_io.default"] + --graphite.includeQueryParams Whether to include query paramaters from the URL in the Graphite keys or not [boolean] [default: false] + +Plugins + --plugins.list List all configured plugins in the log. [boolean] [default: false] + --plugins.disable Disable a plugin. Use it to disable generating html or screenshots. [array] + --plugins.load Extra plugins as an installed npm module that you want to run [array] + +Metrics + --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.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: *- coach.summary.score.* [array] + +WebPageTest + --webpagetest.host The domain of your WebPageTest instance. [default: "https://www.webpagetest.org"] + --webpagetest.key The API key for you WebPageTest instance. + --webpagetest.location The location for the test [default: "Dulles:Chrome"] + --webpagetest.connectivity The connectivity for the test. [default: "Cable"] + --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.script Path to a script file + +gpsi + --gpsi.key The key to use Google Page Speed Insight + +Slack + --slack.hookUrl WebHook url for the Slack team (check https://.slack.com/apps/manage/custom-integrations). + --slack.userName User name to use when posting status to Slack. [default: "Sitespeed.io"] + +HTML + --html.showWaterfallSummary Set to true to show waterfalls on summary HTML report [boolean] [default: false] + +Options: + --version, -V Show version number [boolean] + --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] + --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] + --outputFolder The folder name where the result will be stored. By default the name is generated using current_date/domain/filename [default: "sitespeed-result"] + --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] + --config Path to JSON config file + --help, -h Show help [boolean] + +Read the docs at https://www.sitespeed.io/documentation/ + +urlOrFile +~~~ + + +## The basics +If you installed with the global option (-g), run the command *sitespeed.io* else run the script *bin/sitespeed.js*. In the examples we will use the installed version. + +You can analyze a site either by crawling or feed sitespeed.io with the URL:s you want to analyze. + +### Analyze by URLs +You can choose + +~~~bash +$ sitespeed.io https://www.sitespeed.io +~~~ + +If you wanna test multiple URLs just feed them: + +~~~bash +$ sitespeed.io https://www.sitespeed.io https://www.sitespeed.io/documentation/ +~~~ + +You can also use a plain text file with one URL on each line. Create a file called urls.txt: + +~~~ +http://www.yoursite.com/path/ +http://www.yoursite.com/my/really/important/page/ +http://www.yoursite.com/where/we/are/ +~~~ + +And feed it: + +~~~bash +$ sitespeed.io urls.txt +~~~ + +### Analyze by crawling + +You can choose how deep to crawl (1=only one page, 2=include links from first page, etc.): + +~~~bash +$ sitespeed.io https://www.sitespeed.io -d 2 +~~~ + +### How many runs per URL? +Collecting timing metrics it's good to test the URL more than one time. You can configure how many runs doing like this (five runs): + +~~~bash +$ sitespeed.io https://www.sitespeed.io -n 5 +~~~ + +### Choose browser +Choose which browser to use: + +~~~bash +$ sitespeed.io https://www.sitespeed.io -b firefox +~~~ + +~~~bash +$ sitespeed.io https://www.sitespeed.io -b chrome +~~~ + +### Connectivity + +You can throttle the connection when you are fetching metrics using the browser. Choose between: + +* 3g - 1600/768 300 RTT +* 3gfast - 1600/768 150 RTT +* 3gslow - 780/330 200 RTT +* 2g - 35/328 1300 RTT +* cable - 5000/1000 280 RTT +* native - your current connection + +We use [TSProxy](https://github.com/WPO-Foundation/tsproxy) by default so you need Python 2.7 to be able to throttle the connection. + +~~~bash +$ sitespeed.io https://www.sitespeed.io -c cable +~~~ diff --git a/docs/documentation/sitespeed.io/continuous-integration/index.md b/docs/documentation/sitespeed.io/continuous-integration/index.md new file mode 100644 index 0000000000..fc33965689 --- /dev/null +++ b/docs/documentation/sitespeed.io/continuous-integration/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: Continuous integration - Documentation - sitespeed.io +description: Use sitespeed.io in your Continuous Integration setup with Jenkins, Grunt or Team City. +keywords: Continuous Integration, jenkins, grunt, team city, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Use sitespeed.io in your Continuous Integration setup. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Continuous Integration + +# Continuous Integration +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Coming soon! diff --git a/docs/documentation/sitespeed.io/developers/index.md b/docs/documentation/sitespeed.io/developers/index.md new file mode 100644 index 0000000000..0d48146618 --- /dev/null +++ b/docs/documentation/sitespeed.io/developers/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: Developers - Documentation - sitespeed.io +description: How to add your own post tasks, create rules and other cool stuff. +keywords: developers, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: How to add your own post tasks, create rules and other cool stuff. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Developers + +# Developers +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Coming soon! diff --git a/docs/documentation/sitespeed.io/docker/index.md b/docs/documentation/sitespeed.io/docker/index.md new file mode 100644 index 0000000000..503d7eeade --- /dev/null +++ b/docs/documentation/sitespeed.io/docker/index.md @@ -0,0 +1,68 @@ +--- +layout: default +title: Docker - Documentation - sitespeed.io +description: Use Docker to run sitespeed.io. +keywords: docker, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Use Docker to run sitespeed.io. +--- +[Documentation]({{site.baseurl}}/sitespeed.io/documentation/) / Docker + +# Docker +{:.no_toc} + +* Lets place the TOC here +{:toc} + +## Containers +With 4.0 we focus on one Docker container that you should use to run sitespeed.io. + + * [Chrome, Firefox & Xvfb](https://hub.docker.com/r/sitespeedio/sitespeed.io/) + + +## Running in Docker +The simplest way to run is like this fetching the box with Chrome and Firefox: + +~~~ bash +sudo docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io -b chrome +~~~ + +If you want to feed sitespeed with a list of URL:s in a file (here named *myurls.txt*), add the file to your current directory and do like this: + +~~~ bash +sudo docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io myurls.txt -b chrome +~~~ + +In the real world you should always specify the exact version (tag) of the Docker container to make sure you use the same version all the time (else you will download the latest tag, meaning you can have old and new versions running on the server and you don't know it). 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: + +~~~ bash +sudo docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:X.Y.Z https://www.sitespeed.io -b chrome +~~~ + + + +## Setup the volume + +If you want to feed sitespeed.io with a file with URL:s 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* + +Note: running on Mac OS X and Windows Docker only has rights to write data in your */Users* or *C:\Users* directory. Read more [here](https://docs.docker.com/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume). +{: .note .note-warning} + +## Update version (download newer sitespeed.io version) +Updating to a newer version is 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 you will run the latest version. diff --git a/docs/documentation/sitespeed.io/how-it-all-works/index.md b/docs/documentation/sitespeed.io/how-it-all-works/index.md new file mode 100644 index 0000000000..9abba65b7e --- /dev/null +++ b/docs/documentation/sitespeed.io/how-it-all-works/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: Installation - Documentation - sitespeed.io +description: How to to install sitespeed.io. Use npm or Docker. +keywords: installation, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: How to to install sitespeed.io. Use npm or Docker. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / How it all works + +# How it all works +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Coming soon! diff --git a/docs/documentation/sitespeed.io/index.md b/docs/documentation/sitespeed.io/index.md new file mode 100644 index 0000000000..b900742526 --- /dev/null +++ b/docs/documentation/sitespeed.io/index.md @@ -0,0 +1,30 @@ +--- +layout: default +title: sitespeed.io +description: +keywords: tools, documentation, web performance +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Documentation for the sitespeed.io. +--- + +# Documentation 4.x + +Browsertime logo + + * [Introduction](introduction/) + * [Installation](installation/) - install using npm, Vagrant or run our Docker containers. + * [Configuration](configuration/) - there's alot of things you can do with sitespeed.io, lets checkout how! + * [Browsers](browsers/) - collect timings using real browsers. We support Firefox, Chrome, Internet Explorer and Safari. + * [Use Cases](use-cases/) - find out best practices for testing a site, compare with other sites. +* [Performance Dashboard](performance-dasboard/) - keep track of your metrics and performance. + * [Performance Budget](performance-budget/) - make sure you are within your performance budget. + * [Plugins](plugins/) - list/disable/enable or create your own plugin. + * [Pre/post scripting](prepostscript/) - run Selenium scripts before/after you test a URL. + * [Metrics](metrics/) - configure which metrics you want to use. + * [Continuous Integration](continuous-integration/) - generate JUnit XML/TAP and use Jenkins, Team City, Grunt or the Gulp plugin. + * [Docker](docker/) - how to use our Docker containers. + * [Mobile phones](mobile-phones/) - test using your mobile phone (Android only). + * [WebPageTest](webpagetest/) - drive WebPageTest and fetch metrics and graph them. + * [Developers](developers/) - more info on how to create your own post tasks or use your own rules. diff --git a/docs/documentation/sitespeed.io/installation/index.md b/docs/documentation/sitespeed.io/installation/index.md new file mode 100644 index 0000000000..717f9a5413 --- /dev/null +++ b/docs/documentation/sitespeed.io/installation/index.md @@ -0,0 +1,47 @@ +--- +layout: default +title: Installation - Documentation - sitespeed.io +description: How to to install sitespeed.io. Use npm or Docker. +keywords: installation, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: How to to install sitespeed.io. Use npm or Docker. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Installation + +# Installation +{:.no_toc} + +* Lets place the TOC here +{:toc} + +# Download and installation + +## Install on Mac, Linux & Windows + +Prerequisites: Install [NodeJS](https://nodejs.org/en/download/) ([Linux](https://github.com/creationix/nvm)) and make sure you have [npm](https://github.com/npm/npm) installed. + +~~~ bash +$ npm install sitespeed.io@4.0.0-beta.1 -g +~~~ + +Run + +~~~ bash +sitespeed.io --help +~~~ + +on Windows you should use the Docker image. + + +## Docker + +We have [Docker images](https://hub.docker.com/u/sitespeedio/) with sitespeed.io, Chrome, Firefox and Xvfb. They are super easy to use (Xvfb is started automatically when you start the container). Here's how to use the container with both Firefox & Chrome (install [Docker](https://docs.docker.com/engine/installation/) first. + +~~~ bash +$ docker pull sitespeedio/sitespeed.io:4.0-beta +$ docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:4.0-beta https://www.sitespeed.io -b firefox +~~~ + +That will output the data from the run in the current directory. You can read more about running the containers [here]({{site.baseurl}}/documentation/docker/). diff --git a/docs/documentation/sitespeed.io/introduction/index.md b/docs/documentation/sitespeed.io/introduction/index.md new file mode 100644 index 0000000000..77ad967c9c --- /dev/null +++ b/docs/documentation/sitespeed.io/introduction/index.md @@ -0,0 +1,21 @@ +--- +layout: default +title: Introduction - Documentation - sitespeed.io +description: Introduction for sitespeed.io. +keywords: introduction, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Introduction for sitespeed.io. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Introduction + +# Introduction +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Sitespeed.io is an Open Source tool that helps you measuring the performance of your web site. It tests your site against web performance best practice rules (using the [Coach]({{site.baseurl}}/documentation/coach/)), collect timing metrics from Chrome/Firefox (using [Browsertime]({{site.baseurl}}/documentation/browsertime/)). It generates a HTML report and you can choose to send the metrics to Graphite. + +You can also drive WebPageTest and collect data from Google Page Speed Insights. diff --git a/docs/documentation/sitespeed.io/metrics/index.md b/docs/documentation/sitespeed.io/metrics/index.md new file mode 100644 index 0000000000..2378bd40ea --- /dev/null +++ b/docs/documentation/sitespeed.io/metrics/index.md @@ -0,0 +1,113 @@ +--- +layout: default +title: Configuring metrics to use +description: +keywords: configure, metrics, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Configuring metrics to use +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Metrics + +# Metrics +{:.no_toc} + +* Lets place the TOC here +{:toc} + +# Collected metrics +Sitepeed.io collects a lot of metrics and they are filtered before they are sent to Graphite. You can remove filters and/or add your own filters. We have tried to setup sensible defaults, if you have suggestions to change them create an [issue at Github](https://github.com/sitespeedio/sitespeed.io/issues/new). + +## Summary vs pageSummary +We group the metrics in two different groups: pageSummary are the metrics for one specific page. For example if we test that page 10 times, you will have the min/median/max here for values that change like different timing metrics. + +The summary holds information per group, or specific per domain. If you test ten different pages on a site (same domain), the summary of those metrics will end up here. + +## List configured metrics +You can list the metrics that are configured by **\-\-metrics.filterList**. The list is dependent on which plugin that you are using, so you need to do an actual run to generate the list. The list is stored in the data folder in a file named **configuredMetrics.txt**. + +~~~ bash +$ sitespeed.io https://www.sitespeed.io --metrics.filterList +~~~ + +The file will look something like this: + +~~~ +browsertime.pageSummary.statistics.timings.timings +browsertime.pageSummary.statistics.timings.rumSpeedIndex +browsertime.pageSummary.statistics.timings.fullyLoaded +browsertime.pageSummary.statistics.timings.firstPaint +browsertime.pageSummary.statistics.timings.userTimings +browsertime.pageSummary.statistics.visualMetrics.SpeedIndex +browsertime.pageSummary.statistics.visualMetrics.FirstVisualChange +browsertime.pageSummary.statistics.visualMetrics.LastVisualChange +browsertime.pageSummary.statistics.custom.* +... +~~~ + +## List metrics +You can also list all possible metrics that you can send. Do that by **\-\-metrics.list**. It will generate a text file named **metrics.txt** in the data folder. + +~~~ bash +$ sitespeed.io https://www.sitespeed.io --metrics.list +~~~ + + +## Configure/filter metrics +You add/change/remove filters with **\-\-metrics.filter**. + +### Add a metric +If you want to add metrics, start by looking at the generated metrics file, so you can see what you can send. + +Say you want to send all performance advice to Graphite for a page. Checking the file you can see them something like this: + +~~~ +... +coach.pageSummary.advice.performance.adviceList.avoidScalingImages.score +coach.pageSummary.advice.performance.adviceList.avoidScalingImages.weight +coach.pageSummary.advice.performance.adviceList.cssPrint.score +coach.pageSummary.advice.performance.adviceList.cssPrint.weight +coach.pageSummary.advice.performance.adviceList.fastRender.score +coach.pageSummary.advice.performance.adviceList.fastRender.weight +coach.pageSummary.advice.performance.adviceList.inlineCss.score +coach.pageSummary.advice.performance.adviceList.inlineCss.weight +coach.pageSummary.advice.performance.adviceList.jquery.score +coach.pageSummary.advice.performance.adviceList.jquery.weight +coach.pageSummary.advice.performance.adviceList.spof.score +coach.pageSummary.advice.performance.adviceList.spof.weight +coach.pageSummary.advice.performance.adviceList.thirdPartyAsyncJs.score +coach.pageSummary.advice.performance.adviceList.thirdPartyAsyncJs.weight +... +~~~ + +The score is .. yes the score and the weight is how important it is. You probably only need the score, so setting a filter like this **coach.pageSummary.advice.performance.adviceList.\*.score** will send them all (setting a wildcard for the name). + +~~~ bash +$ sitespeed.io https://www.sitespeed.io --metrics.filter coach.pageSummary.advice.performance.adviceList.*.score -n 1 +~~~ + +The best way to test and verify on your local, is to checkout the sitespeed.io project and then start a TCP server that logs everything: + +~~~ bash +$ tools/tcp-server.js +$ Server listening on :::52860 +~~~ + +It will output the port, so use it when you run sitespeed.io: + +~~~ bash +$ sitespeed.io --metrics.list https://www.sitespeed.io -n 1 --metrics.filter coach.pageSummary.advice.performance.adviceList.*.score --graphite.host 127.0.0.1 --graphite.port 52860 +~~~ + +It will log all metrics you will send to Graphite. + +### Remove metrics +We don't have support to remove single metrics, but you can +remove all configured metrics with the parameter value *\*-* + +~~~ bash +$ sitespeed.io --metrics.list https://www.sitespeed.io -n 1 --metrics.filter *- coach.pageSummary.advice.performance.adviceList.*.score --graphite.host 127.0.0.1 --graphite.port 52860 +~~~ + +will send only the **coach.pageSummary.advice.performance.adviceList.\*.score** metrics. diff --git a/docs/documentation/sitespeed.io/mobile-phones/index.md b/docs/documentation/sitespeed.io/mobile-phones/index.md new file mode 100644 index 0000000000..56c49f678e --- /dev/null +++ b/docs/documentation/sitespeed.io/mobile-phones/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: Test your page using a mobile phone +description: +keywords: plugin, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Test your page using a mobile phone +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Mobile phones + +# Use Cases +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Coming soon! diff --git a/docs/documentation/sitespeed.io/performance-budget/index.md b/docs/documentation/sitespeed.io/performance-budget/index.md new file mode 100644 index 0000000000..fab33b119d --- /dev/null +++ b/docs/documentation/sitespeed.io/performance-budget/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: Performance Budget - Documentation - sitespeed.io +description: Performance budget with sitespeed.io. +keywords: performance, budget, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Performance budget with sitespeed.io. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Performance Budget + +# Performance Budget +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Coming soon! diff --git a/docs/documentation/sitespeed.io/performance-dasboard/index.md b/docs/documentation/sitespeed.io/performance-dasboard/index.md new file mode 100644 index 0000000000..4bd14d9c7c --- /dev/null +++ b/docs/documentation/sitespeed.io/performance-dasboard/index.md @@ -0,0 +1,20 @@ +--- +layout: default +title: Dashboard - Documentation - sitespeed.io +description: Web performance dashboard using sitespeed.io. +keywords: dashboard, docker, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Web performance dashboard using sitespeed.io. +--- + +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Performance Dashboard + +# Performance Dashboard +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Coming soon! diff --git a/docs/documentation/sitespeed.io/plugins/index.md b/docs/documentation/sitespeed.io/plugins/index.md new file mode 100644 index 0000000000..f4eb2d44fc --- /dev/null +++ b/docs/documentation/sitespeed.io/plugins/index.md @@ -0,0 +1,65 @@ +--- +layout: default +title: Create your own plugin for sitespeed.io +description: +keywords: plugin, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Create your own plugin for sitespeed.io +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Plugins + +# Plugins +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Sitespeed.io uses a plugin architecture where you can remove/add your own plugins that can run additional tests on the URLs or do what you want with the result (store to a database or ...). + + +## List configured plugins +You can list the plugins that will be used when you do a run: + +~~~ bash +$ sitespeed.io --plugins.list https://en.wikipedia.org/wiki/Barack_Obama +~~~ + +And you will get a log entry looking something like this: + +~~~ +... +The following plugins is enabled: assets,browsertime,coach,domains,html,screenshot +... +~~~ + +These are the default plugins. If you want to disable some of them then ... + +## Disable a plugin +You can disable default plugins if you want. Maybe you don't need to output HTML and only send the data to Graphite or you don't need the screenshots. + +~~~ bash +$ sitespeed.io https://www.sitespeed.io --plugins.disable html +~~~ + +If you wanna disable multiple plugins: + +~~~ bash +$ sitespeed.io https://www.sitespeed.io --plugins.disable html screenshot +~~~ + +And if you wanna verify that it worked, add the plugins.list: + +~~~ bash +$ sitespeed.io https://www.sitespeed.io --plugins.disable html screenshot --plugins.list +~~~ + +## Add a plugin +You can also add a plugin. Plugins you create yourself or plugins that isn't enabled by default. The analysisStorer plugin stores the original JSON data from analyzers (from Browsertime, Coach data, WebPageTest etc). + +~~~ bash +$ sitespeed.io https://www.sitespeed.io --plugins.load analysisStorer +~~~ + +# Create your own plugin diff --git a/docs/documentation/sitespeed.io/prepostscript/index.md b/docs/documentation/sitespeed.io/prepostscript/index.md new file mode 100644 index 0000000000..a2fd16dfe4 --- /dev/null +++ b/docs/documentation/sitespeed.io/prepostscript/index.md @@ -0,0 +1,68 @@ +--- +layout: default +title: Pre/post scripts (log in the user) +description: +keywords: selenium, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Pre/post scripts (log in the user) +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Pre/post scripts + +# Pre/post scripts +{:.no_toc} + +* Lets place the TOC here +{:toc} + +# Selenium +Before sitespeed.io access and test a URL you can run your own Selenium script if you want to access a URL and pre-load the cache or if you want to login the user and then measure a URL. + +We use the NodeJs version of Selenium, you can find the [API documentation here](http://seleniumhq.github.io/selenium/docs/api/javascript/index.html). + +## Login example +Create a script where you login the user. This is an example to login the user at Wikipedia. Name the file login.js. + +~~~ bash +module.exports = { + run(context) { + return context.runWithDriver((driver) => { + // Go to Wikipedias login URL + return driver.get('https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page') + .then(() => { + // You need to find the form, the login input fiels and the + // password field. Just add you name and password and submit the form + // For more docs, checkout the NodeJS Selenium version + // http://seleniumhq.github.io/selenium/docs/api/javascript/index.html + + // we fetch the selenium webdriver from context + var webdriver = context.webdriver; + // before you start, make your username and password + var userName = 'YOUR_USERNAME_HERE'; + var password = 'YOUR_PASSWORD_HERE'; + var loginForm = driver.findElement(webdriver.By.tagName('form')); + var loginInput = driver.findElement(webdriver.By.id('wpName1')); + loginInput.sendKeys(userName); + var passwordInput = driver.findElement(webdriver.By.id('wpPassword1')); + passwordInput.sendKeys(password); + loginForm.submit(); + }); + }) + } +}; +~~~ + +Then run like (change your username & password first): + +~~~ bash +$ sitespeed.io --preScript login.js https://en.wikipedia.org/wiki/Barack_Obama +~~~ + +Checkout the magic row: + +~~~ +var webdriver = context.webdriver; +~~~ + +From the context object you get hold of the Selenium [Webdriver object](http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index.html). diff --git a/docs/documentation/sitespeed.io/upgrade/index.md b/docs/documentation/sitespeed.io/upgrade/index.md new file mode 100644 index 0000000000..5458629795 --- /dev/null +++ b/docs/documentation/sitespeed.io/upgrade/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: Upgrading from 3.x -> 4 sitespeed.io +description: +keywords: upgrading documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Use Cases for running sitespeed.io. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Upgrade + +# Upgrade +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Coming soon! diff --git a/docs/documentation/sitespeed.io/use-cases/index.md b/docs/documentation/sitespeed.io/use-cases/index.md new file mode 100644 index 0000000000..20ad810a45 --- /dev/null +++ b/docs/documentation/sitespeed.io/use-cases/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: Use Cases - Documentation - sitespeed.io +description: Use Cases for running sitespeed.io. +keywords: use case, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Use Cases for running sitespeed.io. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Use Cases + +# Use Cases +{:.no_toc} + +* Lets place the TOC here +{:toc} + +Coming soon! diff --git a/docs/documentation/sitespeed.io/webpagetest/index.md b/docs/documentation/sitespeed.io/webpagetest/index.md new file mode 100644 index 0000000000..d234eb8111 --- /dev/null +++ b/docs/documentation/sitespeed.io/webpagetest/index.md @@ -0,0 +1,106 @@ +--- +layout: default +title: WebPageTest - Documentation - sitespeed.io +description: Drive WebPageTest using sitespeed.io and include the metrics in your sitespeed.io report. +keywords: webpagetest, wpt, documentation, web performance, sitespeed.io +author: Peter Hedenskog +nav: documentation +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Drive WebPageTest using sitespeed.io and include the metrics in your sitespeed.io report. +--- +[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / WebPageTest + +# WebPageTest +{:.no_toc} + +* Lets place the TOC here +{:toc} + +## Using WebPageTest +Yep we all still love [WebPageTest](https://www.webpagetest.org/) (WPT), so we made it possible to drive an instance of and collect the data from it. + +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 there own 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 the same thing as with the API standalone. + +By default we the following configuration options: + +~~~ bash +--webpagetest.host The domain of your WebPageTest instance. +--webpagetest.key The API key for you WebPageTest instance. +--webpagetest.location The location for the test +--webpagetest.connectivity The connectivity for the test. +--webpagetest.runs The number of runs per URL. +--webpagetest.custom Execute arbitrary Javascript at the end of a test to collect custom metrics. +--webpagetest.script Path to a script file +~~~ + +and 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. Say that you want to change the user agent of your test. In the API you do that with --useragent so you can pass the same by adding --webpagetest.useragent in the cli. + +The default configuration for WebPageTest looks like this: + +~~~ bash +{ + pollResults: 10, + timeout: 600, + includeRepeatView: false, + private: true, + aftRenderingTime: true, + location: 'Dulles:Chrome', + connectivity: 'Cable', + video: true +} +~~~ + +### WebPageTest scripting + +WebPageTest has scripting capability where you can automate a multi-step test (=login the user and do stuff). That is supported by sitespeed.io by supplying the script. Do like this. Create your script file (checkout [WebPageTest documentation](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/scripting)). It can look something like this (wptScript.txt): + +~~~ bash +logData 0 + +// put any urls you want to navigate +navigate www.aol.com +navigate news.aol.com + +logData 1 + +// this step will get recorded +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): + +~~~ bash +sitespeed.io --webpagetest.script wptScript.txt --webpagetest.host my.wpt.host.com http://example.org +~~~ + +### Custom metrics + +Hey we love custom metrics and you can fetch them using WPT. Checkout the [metrics docs](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/custom-metrics) for WPT and then create a file containing your metrics: + +~~~ bash +[iframe-count] +return document.getElementsByTagName("iframe").length; + +[script-tag-count] +return document.getElementsByTagName("script").length; + +[meta-viewport] +var viewport = undefined; +var metaTags=document.getElementsByTagName("meta"); +for (var i = 0; i < metaTags.length; i++) { + if (metaTags[i].getAttribute("name") == "viewport") { + viewport = metaTags[i].getAttribute("content"); + break; + } +} +return viewport; +~~~ + +Then run sitespeed.io like this: + +~~~ bash +sitespeed.io --webpagetest.custom myScriptFile.txt --webpagetest.host my.wpt.host.com https://www.sitespeed.ip +~~~ diff --git a/docs/example/index.md b/docs/example/index.md new file mode 100644 index 0000000000..732d93ab6e --- /dev/null +++ b/docs/example/index.md @@ -0,0 +1,18 @@ +--- +layout: default +title: Example of a sitespeed.io run. +description: Here is examples of what the result looks like, when you run sitesspeed.io. +author: Peter Hedenskog +keywords: sitespeed.io, examples, results, wpo, web performance optimization +nav: examples +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +--- + +# Examples sitespeed.io + +Analyzing two pages using Chrome looks like this: + +~~~ bash +sitespeed.io https://en.wikipedia.org/wiki/Main_Page https://en.wikipedia.org/wiki/Barack_Obama -c cable -b chrome +~~~ +Gives the following [report](http://examples.sitespeed.io/4.0/2016-08-27-15-53-11). Checkout our [example dashboard](https://dashboard.sitespeed.io) to see what it looks like to use sitespeed.io to continuously measure performance. diff --git a/docs/faq/index.md b/docs/faq/index.md new file mode 100644 index 0000000000..9b29196baf --- /dev/null +++ b/docs/faq/index.md @@ -0,0 +1,17 @@ +--- +layout: default +title: Frequently asked questions for sitespeed.io +description: Questions and answers for sitespeed.io. +author: Peter Hedenskog +keywords: sitespeed.io, faq, questions, frequently, asked +nav: faq + +--- + +# FAQ +{:.no_toc} + +If you don't find the answer here or in the [documentation]({{site.baseurl}}/documentation/), please ping me on [Twitter](https://twitter.com/SiteSpeedio) or add an issue on [Github](https://github.com/sitespeedio/sitespeed.io/issues?state=open). + +* Lets place the TOC here +{:toc} diff --git a/docs/google0c83e3facf54325f.html b/docs/google0c83e3facf54325f.html new file mode 100644 index 0000000000..4f4cca765b --- /dev/null +++ b/docs/google0c83e3facf54325f.html @@ -0,0 +1 @@ +google-site-verification: google0c83e3facf54325f.html \ No newline at end of file diff --git a/docs/img/404.png b/docs/img/404.png new file mode 100644 index 0000000000..692603c202 Binary files /dev/null and b/docs/img/404.png differ diff --git a/docs/img/404b.png b/docs/img/404b.png new file mode 100644 index 0000000000..e5bb06e638 Binary files /dev/null and b/docs/img/404b.png differ diff --git a/docs/img/404c.png b/docs/img/404c.png new file mode 100644 index 0000000000..54e57811da Binary files /dev/null and b/docs/img/404c.png differ diff --git a/docs/img/GitHub-Mark-32px.png b/docs/img/GitHub-Mark-32px.png new file mode 100644 index 0000000000..741cc27e95 Binary files /dev/null and b/docs/img/GitHub-Mark-32px.png differ diff --git a/docs/img/GitHub-Mark-64px.png b/docs/img/GitHub-Mark-64px.png new file mode 100644 index 0000000000..b1125d24ef Binary files /dev/null and b/docs/img/GitHub-Mark-64px.png differ diff --git a/docs/img/aboutus/jonathan.jpg b/docs/img/aboutus/jonathan.jpg new file mode 100644 index 0000000000..10cace7cfa Binary files /dev/null and b/docs/img/aboutus/jonathan.jpg differ diff --git a/docs/img/aboutus/peter.jpg b/docs/img/aboutus/peter.jpg new file mode 100644 index 0000000000..5a4a1ec722 Binary files /dev/null and b/docs/img/aboutus/peter.jpg differ diff --git a/docs/img/aboutus/tobias.jpg b/docs/img/aboutus/tobias.jpg new file mode 100644 index 0000000000..ffc56fee16 Binary files /dev/null and b/docs/img/aboutus/tobias.jpg differ diff --git a/docs/img/black-logo-120.png b/docs/img/black-logo-120.png new file mode 100644 index 0000000000..219803d654 Binary files /dev/null and b/docs/img/black-logo-120.png differ diff --git a/docs/img/dashboard.jpg b/docs/img/dashboard.jpg new file mode 100644 index 0000000000..40d3e1164c Binary files /dev/null and b/docs/img/dashboard.jpg differ diff --git a/docs/img/dashboard.png b/docs/img/dashboard.png new file mode 100644 index 0000000000..3df3c98de6 Binary files /dev/null and b/docs/img/dashboard.png differ diff --git a/docs/img/fastly.png b/docs/img/fastly.png new file mode 100644 index 0000000000..53b4ced9a1 Binary files /dev/null and b/docs/img/fastly.png differ diff --git a/docs/img/fastly2.png b/docs/img/fastly2.png new file mode 100644 index 0000000000..2fb1bb03ab Binary files /dev/null and b/docs/img/fastly2.png differ diff --git a/docs/img/ico/sitespeed.io-114.png b/docs/img/ico/sitespeed.io-114.png new file mode 100644 index 0000000000..7faf6c3eae Binary files /dev/null and b/docs/img/ico/sitespeed.io-114.png differ diff --git a/docs/img/ico/sitespeed.io-144.png b/docs/img/ico/sitespeed.io-144.png new file mode 100644 index 0000000000..f0728d046b Binary files /dev/null and b/docs/img/ico/sitespeed.io-144.png differ diff --git a/docs/img/ico/sitespeed.io-72.png b/docs/img/ico/sitespeed.io-72.png new file mode 100644 index 0000000000..be4ce63ad8 Binary files /dev/null and b/docs/img/ico/sitespeed.io-72.png differ diff --git a/docs/img/ico/sitespeed.io.ico b/docs/img/ico/sitespeed.io.ico new file mode 100644 index 0000000000..0f528413bb Binary files /dev/null and b/docs/img/ico/sitespeed.io.ico differ diff --git a/docs/img/images-boxes.png b/docs/img/images-boxes.png new file mode 100644 index 0000000000..5e54c25e35 Binary files /dev/null and b/docs/img/images-boxes.png differ diff --git a/docs/img/logo-christmas.png b/docs/img/logo-christmas.png new file mode 100644 index 0000000000..18ed9b1b3b Binary files /dev/null and b/docs/img/logo-christmas.png differ diff --git a/docs/img/logos/browsertime.png b/docs/img/logos/browsertime.png new file mode 100644 index 0000000000..1a17dc6d1e Binary files /dev/null and b/docs/img/logos/browsertime.png differ diff --git a/docs/img/logos/coach.png b/docs/img/logos/coach.png new file mode 100644 index 0000000000..b329c19a11 Binary files /dev/null and b/docs/img/logos/coach.png differ diff --git a/docs/img/logos/pagexray.png b/docs/img/logos/pagexray.png new file mode 100644 index 0000000000..6d2d1fd8ae Binary files /dev/null and b/docs/img/logos/pagexray.png differ diff --git a/docs/img/logos/sitespeed.io.png b/docs/img/logos/sitespeed.io.png new file mode 100644 index 0000000000..b229331325 Binary files /dev/null and b/docs/img/logos/sitespeed.io.png differ diff --git a/docs/img/multiple-sites-2.0.jpg b/docs/img/multiple-sites-2.0.jpg new file mode 100644 index 0000000000..ccec825811 Binary files /dev/null and b/docs/img/multiple-sites-2.0.jpg differ diff --git a/docs/img/page-1.6.jpg b/docs/img/page-1.6.jpg new file mode 100644 index 0000000000..5cc8d9b96c Binary files /dev/null and b/docs/img/page-1.6.jpg differ diff --git a/docs/img/page-1.7-b.jpg b/docs/img/page-1.7-b.jpg new file mode 100644 index 0000000000..8e258b9cd3 Binary files /dev/null and b/docs/img/page-1.7-b.jpg differ diff --git a/docs/img/page-2.0.jpg b/docs/img/page-2.0.jpg new file mode 100644 index 0000000000..a703b92f0a Binary files /dev/null and b/docs/img/page-2.0.jpg differ diff --git a/docs/img/pages-1.6.jpg b/docs/img/pages-1.6.jpg new file mode 100644 index 0000000000..e8ae0aa9e6 Binary files /dev/null and b/docs/img/pages-1.6.jpg differ diff --git a/docs/img/pages-1.7.jpg b/docs/img/pages-1.7.jpg new file mode 100644 index 0000000000..a398e51c9c Binary files /dev/null and b/docs/img/pages-1.7.jpg differ diff --git a/docs/img/pages-1.8.jpg b/docs/img/pages-1.8.jpg new file mode 100644 index 0000000000..8ab9bbdb02 Binary files /dev/null and b/docs/img/pages-1.8.jpg differ diff --git a/docs/img/pages-2.0.jpg b/docs/img/pages-2.0.jpg new file mode 100644 index 0000000000..9b5cfe836d Binary files /dev/null and b/docs/img/pages-2.0.jpg differ diff --git a/docs/img/pages.jpg b/docs/img/pages.jpg new file mode 100644 index 0000000000..de0ed0949b Binary files /dev/null and b/docs/img/pages.jpg differ diff --git a/docs/img/perfbudget.png b/docs/img/perfbudget.png new file mode 100644 index 0000000000..6161c7e684 Binary files /dev/null and b/docs/img/perfbudget.png differ diff --git a/docs/img/pippi.png b/docs/img/pippi.png new file mode 100644 index 0000000000..2113f3ed09 Binary files /dev/null and b/docs/img/pippi.png differ diff --git a/docs/img/screenshots-2.0.jpg b/docs/img/screenshots-2.0.jpg new file mode 100644 index 0000000000..f8d373ba82 Binary files /dev/null and b/docs/img/screenshots-2.0.jpg differ diff --git a/docs/img/sitespeed-400x400.jpg b/docs/img/sitespeed-400x400.jpg new file mode 100644 index 0000000000..0b2b22f0d6 Binary files /dev/null and b/docs/img/sitespeed-400x400.jpg differ diff --git a/docs/img/sitespeed-boss-page.png b/docs/img/sitespeed-boss-page.png new file mode 100644 index 0000000000..c2e43e5d91 Binary files /dev/null and b/docs/img/sitespeed-boss-page.png differ diff --git a/docs/img/sitespeed-logo-2.png b/docs/img/sitespeed-logo-2.png new file mode 100644 index 0000000000..8e70c7fd5d Binary files /dev/null and b/docs/img/sitespeed-logo-2.png differ diff --git a/docs/img/sitespeed-logo-2c.png b/docs/img/sitespeed-logo-2c.png new file mode 100644 index 0000000000..b67f352559 Binary files /dev/null and b/docs/img/sitespeed-logo-2c.png differ diff --git a/docs/img/sitespeed-summary-twitter.gif b/docs/img/sitespeed-summary-twitter.gif new file mode 100644 index 0000000000..57f03abc38 Binary files /dev/null and b/docs/img/sitespeed-summary-twitter.gif differ diff --git a/docs/img/sitespeed-twitter.gif b/docs/img/sitespeed-twitter.gif new file mode 100644 index 0000000000..91561a3651 Binary files /dev/null and b/docs/img/sitespeed-twitter.gif differ diff --git a/docs/img/sitespeed-twitter2.gif b/docs/img/sitespeed-twitter2.gif new file mode 100644 index 0000000000..91561a3651 Binary files /dev/null and b/docs/img/sitespeed-twitter2.gif differ diff --git a/docs/img/sitespeed.io-1.6-workflow.png b/docs/img/sitespeed.io-1.6-workflow.png new file mode 100644 index 0000000000..160db7e996 Binary files /dev/null and b/docs/img/sitespeed.io-1.6-workflow.png differ diff --git a/docs/img/sitespeed.io-400x400.png b/docs/img/sitespeed.io-400x400.png new file mode 100644 index 0000000000..9f92a34168 Binary files /dev/null and b/docs/img/sitespeed.io-400x400.png differ diff --git a/docs/img/sitespeed.io-logo-large.png b/docs/img/sitespeed.io-logo-large.png new file mode 100644 index 0000000000..b068ab463b Binary files /dev/null and b/docs/img/sitespeed.io-logo-large.png differ diff --git a/docs/img/sitespeed.io-logo-large2.png b/docs/img/sitespeed.io-logo-large2.png new file mode 100644 index 0000000000..54aeefddfc Binary files /dev/null and b/docs/img/sitespeed.io-logo-large2.png differ diff --git a/docs/img/sitespeed3.x.png b/docs/img/sitespeed3.x.png new file mode 100644 index 0000000000..b9b5809e4e Binary files /dev/null and b/docs/img/sitespeed3.x.png differ diff --git a/docs/img/star2.png b/docs/img/star2.png new file mode 100644 index 0000000000..8588c421d6 Binary files /dev/null and b/docs/img/star2.png differ diff --git a/docs/img/star3.png b/docs/img/star3.png new file mode 100644 index 0000000000..fedc511947 Binary files /dev/null and b/docs/img/star3.png differ diff --git a/docs/img/summary-1.6.jpg b/docs/img/summary-1.6.jpg new file mode 100644 index 0000000000..57a275a90b Binary files /dev/null and b/docs/img/summary-1.6.jpg differ diff --git a/docs/img/summary-1.7.jpg b/docs/img/summary-1.7.jpg new file mode 100644 index 0000000000..e6195ea018 Binary files /dev/null and b/docs/img/summary-1.7.jpg differ diff --git a/docs/img/summary-1.8.jpg b/docs/img/summary-1.8.jpg new file mode 100644 index 0000000000..c31d839d53 Binary files /dev/null and b/docs/img/summary-1.8.jpg differ diff --git a/docs/img/summary-2.0.jpg b/docs/img/summary-2.0.jpg new file mode 100644 index 0000000000..ab2ee58d61 Binary files /dev/null and b/docs/img/summary-2.0.jpg differ diff --git a/docs/img/summary-details-1.8.png b/docs/img/summary-details-1.8.png new file mode 100644 index 0000000000..35bd426225 Binary files /dev/null and b/docs/img/summary-details-1.8.png differ diff --git a/docs/img/summary-details-2.0.png b/docs/img/summary-details-2.0.png new file mode 100644 index 0000000000..49d26a6e00 Binary files /dev/null and b/docs/img/summary-details-2.0.png differ diff --git a/docs/img/twitter.png b/docs/img/twitter.png new file mode 100644 index 0000000000..ef73e4223e Binary files /dev/null and b/docs/img/twitter.png differ diff --git a/docs/img/twitter64.png b/docs/img/twitter64.png new file mode 100644 index 0000000000..1a77219fe6 Binary files /dev/null and b/docs/img/twitter64.png differ diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000000..967bb045c6 --- /dev/null +++ b/docs/index.md @@ -0,0 +1,25 @@ +--- +layout: startpage +title: Sitespeed.io - Analyze your website speed and performance +description: Sitespeed.io is an open source tool that helps you analyze and optimize your website speed and performance, based on performance best practices. Run it locally or use it in your continuous integration. Download or fork it on Github! +author: Peter Hedenskog +keywords: sitespeed.io, wpo, webperf, perfmatters, fast, site, speed, web performance optimization, analyze, best practices, continous integration +nav: start +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +--- +Sitespeed.io logo + +## Analyze your website speed and performance + +Sitespeed.io is an open source tool ([Apache License Version 2.0](https://github.com/sitespeedio/sitespeed.io/blob/master/LICENSE)) that helps you analyze your website **speed** and **performance** based on **performance best practices** and **timing metrics**. It collects data from multiple pages on your website, analyze them using the [rules](/documentation/rules-and-best-practices/) and output the result as HTML or send the metrics to [Graphite](/documentation/graphs/). + +You can analyze one site, analyze and compare multiple sites or let your continuous integration server break your build when your performance budget is exceeded. + +Install using [npm](https://www.npmjs.org/) ([need help?](/documentation/installation/)): + +~~~ bash +$ npm install -g sitespeed.io +$ sitespeed.io -h +~~~ + +You can clone or fork the project at [![Github]({{site.baseurl}}/img/GitHub-Mark-64px.png){: .middle}](https://github.com/sitespeedio/sitespeed.io/issues) and if you like sitespeed.io, please give us a [![Give us a star]({{site.baseurl}}/img/star3.png){: .middle}](https://github.com/sitespeedio/sitespeed.io/stargazers)! diff --git a/docs/logo/index.md b/docs/logo/index.md new file mode 100644 index 0000000000..42b0d6e552 --- /dev/null +++ b/docs/logo/index.md @@ -0,0 +1,19 @@ +--- +layout: default +title: The sitespeed.io logo +description: Download the sitespeed.io to use on the web and for print. +author: Peter Hedenskog +keywords: sitespeed.io, logo +nav: logo +--- + + +# The Logo + +Do you you want use the sitespeed.io logo in your blog post or in a report? Click on the image (or choose *Save link as*) and the zip will be saved to your disk. There's a transparent sitespeed.io logo to be used for web and one for print in the zip file. + +The logo was created by Mochamad Arief, you can find his stuff at [http://www.mochawalk.com/](http://www.mochawalk.com/). + +Checkout all our logos [https://github.com/sitespeedio/logo](https://github.com/sitespeedio/logo). + +[![Sitespeed.io logos](sitespeed.io-logo-web.png){: .img-big}](sitespeed.io-logo.zip) diff --git a/docs/logo/sitespeed.io-logo-web.png b/docs/logo/sitespeed.io-logo-web.png new file mode 100644 index 0000000000..cf0e3edc2f Binary files /dev/null and b/docs/logo/sitespeed.io-logo-web.png differ diff --git a/docs/logo/sitespeed.io-logo.png b/docs/logo/sitespeed.io-logo.png new file mode 100644 index 0000000000..813a8cb596 Binary files /dev/null and b/docs/logo/sitespeed.io-logo.png differ diff --git a/docs/logo/sitespeed.io-logo.zip b/docs/logo/sitespeed.io-logo.zip new file mode 100644 index 0000000000..4368e4bf10 Binary files /dev/null and b/docs/logo/sitespeed.io-logo.zip differ diff --git a/docs/release-notes/1.3/index.html b/docs/release-notes/1.3/index.html new file mode 100644 index 0000000000..18ec061af6 --- /dev/null +++ b/docs/release-notes/1.3/index.html @@ -0,0 +1,32 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.3 +description: Sitespeed.io is an open source tool that helps you analyze and optimize your website speed and performance, based on perfor +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.3 +nav: +image: +--- +
+

Sitespeed.io 1.3 release notes

+
+ +
+Sitespeed 1.3 was relased the 15th of November 2012. The main goal with the release was to make all result pages responsive, so they can be viewable on a phone/tablet in a nice looking way. + + +

Improvements

+
    +
  • All result pages are now responsive, standard stuff except the table in pages.vm, two different tables, one for phones, one for the rest
    • +
  • Moved webpagetest link from pages.vm to page, to make more space, because the page was broken on tablets
    • +
  • Added the summary data also on page.vm
    • +
  • Added possibility to output all page data as csv file (yes that old thing)
    • +
  • Added possibility to output every html file as png, for easy include in documents/web etc
    • +
  • Added (htmlcompressor) to compress all html, to make the result pages smaller
    • +
  • Upgraded to latest version of the crawler (that version is smaller in size )
    • +
  • Added support for testing only one page (depth = 0), thanks @tomsutton1984 for the idea
    • +
+

+See the changelog for changes done in the past. +

+
diff --git a/docs/release-notes/1.4/index.html b/docs/release-notes/1.4/index.html new file mode 100644 index 0000000000..aa6b6eb2af --- /dev/null +++ b/docs/release-notes/1.4/index.html @@ -0,0 +1,69 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.4 +description: Sitespeed.io 1.4 is now released with median values on the summary page, a new rule checking if you use to much javascript and lots of small changes. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.4 +nav: +image: http://sitespeed.io/img/sitespeed-1.4-twitter.gif +twitterdescription: The new release contains with median values on the summary page, a new rule checking if you use to much javascript, the amount of js, css, images & css images on each individual page and lots of small changes. +--- +
+

Sitespeed.io 1.4 release notes

+
+ +

+Sitespeed 1.4 was relased the 5th of December 2012. The main goal with the release was to add median values for all statistics on the summary page (before only average values was displayed). This is what's done in this release: +

+ +
+
    +
  • +
    + Show median value on the summary page +

    Median values

    +

    Median values are now shown for all statistics on the summary page (shows both average & median).

    +
    +
    • +
  • +
    + Too much javascript +

    Too much javascript?

    +

    The amount of javascript on each page are calculated and compared with the amount of textual content, to make it visible how much javascript that is used.

    +
    +
    • + +
  • +
    + The size of js & css compared to text +

    Too much js & css?

    +

    The size of javasscript and css on each individual page are compared to the textual content, in order to get a feel of how much js & css you use.

    +
    +
    • +
  • +
    + The actual size in kb of images, css, js & css images +

    Total weight on page

    +

    Added image, css, js and css image total weight in kb on the indivdual page summary.

    +
    +
    • +
+
+

And these minor ones: +

+ +
    +
  • Changed the limit value for doc size on the summary page, was 10 kb but gzip is not taken inconcideration, changed to 100 kb!
    • +
  • Concatenating css & js files in the results to one file each.
    • +
  • Made Java heap size & result directory configurable from the sitespeed script. Read more here and here.
    • +
  • Cleanup of the sitespeed.io script, removed unused code and made a structure easier to maintain.
    • +
  • You can now zip the output result files by passing a parameter to the script. Read exactly how you do it here.
    • +
  • Upgraded to latest crawler & xml-velocity jar.
    • +
  • Upgraded jQuery from 1.8.2 to 1.8.3
    • +
+ +

Also the documentation has been reworked.

+ +

+See the changelog for changes done in the past. +

diff --git a/docs/release-notes/1.4/jscsssizes.png b/docs/release-notes/1.4/jscsssizes.png new file mode 100644 index 0000000000..726708dd48 Binary files /dev/null and b/docs/release-notes/1.4/jscsssizes.png differ diff --git a/docs/release-notes/1.4/jspercentage.jpg b/docs/release-notes/1.4/jspercentage.jpg new file mode 100644 index 0000000000..35a8580ae7 Binary files /dev/null and b/docs/release-notes/1.4/jspercentage.jpg differ diff --git a/docs/release-notes/1.4/median.jpg b/docs/release-notes/1.4/median.jpg new file mode 100644 index 0000000000..5bb2efd90f Binary files /dev/null and b/docs/release-notes/1.4/median.jpg differ diff --git a/docs/release-notes/1.4/sizes.png b/docs/release-notes/1.4/sizes.png new file mode 100644 index 0000000000..d8af84e23a Binary files /dev/null and b/docs/release-notes/1.4/sizes.png differ diff --git a/docs/release-notes/1.5/index.html b/docs/release-notes/1.5/index.html new file mode 100644 index 0000000000..6f8066400c --- /dev/null +++ b/docs/release-notes/1.5/index.html @@ -0,0 +1,56 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.5 +description: The new release contains four new rules (check out the critical rendering path rule!), a fine tuned SPOF rule, time to first byte, ability to set user agent/viewport, use a proxy and more! +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.5 +nav: +image: http://sitespeed.io/img/sitespeed-1.5-twitter.jpg +twitterdescription: The new release contains four new rules (check out the critical rendering path rule!), a fine tuned SPOF rule, time to first byte, ability to set user agent/viewport, use a proxy and more! +--- +
+

Sitespeed.io 1.5 release notes

+
+ +

+Sitespeed 1.5 was released the 6th of January 2013 with the following changes: +

+ +

New rules

+
    +
  • The Critical Rendering Path - Every request fetched inside of HEAD, will postpone the rendering of the page, so be aware of what you actually do. Read more about the rule and read about the rendering path in this really good article by Ilya Grigorik.
    • +
  • Avoid CDN lookups when your page has few requests - If you have few requests on a page, they should all be on the same domain to avoid DNS lookups, because the lookups will then cost much.
    • +
  • Do not load stylesheet files when the page has few request - When a page has few requests (or actually maybe always if you don't have a massive amount of css), it is better to inline the css, to make the page to start render as early as possible. Yes, people will say "will not caching be a problem"? Please try it out and you will see :)
    • +
  • Have a reasonable percentage of textual content compared to the rest of the page - Not much to say about it.
    • +
  • Fine tuned the SPOF rule: Now the font-face problems will be checked.
    • +
+ +

New functionality

+
    +
  • Support for configuring the crawler (see the dependencies/crawler.properties file). You can now configure the number of crawler threads and connection/socket timeout.
    • +
  • Support for analyze behind proxy (thanks rhulse and samteeee for reporting and testing it). Configure it like this.
    • +
  • You can now see errors from the crawl. If you have internal links that returns errors, an extra report file will be created.
    • +
  • You can now set the user agent & view port.
    • +
  • You can now see the percentage of things when you hover on the summary page, for example how many percent of the request are missing a far expire header.
    • +
  • Added time to first byte for each page (cURL is now a new requirement to run sitespeed.io)
    • +
  • Cleanup of the Full page analyzis page, the page shows now both Requests per Content-Type and Size per Content-Type
    • +
+ +

Bugfix

+
    +
  • The document weight now shows the real size (gzipped when it is).
    • +
  • The check for if PhantomJS is installed wasn't working, fixed now.
    • +
  • Now using JAVA_HOME in a correct way (thanks Rob-m).
    • +
  • Upgraded the crawler to version 1.3, now only fetch text/html links (before it also fetched xml etc).
    • +
+ +

Removed functionality

+
    +
  • Removed experimental rule for the amount of JS used because it wasn't adding any value.
    • +
  • Removed csv as output format (too much work to keep up to date).
    • +
+ + +

+See the changelog for changes done in the past and the next milestone what will come in the next release. +

diff --git a/docs/release-notes/1.6/assets.jpg b/docs/release-notes/1.6/assets.jpg new file mode 100644 index 0000000000..169a6ad0b2 Binary files /dev/null and b/docs/release-notes/1.6/assets.jpg differ diff --git a/docs/release-notes/1.6/average.jpg b/docs/release-notes/1.6/average.jpg new file mode 100644 index 0000000000..3cbe03838d Binary files /dev/null and b/docs/release-notes/1.6/average.jpg differ diff --git a/docs/release-notes/1.6/bydomain.jpg b/docs/release-notes/1.6/bydomain.jpg new file mode 100644 index 0000000000..6857799917 Binary files /dev/null and b/docs/release-notes/1.6/bydomain.jpg differ diff --git a/docs/release-notes/1.6/frontback.jpg b/docs/release-notes/1.6/frontback.jpg new file mode 100644 index 0000000000..f93c56bf98 Binary files /dev/null and b/docs/release-notes/1.6/frontback.jpg differ diff --git a/docs/release-notes/1.6/index.html b/docs/release-notes/1.6/index.html new file mode 100644 index 0000000000..157ad8269b --- /dev/null +++ b/docs/release-notes/1.6/index.html @@ -0,0 +1,74 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.6 +description: Sitespeed.io 1.6 release contains a really easy way to see which assets that should have longer cache times and some other small changes. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.6 +nav: +image: http://sitespeed.io/img/sitespeed-1.5-twitter.jpg +twitterdescription: The new release contains a really easy way to identify which assets that should have longer cache times, better handling of the SPOF rule & see the most used assets on the site. +--- +
+

Sitespeed.io 1.6 release notes

+
+ +

Find the assets that should have longer cache time

+

Wow, I really like this feature :) The idea was adopted from Steve Souders of functionality that's missing in the webperf tools that exist today. +It is actually three functions: +

    +
  1. +On the detailed page level, you will for every asset see the time since it was last changed (now date minus last modification date) and +the actual cache time. This give you a nice view to see if assets are cached too short. Check this example:

    + + +

    The asset marked in red was +last changed 315 days ago, but the cache time is 0s. That's not good.

    +
    2. +
  2. +

    You will also see a summary of all assets on an individual page, of the average time since last modification and the cache time.

    + + +
    3. +
  3. +

    On the summary page, you will get the same information but for the whole site. In this example, the average cache time is 10 days (and the median is 0 seconds). The average time since last modification for all assets are 321 days (and the median 189). You will gain a lot if you change the cache headers for this site :)

    + + +
    4. +
+ +

The most used assets on the site

+

Introducing a new brand thing: see which assets are used the most across the analyzed pages. Thanks Tobias Lidskog for the great idea! Here you will see the most (max 200) assets, and how many times they are used. This will give you a hint on which assets you will win the most to fine tune.

+ + + + +

Better handling of the SPOF rule

+

The SPOF rule now only report font face that are loaded from another top level domain (that seems more reasonable than report all font face files). Also the actual font file is reported (before only the css that included the font-face). + +

Show requests per domain on individual page

+

Summarize the requests by domain, so you easy can see how the requests are sharded between domains. Every webperf tool has it, now also sitespeed.

+ + + +

Configure Yslow backend & rules

+

Now it is possible to add a parameter to the script to choose which ruleset or which Yslow file to use. This has two great wins: +If you clone your own version, you can test your own rules without changing the main script. It also makes it more flexible in the future, +opening up for multiple rulesets & rule implementations

+ +

Time spent in backend vs frontend

+

No rules attached to this yet, this is more if informational data. How much time do your site spend in backend & in frontend? You will see the information both on each individual page and on the summary page (the new blue informational color). +

+ + +

Adjusted rules on summary page

+Adjusted the warning rules on the summary page, now a warning is up to the average number collected from http://www.httparchive.org (where applicable). For example: to get red (BAD!) on number of css files, you need to exceed the average number of css files, that the sites have that is collected by HTTP Archive. + +

New Yslow version

+

Yslow has been upgraded with better error handling of faulty javascripts.

+ +

Use Java 1.6 or higher

+

The Java code used by sitespeed is now compiled for Java 1.6, so 1.7 is no longer the requirement.

+
+

+See the changelog for changes done in the past and the next milestone what will come in the next release. +

diff --git a/docs/release-notes/1.6/newassets.jpg b/docs/release-notes/1.6/newassets.jpg new file mode 100644 index 0000000000..86b5c482ea Binary files /dev/null and b/docs/release-notes/1.6/newassets.jpg differ diff --git a/docs/release-notes/1.6/page.jpg b/docs/release-notes/1.6/page.jpg new file mode 100644 index 0000000000..698a6490bd Binary files /dev/null and b/docs/release-notes/1.6/page.jpg differ diff --git a/docs/release-notes/1.6/summary.jpg b/docs/release-notes/1.6/summary.jpg new file mode 100644 index 0000000000..95a7f49b55 Binary files /dev/null and b/docs/release-notes/1.6/summary.jpg differ diff --git a/docs/release-notes/1.7/cacheable.jpg b/docs/release-notes/1.7/cacheable.jpg new file mode 100644 index 0000000000..38aa99eb32 Binary files /dev/null and b/docs/release-notes/1.7/cacheable.jpg differ diff --git a/docs/release-notes/1.7/dom.jpg b/docs/release-notes/1.7/dom.jpg new file mode 100644 index 0000000000..666fc15584 Binary files /dev/null and b/docs/release-notes/1.7/dom.jpg differ diff --git a/docs/release-notes/1.7/expires.jpg b/docs/release-notes/1.7/expires.jpg new file mode 100644 index 0000000000..474e2515aa Binary files /dev/null and b/docs/release-notes/1.7/expires.jpg differ diff --git a/docs/release-notes/1.7/index.html b/docs/release-notes/1.7/index.html new file mode 100644 index 0000000000..a09860f30d --- /dev/null +++ b/docs/release-notes/1.7/index.html @@ -0,0 +1,95 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.7 +description: Sitespeed.io 1.7 release contains support for using sitespeed in your continuous integration tool. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.7, jenkins, travis +nav: +image: http://sitespeed.io/img/sitespeed-1.7-twitter.png +twitterdescription: Sitespeed.io + Jenkins = LOVE! Yes, with the new release you can run sitespeed in your continuous integration tool, generating JUnit XML and for sure know when you break the rules! +--- +
+

Sitespeed.io 1.7 release notes

+
+ +

Sitespeed.io + Jenkins = LOVE

+

Sitespeed.io can now output JUnit XML that you can use in your continuous integration tool. With that, you can for every build test your site against +the rules! In the documentation you will see how to do it for Jenkins & Travis (Travis don't have full support yet for JUnit XML but you can still make sure that builds get broken if you violate the rules). +

+

+You can specify your own limits of when you want the tests to fail: for the overall score and the limit for individual tests. And you can of course skip tests. Using Jenkins you will get information per page and per test, so you easy can see what is failing. +

+ +

+ +

+ +

Feed the beast with a list of URL:s

+

For some sites crawling the site isn't the best thing; you want to test a couple of the most used pages (some of them longer down in the path tree). Now you can do that by supply a list of URL:s to sitespeed to test. +

+

The list is a plain text file with one URL on each line and the first URL will give the name of the whole test. Here's an example of a file: +

+
+http://peterhedenskog.com/
+http://peterhedenskog.com/work/
+http://peterhedenskog.com/music/
+
+

Check the documentation of how to do it. Note: The parameter to supply a file is f meaning that the old functionality "follow only this path when crawling" has changed to parameter c so please make sure you change that if you use that functionality. +

+ +

New functionality

+
+
    +
  • +
    + DOM elements on summary page +

    DOM elements

    +

    You can now see the average & median number of DOM elements on the site summary and for a specific page.

    +
    +
    • +
  • +
    + No expire header +

    Missing expire

    +

    See how many assets on your site that is missing an expire header (I hope it is none!).

    +
    +
    • + +
  • +
    + Cached assets +

    Cached assets

    +

    How many of your assets are being cached?

    +
    +
    • +
  • +
    + New page summary +

    New page summary

    +

    The summary has been redesigned, now you can see cache, content, time, content-type and domain metrics.

    +
    +
    • +
+
+ + +

Small fixes

+
    +
  • The max size of a document for getting a warning has been changed, now using statistics from HTTPArchive.
    • +
  • The primed cache values has been removed from site summary & site detailed report, because they wasn't actually showing correct values all the time.
    • +
  • The Yslow rule ynumreq has been removed and replaced by three new ones in order to get clearer JUnit XML results: cssnumreq, cssimagesnumreq & jsnumreq
    • +
  • You can now see the response headers info on the assets page.
    • +
+ + +

Bug fixes

+
    +
  • If a max age HTTP cache header was missing the cache time part, the cache time was set to 0 instead of checking if an Expire header exists.
    • +
  • If an asset was missing expire headers, it inherited the last one assets with an expire date/header.
    • +
+ +

+
+

+See the changelog for changes done in the past and the next milestone what will come in the next release. +

diff --git a/docs/release-notes/1.7/summary.jpg b/docs/release-notes/1.7/summary.jpg new file mode 100644 index 0000000000..ec1151d763 Binary files /dev/null and b/docs/release-notes/1.7/summary.jpg differ diff --git a/docs/release-notes/1.8.1/index.html b/docs/release-notes/1.8.1/index.html new file mode 100644 index 0000000000..502d09f988 --- /dev/null +++ b/docs/release-notes/1.8.1/index.html @@ -0,0 +1,33 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.8.1 +description: Sitespeed.io 1.8.1 release holds three really important bug fixes. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.8.1 +nav: +image: http://sitespeed.io/img/sitespeed-1.5-twitter.jpg +twitterdescription: Yes box, here are some really nice bug fixes. +--- +
+

Sitespeed.io 1.8.1 release notes

+
+ +

There are three really important bug fixes in the 1.8.1 release, all three are now fixed in the sitespeed.io/YSlow branch and included in sitespeed.io

+ +
    +
  • YSlow didn't honour max-age before expires (following the 1.1 HTTP specification), meaning for sites that had different values for max-age & expires, YSlow reported the expires header as the cache time even when a max-age header existed.
    • + +
  • If a CSS file imported other CSS files with a relative url using the @import directive, that CSS wasn't fetched by YSlow, meaning the cache time & size was not in the result.
    • + +
  • There was a mismatch between assets actually fetched by PhantomJS and Yslow, where PhantomJS don't collect all the assets used by the page. The end result was that some assets didn't get the response headers, meaning cachetime, size etc was unknown. This was the reason why no favicons and Google fonts was fetched correct before.
    • +
+ +

Also two other things fixed, first in the detailed summary page, the TTFB is in seconds, not milliseconds as done before. Thanks Peter van Gils for reporting!

+ +

The second thing is that now when every asset is fetched, the YSlow rule check if a favicon is cached was added and the favicon is now checked in the cache expire rules.

+ + +
+

+See the changelog for changes done in the past. +

diff --git a/docs/release-notes/1.8.2/index.html b/docs/release-notes/1.8.2/index.html new file mode 100644 index 0000000000..1a1f6b0e53 --- /dev/null +++ b/docs/release-notes/1.8.2/index.html @@ -0,0 +1,37 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.8.2 +description: Sitespeed.io 1.8.2 release let you export the pages info as CSV, better error logging and some bug fixes. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.8.2 +nav: +image: http://sitespeed.io/img/sitespeed-1.5-twitter.jpg +twitterdescription: This release let you export the pages info as CSV, better error logging and some bug fixes. +--- +
+

Sitespeed.io 1.8.2 release notes

+
+ +

The 1.8.2 release contains some new small features, cleanup & bug fixes.

+ +

New features/enhancements

+
    +
  • CSV export - you can now export the pages data to a CSV file (added it again) with the switch "-o csv"
    • +
  • Content type percentage - the detailed page now show percentage of requests & size per content type
    • +
  • Better error reporting - a URL that fails e.g. breaks the test, now logs the exact URL, the error message and add the URL to the error list. Also if a cookie is wrongly set, the URL that sets the cookie is logged. Also the Java & PhantomJS version is always shown
    • +
  • Content categories - Favicon and the document are now own categorizes in the detailed page summary
    • +
  • Cleanup - before two different Javascript column sorters was used (on different pages), now one is used
    • +
  • Cleanup - the output is cleaner if you run a test with a list of URLs from a file
    • +
+ +

Bug fixes

+
    +
  • If a page was redirected, the gzipped size was before fetched as 0
    • +
  • For some sites (example www.bike.se) the total weight was fetched wrong by YSlow, now the weight is calculated from each assets on the pages info page
    • +
  • URLs containing & broke some tests
    • +
  • In very rare cases, YSlow reports a larger cache weight than the page weight. The bug is not fixed but when it happens, an error message is displayed
    • + +
    +

    +See the changelog for changes done in the past. +

    diff --git a/docs/release-notes/1.8.3/index.html b/docs/release-notes/1.8.3/index.html new file mode 100644 index 0000000000..a8e0565611 --- /dev/null +++ b/docs/release-notes/1.8.3/index.html @@ -0,0 +1,26 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.8.3 +description: Sitespeed.io 1.8.3 release focus on some small bug fixes for TTFB. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.8.3 +nav: +image: http://sitespeed.io/img/sitespeed-1.5-twitter.jpg +twitterdescription: This release fixes & makes thing clenar if there is problem with the TTFB. +--- +
    +

    Sitespeed.io 1.8.3 release notes

    +
    + +

    The 1.8.3 release contains some bug fixes that makes the time to first byte (TTFB) and frontend/backend time cleaner:

    +
      +
    • TTFB - today there is no way to get the TTFB from PhantomJS, it is fetched by a extra request using curl. Some sites vary much in TTFB between requests, meaning TTFB can be much higher the next request, even higher than the load time the first request. If this happens it is now highlighted in pages summary and page details, so you can investigate it further.
      • +
    • Median value front/backend time - show median front/back end time instead of percentile on summary page.
      • +
    • Cleanup - when the TTFB is larger than page load time, don't add it to summary statistics.
      • +
    • Cleanup - for some sites (very rarely) the total weight was fetched wrong by YSlow, fixed last release for all pages except summary & summary details.
      • +
    +

    And there is one new small feature: You can now supply a test name that will be showed on all test result pages (using the parameter n). See an example here.

    +
    +

    +See the changelog for changes done in the past. +

    diff --git a/docs/release-notes/1.8/detailed-summary-large-image.png b/docs/release-notes/1.8/detailed-summary-large-image.png new file mode 100644 index 0000000000..f3e50d1903 Binary files /dev/null and b/docs/release-notes/1.8/detailed-summary-large-image.png differ diff --git a/docs/release-notes/1.8/image-weight.png b/docs/release-notes/1.8/image-weight.png new file mode 100644 index 0000000000..75709e3c39 Binary files /dev/null and b/docs/release-notes/1.8/image-weight.png differ diff --git a/docs/release-notes/1.8/index.html b/docs/release-notes/1.8/index.html new file mode 100644 index 0000000000..0bf6b140cc --- /dev/null +++ b/docs/release-notes/1.8/index.html @@ -0,0 +1,58 @@ +--- +layout: default +title: Sitespeed.io - Release notes 1.8 +description: Sitespeed.io 1.8 release adds a more detailed summary to help you keep track of your site. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 1.8, jenkins +nav: +image: http://sitespeed.io/img/sitespeed-1.5-twitter.jpg +twitterdescription: It is all in the (summary) details! It is now easier to keep track how your site is really doing with median, X percentile, max & min values. +--- +
    +

    Sitespeed.io 1.8 release notes

    +
    + +

    It's all in the (summary) details

    +

    The summary page is now based on the summary.xml file. The XML file keeps information of all fields you see on the summary page for all the pages that has been tested. For all the metrics you will get the average, median, max, min, standard deviation, variance, 10 percentile, 90 percentile & the 95 percentile! Yes that is a lot of difference statistics and it is quite cool!

    +How do you actually make use of it? Well for example, you can easily see which is the largest image of your site, check this out (data collected from a big video site): + +

    You will find the link to the detailed summary on the start page of the result pages. When the new design is added, it will be in the navigation

    + +

    You can also use the summary.xml file with Jenkins. You can use the Plot plugin and create graphs between your test runs, keep track of what's happening with your site in your development cycle.

    + + +

    There are also some new metrics: The total per page and individual size of js/css and images. You can check out an example of the summary.xml file.

    + +

    Goodbye average, hello the 90th percentile!

    +The summary page used to report average values of all different metrics. That has been changed, now median & the 90th percentile is the standard. + +

    Preparing for comparing different runs

    +

    + The report dir name & structure has been changed, to make it easier to compare runs in the future. The old structure was sitespeed-HOST-DATE, now it is HOST/DATE. +

    + +

    New rule checking for old versions

    +

    There is a new rule in town that checks if the latest version is used of a Javascript plugin. Right now the only check is for the latest JQuery version, in the future other plugins will be checked.

    + + +

    Image size are important!

    +

    + On the summary page, you can now see the total image size per page (median & 90 percentile values of course). +

    + + +

    New way of how to output the JUnit XML

    +

    A few changes to make things easier: By default, the JUnit xml file is now named sitespeed.io-junit.xml. You need to configure the output directory (see the docs) and the script will also put a copy of the summary.xml in the same dir. +

    + +

    Bug fixes

    +
      +
    • The check for number of DOM elements where wrong when signalling a warning.
      • +
    • Better check for Java version (thanks Emil Breding).
      • +
    + +

    +
    +

    +See the changelog for changes done in the past. +

    diff --git a/docs/release-notes/1.8/jenkins-page-weight.png b/docs/release-notes/1.8/jenkins-page-weight.png new file mode 100644 index 0000000000..430db16413 Binary files /dev/null and b/docs/release-notes/1.8/jenkins-page-weight.png differ diff --git a/docs/release-notes/1.8/jquery.png b/docs/release-notes/1.8/jquery.png new file mode 100644 index 0000000000..4ce8143da6 Binary files /dev/null and b/docs/release-notes/1.8/jquery.png differ diff --git a/docs/release-notes/2.0/browser-scaled-images.png b/docs/release-notes/2.0/browser-scaled-images.png new file mode 100644 index 0000000000..7016bf7f2d Binary files /dev/null and b/docs/release-notes/2.0/browser-scaled-images.png differ diff --git a/docs/release-notes/2.0/columns-time.png b/docs/release-notes/2.0/columns-time.png new file mode 100644 index 0000000000..bad754cf35 Binary files /dev/null and b/docs/release-notes/2.0/columns-time.png differ diff --git a/docs/release-notes/2.0/columns.png b/docs/release-notes/2.0/columns.png new file mode 100644 index 0000000000..9bb3565746 Binary files /dev/null and b/docs/release-notes/2.0/columns.png differ diff --git a/docs/release-notes/2.0/index.html b/docs/release-notes/2.0/index.html new file mode 100644 index 0000000000..e9ab7563bb --- /dev/null +++ b/docs/release-notes/2.0/index.html @@ -0,0 +1,66 @@ +--- +layout: default +title: Sitespeed.io - Release notes 2.0 +description: The 2.0 release is here. Test multiple sites with one go, configure what you want to see and fetch timings using the Navigation Timing API (and custom measurements!) +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 2.0 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: The 2.0 release is here! Test multiple sites with one go, configure what you want to see and fetch timings using the Navigation Timing API (and custom measurements!). +--- +
    +

    Sitespeed.io 2.0 release notes

    +
    +

    Well, it took all summer and almost the autumn to get it ready and now it is here! Almost everything has been reworked & cleaned up, here are the new major changes:

    + +

    Configurable summary boxes

    +

    You can now choose which data that is showed in the summary boxes on the first page. You can also create your own boxes (with your own data) and set the rule limits (when to signal red/yellow/green).

    +

    +The summary boxes, now you can change them +

    +

    Configurable columns

    +

    Yes, you can also choose & create your own data to be showed in the detailed summary columns.

    +

    Configure which colums to see!

    +

    Fetch real browser timings

    +

    Fetch Navigation Timing API data from real browser (and custom measurements) using Browser Time. You will get the info in the summary page:

    +

    See the timings in the summary

    +

    In the summary detailed page:

    +

    See the timings in the detailed summary

    +

    And specific timings on each page that has been tested:

    +

    See the timings for each page

    +

    Read more about the browser timings.

    +

    New rule: Browser scaled images

    +

    The YSlow rule yimgnoscale doesn't work with PhantomJS. The new rule compare the image browser width and the real image width and if it differ, you will get that in the output.

    +

    The result for browser scaled images

    +

    Test multiple sites & compare them

    +

    You can now test multiple sites and compare them using the sitespeed-sites.io script (you can choose what kind of data to compare).

    +

    Test multiple sites

    +

    Test for mobile or desktop

    +

    There are now two different rule-sets, one for desktop & one for mobile.

    + +

    Rewrite

    +

    The main script (sitespeed.io) has been cleaned up & Velocity templates has been restructured.

    + +

    Upgrade to Bootstrap 3.0

    +

    The new Bootstrap version is mobile first and will render the page faster than before.

    + +

    New logo

    +

    Say hello to the new sitespeed.io logo:

    +

    The new sitespeed.io logo!

    +

    Minor changes

    +
      +
    • Phone view on detailed summary page now only contains url & score to make it simpler to maintain.
      • +
    • You can now see the IP of the computer running the test in the result.xml file.
      • +
    • You can now set the max pages to test & the name of the test (displayed on every HTML page).
      • +
    • Simplified user agent by choosing between iphone, ipad or nexus and a real agent & viewport is set.
      • +
    • Output as CSV: Choose which column to output and always output ip, start url & date.
      • +
    • Fix for Windows-users that is having spaces in their path to Java.
      • +
    • Bug fix: URL:s that returns error (4XX-5XX and that sitespeed can't analyze) is now included in the JUnit xml.
      • +
    • Bug fix: The JUnit script can now output files to a relative path.
      • +
    • Bug fix: User Agent is now correctly set.
      • +
    + +
    +

    +See the changelog for changes done in the past. +

    diff --git a/docs/release-notes/2.0/page-specific-metrics.png b/docs/release-notes/2.0/page-specific-metrics.png new file mode 100644 index 0000000000..017233db1c Binary files /dev/null and b/docs/release-notes/2.0/page-specific-metrics.png differ diff --git a/docs/release-notes/2.0/sites.png b/docs/release-notes/2.0/sites.png new file mode 100644 index 0000000000..c9d3c9a24f Binary files /dev/null and b/docs/release-notes/2.0/sites.png differ diff --git a/docs/release-notes/2.0/summary.png b/docs/release-notes/2.0/summary.png new file mode 100644 index 0000000000..1cd9a17378 Binary files /dev/null and b/docs/release-notes/2.0/summary.png differ diff --git a/docs/release-notes/2.0/time-summary.png b/docs/release-notes/2.0/time-summary.png new file mode 100644 index 0000000000..621e626b1c Binary files /dev/null and b/docs/release-notes/2.0/time-summary.png differ diff --git a/docs/release-notes/2.1.1/index.html b/docs/release-notes/2.1.1/index.html new file mode 100644 index 0000000000..fe768c2604 --- /dev/null +++ b/docs/release-notes/2.1.1/index.html @@ -0,0 +1,27 @@ +--- +layout: default +title: Sitespeed.io - Release notes 2.1.1 +description: Sitespeed.io 2.1.1 release focus on some small bug fixes. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 2.1.1 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: This release fixes +--- +
    +

    Sitespeed.io 2.1.1 release notes

    +
    + +

    This release contains a couple of bug fixes:

    +
      +
    • Unable to crawl websites with GA cookie (#298, when GA uses a character that are not valid in XML).
      • +
    • The sitespeed-sites.io used the sitespeed.io script with sh instead of bash.
      • +
    • New BrowserTime version (0.2) so you now can use Firefox 25 + the wait time before breaking a test is now 60 seconds instead of 30.
      • +
    • All PhantomJS errors are now logged to a PhantomJS error log (since there is a defect in QT using Mavericks).
      • +
    • URL:s using brackets didn't get the correct document size.
      • + +
    +
    +

    +See the changelog for changes done in the past. +

    diff --git a/docs/release-notes/2.1/index.html b/docs/release-notes/2.1/index.html new file mode 100644 index 0000000000..f3b7c3645b --- /dev/null +++ b/docs/release-notes/2.1/index.html @@ -0,0 +1,38 @@ +--- +layout: default +title: Sitespeed.io - Release notes 2.1 +description: The 2.1 release makes it possible to break builds using Jenkins & Travis-CI if the browser timings hits the limits. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 2.1 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: The 2.1 release makes it possible to break builds using Jenkins & Travis-CI if the Navigation Timing metrics hits the limits. +--- +
    +

    Sitespeed.io 2.1 release notes

    +
    +

    This release focus on one thing: Break builds for Jenkins and Travis-CI if your browser + Navigation Timing API metrics doesn't meet your limits.

    +

    Break builds if your pages are too slow

    +

    Configure the limits for your pages and break builds if the timings are higher than your configuration. You can use the timings in the Navigation Timing API or create your own custom timings. Choose how many times you want to test the page and use the median or different percentile values. Read more about it here.

    +

    Keep track of your timings

    +

    Using Jenkins you can easily create graphs of your browser timings. They look like they are from the 1980's but it's quite nice info (btw nicer graphs will come in later releases)!

    +

    + +

    Use sitespeed.io in your projects with Travis-CI

    +

    Drop the latest sitespeed.io release in your project, configure the Travis config file and break the build if it doesn't meet your limits. Checkout the example project on Github. Now you can break builds if you break your web performance best practices rules or if you exceed your timing limits. Read more about the Travis-CI integration.

    + +

    Minor changes

    +
      +
    • Prepared for HTTP 2.0 rules & renamed the current rulesets. The new names: sitespeed.io-desktop & sitespeed.io-mobile
      • +
    • Better error handling: Output the input parameters to the error.log file so it is easy to reproduce the error. Also centralized the error logging
      • +
    • Made it possible to analyze sites with non signed certificates
      • +
    • Finetuned the logo
      • +
    • Bug fix: The crawler sometimes picked up URL:s linking to other content types than HTML (if you have linked to an image)
      • +
    • Bug fix: The JUnit XSLT outputted timings metrics
      • +
    + +
    +

    +See the changelog for changes done in the past. +

    diff --git a/docs/release-notes/2.2.2/index.html b/docs/release-notes/2.2.2/index.html new file mode 100644 index 0000000000..3e4fc4e9d7 --- /dev/null +++ b/docs/release-notes/2.2.2/index.html @@ -0,0 +1,24 @@ +--- +layout: default +title: Sitespeed.io - Release notes 2.2.2 +description: Sitespeed.io 2.2.2 release focus on some small bug fixes. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 2.2.2 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: This release fixes a couple of small bugs. +--- +
    +

    Sitespeed.io 2.2.2 release notes

    +
    + +

    This release contains a couple of bug fixes:

    +
      +
    • Upgraded version of Browser Time (0.4) that again collects custom user measurements (will have better docs on this later)
      • +
    • Bug fix: User marks named with spaces broke the summary.xml
      • +
    • Bug fix: Sites with extremely (I mean extremely) far away last modification time on an asset, could break an analyze
      • +
    +
    +

    +See the changelog for changes done in the past. +

    diff --git a/docs/release-notes/2.2/index.html b/docs/release-notes/2.2/index.html new file mode 100644 index 0000000000..4d98c344f4 --- /dev/null +++ b/docs/release-notes/2.2/index.html @@ -0,0 +1,32 @@ +--- +layout: default +title: Sitespeed.io - Release notes 2.2 +description: Sitespeed.io 2.2 release focus on packaging for Homebrew. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 2.2 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Sitespeed.io 2.2 release focus on packaging for Homebrew. +--- +
    +

    Sitespeed.io 2.2 release notes

    +
    + +

    This release contains a couple of fixes for making it easier to package sitespeed.io:

    +
      +
    • Important: All scripts has been moved to the bin folder, making it easier to package
      • +
    • Important: The sites & the JUnit scripts has been renamed sitespeed.io-sites & sitespeed.io-junit
      • +
    • All scripts has been cleaned to use absolute paths, making it easier to package for Homebrew
      • +
    • sitespeed-sites.io always need to have the filename of the text file containing all the URLS (before there was a default file name)
      • +
    • New BrowserTime (0.3) version including metrics backEndTime & frontEndTime
      • +
    • Changed default summary page to show backend & frontend time (removed redirectionTime & domInteractiveTime)
      • +
    • Increased timeout for the crawler for really slow pages (now 60 seconds)
      • +
    + And one bug fix: +
      +
    • The fix for removing invalid XML caharcters created by GA, sometimes broke the analyze, now fixed (#304)
      • +
    +
    +

    +See the changelog for changes done in the past. +

    diff --git a/docs/release-notes/2.4/extra-info.jpg b/docs/release-notes/2.4/extra-info.jpg new file mode 100644 index 0000000000..fe5f5a3a37 Binary files /dev/null and b/docs/release-notes/2.4/extra-info.jpg differ diff --git a/docs/release-notes/2.4/index.html b/docs/release-notes/2.4/index.html new file mode 100644 index 0000000000..3268097868 --- /dev/null +++ b/docs/release-notes/2.4/index.html @@ -0,0 +1,41 @@ +--- +layout: default +title: Sitespeed.io - Release notes 2.4 +description: Sitespeed.io 2.4 release focus on making the default setup even cleaner and works on Windows. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 2.4 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Sitespeed.io 2.4 focus on adding extra value on the defaut setup and add support for Windows (again). +--- +
    +

    Sitespeed.io 2.4 release notes

    +
    +

    Here are the most important changes:

    + +

    Microsoft Windows

    +

    With the new release sitespeed.io has been tested (and fixed) to work on Windows 8.1. You can run analyze and fetch metrics, create the JUnit results and test multiple sites at once. Check out the timing metrics fetched using Internet Explorer 11:

    +

    + +

    +

    Browser Time has been updated to a new version that works in Windows (and actually also fetch resource timing data, but that isn't used in sitespeed right now).

    +

    Better default setup on the summary page

    +

    If you use Chrome or Internet Explorer that reports the first paint time, it will automatically be showed as metric on the summary page. All browser will also show the new fields as default: requestsMissingGzip (how many requests that + are missing GZip), jsWeightPerPage (the Javascript weight per page in kb) and cssWeightPerPage (the CSS weight in kb per page).

    +

    + +

    +

    What is measured?

    +

    Now you can hover on the each metric on the summary page to see a description of what it measured.

    +

    + +

    +

    Bug fixes

    +
      +
    • The rule Avoid DNS lookups when a page has few requests was broken, couldn't tell if JS was loaded async or not, meaning the number of requests was sometimes calculated wrong.
      • +
    • You could not create JUnit output if you fetched a URL:s from file instead of crawling.
      • +
    +
    +

    +See all the changes done in this release. +

    diff --git a/docs/release-notes/2.4/new-fields.jpg b/docs/release-notes/2.4/new-fields.jpg new file mode 100644 index 0000000000..267a835394 Binary files /dev/null and b/docs/release-notes/2.4/new-fields.jpg differ diff --git a/docs/release-notes/2.4/time-metrics-ie-windows.jpg b/docs/release-notes/2.4/time-metrics-ie-windows.jpg new file mode 100644 index 0000000000..eb0a8af31a Binary files /dev/null and b/docs/release-notes/2.4/time-metrics-ie-windows.jpg differ diff --git a/docs/release-notes/2.5/2browsers.png b/docs/release-notes/2.5/2browsers.png new file mode 100644 index 0000000000..1e7c7f6175 Binary files /dev/null and b/docs/release-notes/2.5/2browsers.png differ diff --git a/docs/release-notes/2.5/index.html b/docs/release-notes/2.5/index.html new file mode 100644 index 0000000000..c35cb96576 --- /dev/null +++ b/docs/release-notes/2.5/index.html @@ -0,0 +1,45 @@ +--- +layout: default +title: Sitespeed.io - Release notes 2.5 +description: Sitespeed.io 2.5 makes it possible to test in multiple browsers in one run. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 2.5 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Sitespeed.io 2.5 makes it possible to test in multiple browsers in one run. +--- +
    +

    Sitespeed.io 2.5

    +
    +

    The brand new thing is that you can test with multiple browsers with one run! Before I show you, there's one really IMPORTANT thing: the parameters have changed when you collect metrics, you choose which browser with the + c parameter and the z decides how many runs per page (three is still the default value). + It looks like this ( test the URL ten times with Chrome):

    + 
    $ ./bin/sitespeed.io -u https://www.sitespeed.io -c chrome -z 10
    +

    If you want to test with multiple browsers, you add each browser separated with a comma:

    +
    $ ./bin/sitespeed.io -u https://www.sitespeed.io -c firefox,chrome
    +

    Then you will get timings from both the browsers, by default fetching each URL three times. On the summary page, the summaries will be for both Firefox & Chrome:

    + The metric summary data +

    All the summary timings will be named with the browser name at the end of the name. To get domContentLoadedTime for Firefox, you configure to fetch domContentLoadedTimeFirefox. Here's an exampe running on Windows, only showing + domContentLoadedTime for each browser:

    +
    $ bin/sitespeed.io -u https://www.sitespeed.io -c firefox,chrome,ie -b domContentLoadedTimeFirefox,domContentLoadedTimeChrome,domContentLoadedTimeIE
    +

    And the summary will then look something like this:

    +Summary per browser +
    Running Internet Explorer on Windows have some caching issues (meaning the cache is not cleared between runs). If you have a good solution on how to solve that for Selenium, please send + me or Tobias a tweet.
    + +

    + On the details page, you will see the data for each browser: +

    + The metrics from two browsers + +

    Jenkins

    +

    If you are using the Jenkins plugin, you need to upgrade it to the new beta 7 version to be able to get all the browser metrics into Graphite. The summary metrics will look the same + except that you will have an extra level per browser.

    + +
    Remember that the metrics we fetch are synthetic measurements, it will not be the same for real users BUT if you fetch sufficient times (maybe 30 times per URL) then you can safely compare the timings between runs.
    + +

    +
    +

    +See all the changes done in this release. +

    diff --git a/docs/release-notes/2.5/summaries.png b/docs/release-notes/2.5/summaries.png new file mode 100644 index 0000000000..4e37d85545 Binary files /dev/null and b/docs/release-notes/2.5/summaries.png differ diff --git a/docs/release-notes/2.5/summary-per-browser.png b/docs/release-notes/2.5/summary-per-browser.png new file mode 100644 index 0000000000..96cdd49f50 Binary files /dev/null and b/docs/release-notes/2.5/summary-per-browser.png differ diff --git a/docs/release-notes/3.0/index.html b/docs/release-notes/3.0/index.html new file mode 100644 index 0000000000..d97a5796b6 --- /dev/null +++ b/docs/release-notes/3.0/index.html @@ -0,0 +1,58 @@ +--- +layout: default +title: Sitespeed.io - Release notes 3.0 +description: The new sitespeed.io has support for driving WebPageTest, send metrics to Graphite and much more. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 3.0 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: The new sitespeed.io has support for driving WebPageTest, send metrics to Graphite and much more. +--- +
    +

    Sitespeed.io 3.0

    +
    +

    Yep, it took us almost half a year to migrate sitespeed.io to NodeJS and now it is ready for a release! The new version is faster, has a much richer feature list and is +so much easier to maintain.

    +

    Here's a list of the new things:

    +
      +
    • NodeJS - We moved (almost) everything to NodeJS. We are still dependent on Java, because the (old) Java crawler is still used and we will try to remove it in the future. + The new version is faster than the old one. And so much easier to change and better separation between logic and
      • +
    • Send metrics to Graphite - one of the number one feature requests for sitespeed.io has been to collect data over time and graph it. Sitespeed.io now supports sending the metrics to Graphite It can looks something like this + +
      • + +
    • RUM SpeedIndex - We have rewritten BrowserTime to NodeJS, and it now supports running whatever javascript snippet you want< meaning you can fetch whatever + metric you want. It is not fully implemented yet in sitespeed.io, but with the current version it gives us + Pat Meenans RUM SpeedIndex and support for getting resource timing API metrics.
      • +
    • PostTask - when sitespeed.io has analyzed all pages and collected the metrics, you can run your own code to handle the result. This can be used to store the data in a database + or create your own reports. +
      • +
    • Drive WebPageTest - you can now feed WebPageTest with URL:s to test and collect the metrics and include them in your sitespeed.io report. + +
      • +
    • Google Page Speed Insights - collect the score and other data and show it in your sitespeed.io report. + +
      • +
    • Support for PhantomJS 2 - yep we know, 2.0 is not released yet and we are really looking forward to it, so + we added the functionality to use it already. What's extra cool with 2.0 (except that it is much faster) is that it supports the Navigation Timing API. You can use it by pointing out your binary by --phantomjsPath
      • +
    • Two new rules - check if connection is closed and don't set private headers on static assets.
      • +
    • Two new summary pages - slowest domains and hotlist (find troublesome assets fast)
      • +
    • TAP - you can now generate TAP reports, making your CI tool break your build if you don't follow the web performance best practice rules
      • +
    • Performance budget - we kind of had support for a performance budget before with the JUnitXML. With the new version it is much cleaner: specify which values + you will test against and run.
      • +
    • Throttle the connection - You can throttle the connection when you are fetching timing metrics from the browser. Choose between: +
        +
      • mobile3g - 1.6 Mbps/768 Kbps - 300 RTT
        • +
      • mobile3gfast - 1.6 Mbps/768 Kbps - 150 RTT
        • +
      • cable - 5 Mbps/1 Mbps - 28 RTT
        • +
      • native - the current connection
        • +
      +
      • +
    + +

    Tobias and me (Peter) have worked really hard the last half year to make the 3.0 release happen. We hope that you will love it as much as we do. + There are still bugs out there, if you find them, please add an issue at GitHub and solve it with a pull request :) + +

    The input parameters has changed since 2.5. Yep we know it is bad practice, the reason is that the old version +had a really bad CLI handling where you could only fetch a input parameter with a character and we where running out of characters! To see the new parameters see +
    sitespeed.io -h
    diff --git a/docs/release-notes/3.1/index.md b/docs/release-notes/3.1/index.md new file mode 100644 index 0000000000..ea6539ef2a --- /dev/null +++ b/docs/release-notes/3.1/index.md @@ -0,0 +1,47 @@ +--- +layout: default +title: Sitespeed.io - Release notes 3.1 +description: The new sitespeed.io has support for driving multiple WebPageTest locations/browsers/connectivity and choose to collect metrics using PhantomJS or SlimerJS. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 3.1 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: The new sitespeed.io has support for driving multiple WebPageTest locations/browsers/connectivity and choose to collect metrics using PhantomJS or SlimerJS. +--- + +# Sitespeed.io 3.1 +After releasing 3.0 we felt that there was one big thing that we missed. You could only run one location/browser or use one connectivity per run when fetching data from WebPageTest! We have fixed that in 3.1 + +## Run multiple locations of WebPageTest +You can now test multiple locations/browesers/connectivities for WebPageTest in one and the same run for sitespeed.io. You do that with the wptConfig parameter. If you want to run multiple instances, configure an array with different configurations: + +~~~ +[ + { + "location": "Dulles:Firefox", + "connectivity": "3G" + }, + { + "location": "Dulles:Chrome", + "connectivity": "Cable" + } +] +~~~ + +Running only one, you can do as before and only configure one configuration object: + +~~~ +{ + "location": "Dulles:Firefox", + "connectivity": "3G" +} +~~~ + +Everything will work as before except that the keys in Graphite for WebPageTest will include location, browser and connectivity meaning after you installed the new version you need to go into your grafical interface (Grafana) and change the keys for WebPageTest. + + +## Hello SlimerJS! + +We cannot tell you have much love we have for PhantomJS! To show it, we also include support for SlimerJS :) Slimer is not headless but kind of/or headlessish. You can now choose with the flag headless which backend to use (PhantomJS is the default one). Another change is that collecting timing metrics using the headless alternative is made by configuring -b headless and will use the backend you configured with the headless flag. + + Remember: To collect timings using PhantomJS you need the soon coming 2.0 version. diff --git a/docs/release-notes/3.2/index.md b/docs/release-notes/3.2/index.md new file mode 100644 index 0000000000..d5f039f4a6 --- /dev/null +++ b/docs/release-notes/3.2/index.md @@ -0,0 +1,27 @@ +--- +layout: default +title: Sitespeed.io - Release notes 3.2 +description: Here is 3.2 making it easier to test multiple sites and running your custom Javascript to collect metrics. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 3.2 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: THere is 3.2 making it easier to test multiple sites and running your custom Javascript to collect metrics. +--- + +# Sitespeed.io 3.2 +We've been releasing many small 3.1.x releases and now it's time for 3.2. Here are three important new things: + + * We have changed the way of fetching multiple sites. In the new version you can configure multiple sites by adding the parameter **sites** one time for each site. The main reason is that it simpler and also makes it easier to run in our Docker container. Check the full [documentation](/documentation/configuration/#analyze-sites-and-benchmark). + * We have decreased the default size of the memory for the Java crawler. The old default (1024 mb) was good for crawling thousend of URL:s so if you are doing that today, add the parameter *--memory 1024* when you run the script. 1024 works bad on small machines so 256 is the new default. + * We upgraded to Browsertime 0.9.0 with support for configuring a *waitScript* and run custom Javascripts in the browser. What does it mean? You can now choose [when to end a run](/documentation/browsers/#choose-when-to-end-your-test) when fetching timings from the browser (catching events happening after the loadEventEnd) and [collect custom metrics](/documentation/browsers/#custom-metrics). The custom metrics will automatically be presented in the result pages and sent to Graphite. + +The new 3.2 helps us getting ready for the next cool feature, lets stay tuned the coming month :) + +Interesting new stuff in the 3.1.x releases: + + * Cleanup of the perf budget handling. the script will return an error code if the budget fails and will log failing budget metrics and an HTML page showing the budget report. + * Upgraded BrowserTime that works as it should on Windows. + * Send domain timings to Graphite and timings per request. + * No robot removed from the HTML pages. + * Many small bug fixes, checkout the [complete list](https://github.com/sitespeedio/sitespeed.io/blob/master/CHANGELOG.md). diff --git a/docs/release-notes/3.5/index.md b/docs/release-notes/3.5/index.md new file mode 100644 index 0000000000..92f6a0697a --- /dev/null +++ b/docs/release-notes/3.5/index.md @@ -0,0 +1,32 @@ +--- +layout: default +title: Sitespeed.io - Release notes 3.5 +description: New key structure for the URL:s in Graphite. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 3.5 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: New key structure for the URL:s in Graphite. +--- + +# Sitespeed.io 3.4 & 3.5 +Two kind of big releases in the same week with two important new things: + + * The Graphite keys that represents the URL:s has been reworked (thanks [@JeroenVdb](https://github.com/JeroenVdb)) and changed from the pattern *http.www.my.host._my_path_* to instead be *http.www_my_host._my_path_* that now makes it much easier to summarize stats on domain level. The bad news is that you yourself need to change/add the new keys to your graph where you show individual page metrics. + We are really sorry for that, but its a great win in the long run. And it is needed for one really cool and awesome thing that we will release sometimes next week :) If you need any help, just tweet [us](https://twitter.com/SiteSpeedio) and we will help you! + + * Custom wait scripts is now implemented for PhantomJS/SlimerJS and all the browsers. What? You can now configure when to end your test. If your browser supports the Navigation Timing API (PhantomJS 2 supports that), it will by default wait for the *window.performance.timing.loadEventEnd* event to happen + 2 seconds. The cool thing is that you now can change that and it will affect all different steps of the testing. This will help you if you have a ajax heavy site and there a specific event your are waiting on to happen and you really want to catch. The waitScript needs to return true when the wait is fulfilled, else just return false. + + We haven't updated to PhantomJS 2 yet (since it isn't fully availible as binaries on Linux). If you want to use it today accross all the tests, you can either use SlimerJS: + +~~~ bash +sitespeed.io -u http://www.example.com --headless slimerjs -b chrome +~~~ + + or install PhantomJS 2 on the side and feed it to sitespeed like this: + +~~~ bash +sitespeed.io -u http://www.example.com --phantomjsPath /path/to/phantomjs -b chrome +~~~ + +Doing like that your test will automatically wait for *loadEventEnd* + 2 seconds, and you can choose to configure yourself when to end. You can [read more](/documentation/browsers/) on what you can configure when you run a test. diff --git a/docs/release-notes/3.6.0/index.md b/docs/release-notes/3.6.0/index.md new file mode 100644 index 0000000000..4225d97380 --- /dev/null +++ b/docs/release-notes/3.6.0/index.md @@ -0,0 +1,36 @@ +--- +layout: default +title: Sitespeed.io - Release notes 3.6 +description: Say hello to scripts and custom metrics for WebPageTest. +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 3.6 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: Say hello to scripts and custom metrics for WebPageTest. +--- + +# Sitespeed.io 3.6 +We have a couple of cool things in 3.6! + +## WebPageTest +If you run WebPageTest through sitespeed.io. We now supports WebPageTest scripts (so you can login etc) and custom metrics (define your own javascript to fetch metrics). WebPageTest custom metrics are also sent to Graphite! Read more about how to run your [custom script](/documentation/webpagetest/#webpagetest-scripting) and to collect [custom metrics](/documentation/webpagetest/#custom-metrics). + +## Browsertime with Firefox 38 +We also have a new upgraded version of Browsertime that gives us a new Selenium that works with Firefox 38, has the possibility to run Chrome without sandbox mode (use the **btConfig** flag to configure specific Browsertime things). Thanks [Patrick Wieczorek](https://github.com/yesman82) for the PR! + +Browsertime also has two new connection speeds: mobile2g and mobile3gslow. The two speeds will be available in sitespeed in a while. + +## Send Google Analytics metrics to Graphite +We also have something really cool :) Inspired by Etsys [Google Analytics to Graphite](https://github.com/etsy/GoogleAnalyticsToGraphite) we added support for the Google API:s 3.0 and created a [NodeJS project](https://www.npmjs.com/package/gatographite) where you can send Google Analytics data to Graphite. You can configure what metrics to export so it is up to you what you want to do with it. We also made a [Docker container]( https://registry.hub.docker.com/u/sitespeedio/gatographite/) that makes it super easy to add on your Open Source Web Performance Dashboard. + +You can checkout our version [http://dashboard.sitespeed.io/dashboard/db/google-analytics](http://dashboard.sitespeed.io/dashboard/db/google-analytics) that fetch Google Analytics metrics once every night. + +## Graphite keys +Graphite keys now replaces pipe, comma and plus. If your URL:s has them, they will now be replaced by a underscore. This is not backward compatible but with these characters Grafana was failing for these URLs, so it's needed. Thanks [EikeDawid](https://github.com/EikeDawid) for the PR! + + +## Updated Docker containers +All [Docker containers](https://registry.hub.docker.com/repos/sitespeedio/) now run the latest version of sitespeed.io, Firefox & Chrome. Use the tagged version of the containers. + +## Reach out! +Hey we also want to reach out to the company/individual that downloaded our main sitespeed.io Docker container 20000 times. We would really love to hear how you use it, please tell us on [Twitter](https://twitter.com/sitespeedio)! diff --git a/docs/release-notes/3.7/index.md b/docs/release-notes/3.7/index.md new file mode 100644 index 0000000000..a405b2f9f8 --- /dev/null +++ b/docs/release-notes/3.7/index.md @@ -0,0 +1,35 @@ +--- +layout: default +title: Sitespeed.io - Release notes 3.7 +description: More data and metrics to Graphite please! +author: Peter Hedenskog +keywords: sitespeed.io, release, release-notes, 3.7 +nav: +image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png +twitterdescription: More data and metrics to Graphite please! +--- + +# Sitespeed.io 3.7 +Well here is 3.7, released from Mexico City :) There has already been a couple of patch releases fixing some new and old bugs. + +We will now follow the [keep a changelog](http://keepachangelog.com/) standard. + +### Added + +* We now use total amount for each collected metric. What does it mean? If we test ten pages, we will now send the summary of all metrics for these pages to Graphite. Meaning you can easily keep track of page size for all tested pages over time (yep, you can do it with a summary also but we also use this in the HTML output). Maybe this isn't super cool right now but in the future when we have implemented a user journey, it will be simple to keep track of all metrics for that journey. + +* Send all individual navigation timings to Graphite (before we only sent calculated timings). This is cool because it makes it easier for us to find performance problems in different layers over time. The keys will have *navigationtiming* in the name [#580](https://github.com/sitespeedio/sitespeed.io/issues/508) + +* Send sitespeed and browser version to Graphite. The keys in Graphite: [namespace].meta.chrome.version, [namespace].meta.firefox.version and [namespace].meta.sitespeed.version Why you ask? It is good when you step back in time to track things to know which version you where using at that time. [#703](https://github.com/sitespeedio/sitespeed.io/issues/703) + +### Changed +* We have upgraded many of the dependencies to latest versions: async, cross-spawn-async, fast-stats, fs-extra, handlebars, html-minifier, moment, phantomjs, request, winston, browsertime & xmlbuilder. + +* One optimization is that if you choose to test only one page, we don't actually start the crawler (yep we did before). This is good for [https://run.sitespeed.io](https://run.sitespeed.io) because it makes running a test for one URL faster. [#706](https://github.com/sitespeedio/sitespeed.io/issues/706) + +### Fixed +* Text fixes, thanks [Ori](@https://github.com/atdt). [#690](https://github.com/sitespeedio/sitespeed.io/issues/690) + +* New Browsertime version fixes Browser name and browser version in the HAR file. Before the HAR file has the browser name and version from the supplied User Agent. [#704](https://github.com/sitespeedio/sitespeed.io/issues/704) + +* New Browsertime also fixes a HAR defect when you tested a page multiple times (and you should do that), that made the HAR incorrect (showing too many requests). Thanks you [@joychester](https://github.com/joychester) for reporting! diff --git a/docs/sitemap.xml b/docs/sitemap.xml new file mode 100644 index 0000000000..23e7a9f49c --- /dev/null +++ b/docs/sitemap.xml @@ -0,0 +1,19 @@ +--- +--- + + + {% for page in site.pages %} + {% if page.layout != nil %} + + http://sitespeed.io{{ page.url | remove: 'index.html' }} + {% if page.url contains 'release-notes' %} + monthly + 0.7 + {% else %} + daily + 1.0 + {% endif %} + + {% endif %} + {% endfor %} + \ No newline at end of file