| Javascript:|58227 bytes
|
| connection rate 56K|20.68 seconds download time
|
| connection rate ISDN 128K|6.33 seconds||
|
| + |
| +In 2010 (May 31), this becomes |
| +||Object type| Size (bytes)|Download @ 56K (seconds)|Download @ T1 (seconds) |
| +HTML:| 32249| 6.63 | 0.37 |
| +HTML Images:| 22854 | 7.35| 2.92 |
| +CSS Images:| 38629 | 8.50| 1.00 |
| +Total Images:| 61483 | 15.85| 3.92 |
| +Javascript:| 71186| 15.19| 1.38 |
| +CSS:| 1096 | 0.42 | 0.21|| |
| + |
| +with some further qualitative analysis : there are green points such as use of Gzip, only one HTML and one CSS file, but too many images (18), and too much Javascript (71k). Of course, nobody today still uses 56k links, but still at T1 speed the calculated speed is about 6 seconds (Yes, I too get more than 9 by simply adding, go figure). So a remommendation would be to use Gzip also for javascript packages. Also adding width and height attributes to all images should make rendering faster. |
|
|
| {maketoc include="all"}
|
|
|
| ! What could be done?
|
| !! eliminate extra size
|
| -* Jakob Nielsen is positive that we should achieve sub-8 seconds load time for the users to enjoy navigating our site. Another reason for speed optimisation is reducing the load for sites with heavy traffic. In the above report, it is obviously a rather impossible task to scale down 120 kilobyte (20 kilobyte of CSS are omitted by the analysis) to 30, necessary for sub-8 load time, but we might want to get closer to that usability ideal. (Side note: at that moment bitweaver was using Ajax for some packages - 45k!)
|
| +* Jakob Nielsen is positive that we should achieve sub-8 seconds load time for the users to enjoy navigating our site. Another reason for speed optimisation is reducing the load for sites with heavy traffic. In the above report, it is obviously a rather impossible task to scale down 120 kilobyte (20 kilobyte of CSS are omitted by the analysis) to 30, necessary for sub-8 load time, but we might want to get closer to that usability ideal. |
|
|
| !! eliminate extra HTTP requests
|
| * Reading: ''Modem connections (56Kbps or less) are corrected by a packet loss factor of 0.7. All download times include delays due to round-trip latency with an average of 0.2 seconds per object. With 31 total objects for this page, that computes to a total lag time due to latency of 6.2 seconds.'' In the above example, we are loosing more then 6 seconds just for HTTP requests, so there's no chance for sub8 response :(
|