Possible changes to grading
|
06-25-2011, 12:19 PM
Post: #11
|
|||
|
|||
RE: Possible changes to grading
Given W3TC, Supercache and a lot of other options your typical wordpress user has a lot of tools at their disposal, maybe with some questions but even just getting the basics set up can be a huge win :-) Given that NOTHING can load until the first byte comes back it's absolutely critical - the key is figuring out where to set the thresholds and still be reasonable. At the end of the day, it doesn't matter if it's database or back-end API calls, if it's slow it's slow.
|
|||
06-27-2011, 11:29 PM
Post: #12
|
|||
|
|||
RE: Possible changes to grading
Totally agree on first byte time - it's so critical that if it's not under your control you should go change that to make sure that it is :-). It would definitely be nice to have a visual indication if you are having TTFB issues.
|
|||
06-28-2011, 01:04 AM
Post: #13
|
|||
|
|||
RE: Possible changes to grading
The CDN change is now live and I'm working on the first byte logic (at which point the JS/CSS will be demoted). Right now I'm thinking that the grading for the first byte will look something like this:
Base time = 3 * rtt to server (allow for DNS + socket connect + http request) If TTFB <= base + 100ms then it get's an A and then deduct a grade for every 100ms beyond that SSL would also be accounted for and the extra round trips would be factored in for a https request. That way the connection latency will not be a factor and it will purely be a measurement of back-end processing time (<= 100ms = really good). It will also penalize for redirects. The end result for the default DSL connection profile would be: TTFB <= 250ms = A 250ms - 350ms = B 350ms - 450ms = C 450ms - 550ms = D > 550ms = F The actual times will be slightly more generous because these times don't include the additional latency to get to the actual server which will be included in the actual grading (using the socket connect time). |
|||
06-28-2011, 04:53 AM
Post: #14
|
|||
|
|||
RE: Possible changes to grading
ok, the changes are live (and retroactive to existing tests). Feedback appreciated.
|
|||
06-28-2011, 06:20 PM
Post: #15
|
|||
|
|||
RE: Possible changes to grading
Boo I have another B to fix now >.<
Which is annoying as my CMS records the time it takes to generate a page, and that records them at 70ms. Now I need to find out where the other 140ms are coming from. Least theres no more big red F staring me in the face! |
|||
06-28-2011, 09:20 PM
Post: #16
|
|||
|
|||
RE: Possible changes to grading
@Kye, do you have a test result? I just want to make sure the math on my side is correct since it's pretty new.
|
|||
06-28-2011, 09:55 PM
Post: #17
|
|||
|
|||
RE: Possible changes to grading
http://www.webpagetest.org/result/110628_5K_Y5JR/ -B
http://www.webpagetest.org/result/110628_JQ_Y6BH/ -D http://www.webpagetest.org/result/110628_2D_Y6HZ/ -B Trouble with FBT is it varies a log with each and every request. |
|||
09-16-2011, 08:32 PM
Post: #18
|
|||
|
|||
RE: Possible changes to grading
(06-24-2011 02:34 AM)LeptienM Wrote: Two things I would like to add Re: JS/CSS: And one more thing to add: See Slides 26-31 and 59 on this deck: https://docs.google.com/present/view?id=...52c9g976c4 So I still think, a grade on Concatenation of JS/CSS in the HEAD would be relevant. :-) |
|||
09-17-2011, 12:48 AM
Post: #19
|
|||
|
|||
RE: Possible changes to grading
Can you make the doc public for reading (or share the key points on the slides)?
I'm not arguing that it's not important, just that it's not universally true that combining resources will be faster. At the end of the day I hope that people pay more attention to the actual waterfalls than the grades themselves. |
|||
09-19-2011, 02:06 AM
Post: #20
|
|||
|
|||
RE: Possible changes to grading
(09-17-2011 12:48 AM)pmeenan Wrote: Can you make the doc public for reading (or share the key points on the slides)? Whoops... This Link should work. http://bit.ly/hKXBKB Got it from Souders Twitter Stream. Basically this guy has tested an artificial test page: "A single 21 KB HTML document 26 image files totaling 1,789 KB Five Javascript files totaling 554 KB Eight style sheets totaling 43 KB Total page weight of 2,407 KB In other words, results not typical" and then has measured the impact of 14 of the most common best practices, each on its own. Each practice was then put on a coordinate system with engineering effort / performance gain being the axis. And Concatenating JS and CSS pretty much got the biggest bang for your bucks. In this scenario. He didn't write, though, what kind of network he tested this on. Best wishes, Markus |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)