use graphs, move results to appendix

rfc-160-using-es6-modules-in-govuk_publishing_components.md

@@ -180,35 +180,36 @@ I tested performance on three types of pages:
 
 What I wanted to test was the difference in how long it takes the page to load on 'normal' and 'slow' internet connections and also the difference in total size between the seperate components and all components in one application.js file. I also deliberately chose a component with one of the largest javascript file sizes in govuk_publishing_components to take into an account a 'worst case scenario'.
 
-### Results
+The time to load pages test was carried out by comparing the pages loading on a throttled "slow 3G" network in Chrome to a non throttled network, with caching disabled to simulate the first time a user visits a page (or a user visits a page of an application that has been recently redeployed).
 
+### Summary of Results
 
+![](rfc-160/components-size.png)
 
-##### Notes
+![](rfc-160/connection-view.png)
 
-application.js (of collections) still includes Javascript for different pages than the user is actually on. In collections there are three additional modules for specific pages (which will not be used on every page). If we included the javascript only on the specific pages that needed it, this would make application.js a smaller size.
-
-#### Time to load pages
-
-This test was carried out by comparing the pages loading on a throttled "slow 3G" network in Chrome to a non throttled network, with caching disabled to simulate the first time a user visits a page (or a user visits a page of an application that has been recently redeployed).
+##### Note about file sizes
 
+application.js (of collections) still includes Javascript for different pages than the user is actually on. In collections there are three additional modules for specific pages (which will not be used on every page). If we included the javascript only on the specific pages that needed it, this would make application.js a smaller size. See the appendix for a breakdown of sizes per componenta and highlighting of which components would be impacted by this change.
 
 ### Conclusions
 
 Switching to individually loaded components would result in decreased file sizes for pages that use a subset of the components. This would be benefitial for users who have slow connections or low data limits. It also results in faster load times on slow connections for pages that use some or no components. For pages that use a lot of components, the time to load a page is not significantly impacted due to GOV.UK using HTTP 3.0. This means that even though a page might request more individual files, they can be loaded simultaneously.
 
 The worst performing example above for the new delivery mechanism of Javascript is "a page which has all components". It has a higher file size than the current delivery mechanism and a time to load that's similar to the current delivery mechanism (on both speeds of connection). What I did not know before running the tests was what was the average number of components using Javascript per partial was on GOV.UK. After seeing the results of the tests, I decided to determine what this was. A summary of the results follows, but I have included the full results as part of the RFC:
 
-| Application | Avg. No. of Javascript Components Per Partial with Javascript Components | % of partials that have any components using Javascript |
+![](rfc-160/percentage-partials.png)
+
+| Application | Avg. No. of Javascript Components Per Partial with Javascript Components |
 | ----------- | ----------- | ----------- | 
-| collections | 2 | 13 |
-| email-alert-frontend | 1 | 67 |
-| feedback | 2 | 29 |
-| finder-frontend | 2 | 25 |
-| frontend | 2 | 53 |
-| government-frontend | 2 | 46 |
-| license-finder | 1 | 33 |
-| smart-answers | 1 | 28 |
+| collections | 2 |
+| email-alert-frontend | 1 |
+| feedback | 2 |
+| finder-frontend | 2 |
+| frontend | 2 |
+| government-frontend | 2 |
+| license-finder | 1 |
+| smart-answers | 1 |
 
 To get these results, I added a [new function to the components audit in govuk_publishing_components](https://github.com/alphagov/govuk_publishing_components/compare/workout-avg-components-using-js-per-partial-on-all-apps?expand=1#diff-a89ea70a9fdb9795d633f2ae337de6aed64cfef61cdc5c5f8c91eefefea88eaaR288). A caveat with this method is that generally an entire page will be compromised of several partials. The partials that make up pages could also have the same Javascript utilising components, meaning the javascript wouldn't need to be included multiple times in the combined page. Based on the low average number of javascript components per partial and the small percentage of partials that have any javascript components at all, it is safe to say that it is likely that the majority of pages on GOV.UK have a smaller number of components than the "a page which has all components" test above. Therefore we can say that "a page which has all components" is an edge case and serves more as an example of a worst cast scenario than a real example of a page. We can also say that most pages will benefit sigificantly from a lower script size and faster load times on slower connections.
 
@@ -332,7 +333,7 @@ For a page with all components
 
 ^: file size that will be smaller with the upcoming changes to govuk-frontend
 
-####
+#### Page Load Test
 
 ##### Current Delivery Mechanism of Javascript