Current time: 12-17-2017, 02:56 AM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Revisiting browser and connectivity defaults
03-15-2013, 07:54 PM
Post: #11
RE: Revisiting browser and connectivity defaults
(03-15-2013 10:56 AM)pmeenan Wrote:  The bulk of the users doing testing are from the US and Europe and I can use different browser defaults by location and tune them for the different regions but the Dulles default is the main one I want to make as neutral as possible since the vast majority of users just drop in an URL and hit test.

I don't know how many people test from multiple locations but I wonder if having different defaults for different locations is likely to create more issues than it solves?

Andy

Using WebPageTest - http://usingwpt.com/
Visit this user's website Find all posts by this user
Quote this message in a reply
03-15-2013, 10:01 PM (This post was last modified: 03-15-2013 10:03 PM by vovone.)
Post: #12
RE: Revisiting browser and connectivity defaults
(03-15-2013 10:56 AM)pmeenan Wrote:  The more data I look at the more comfortable I get with switching to the 5Mbps cable profile as well though I still worry for the sites that do no testing at lower bandwidths and shove 4+MB of data down to users on each page view....

Maybe it's an idea to add a line or table to the final results page with a calculated (rough) estimated load time for the other line speeds. I'm sure you have enough data on the line speeds to make some pretty close estimate calculations. Even when people just tend to test only on speed, the default or not, you still make them aware in the overview of the (estimated) other line speed load time.

Adding 'warning colors' for page load times higher than whatever currently 'the golden rule' is, might get that 4+MB warning and awareness job done better. I know from my experience with customers, that most people are very motivated to get most of those colors on the WPT page as green as possible, even in the EU, where F->A doesn't tell them that much (We're more 1->10 kinda people Wink )
Find all posts by this user
Quote this message in a reply
03-15-2013, 10:19 PM
Post: #13
RE: Revisiting browser and connectivity defaults
I agree about the default's being cable & maybe for the browser you could set a cookie to the last used. I would be intrigued to see some mobile speed settings on there maybe 3G / 4G setting's would be useful to some.

-Sean
Find all posts by this user
Quote this message in a reply
03-16-2013, 12:01 AM
Post: #14
RE: Revisiting browser and connectivity defaults
We should look into the native broadband speed setting some more. Xfinity is talking about doubling their speeds. So fiber/cable-modem is getting even faster. Probably due to improvements and price drops in fiber transceivers, as well as networking backbone equipment moving to 10gpbs and in some cases 100gbps. People are also using triple-play (voice, video & data) more often. They are also using their Internet connection for HD video now. I guess that's a whole other beast though.
Find all posts by this user
Quote this message in a reply
03-16-2013, 12:28 AM (This post was last modified: 03-16-2013 12:30 AM by jklein.)
Post: #15
RE: Revisiting browser and connectivity defaults
I'd like to see the default connectivity move to cable as well, and I'm pretty neutral as far as the IE 9 vs. Chrome debate goes. I certainly think that it should be one of those two instead of IE 8.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-16-2013, 04:44 AM
Post: #16
RE: Revisiting browser and connectivity defaults
ok, I haven't seen any opinions or data opposing it so I'll be switching the defaults to IE 9 and Cable over the weekend (just upgrading some VM's right now so there is enough IE 9 capacity). Thanks everyone.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-16-2013, 03:12 PM
Post: #17
RE: Revisiting browser and connectivity defaults
(03-16-2013 04:44 AM)pmeenan Wrote:  ok, I haven't seen any opinions or data opposing it so I'll be switching the defaults to IE 9 and Cable over the weekend (just upgrading some VM's right now so there is enough IE 9 capacity). Thanks everyone.

Quick question, I've been running tests pointint to stage.mint.com for a couple of weeks now and it seems that today around 5pm Pacific time the outcome of the test changed, apparently some contents I preload from the login page are getting reloaded (not cached) on the page after login and the second refresh seem also to start from scratch.
Not sure how it would be related to this change, any idea?

If you dont have much time to spare, no worry i'll try to look into it.

Thanks
Find all posts by this user
Quote this message in a reply
03-17-2013, 06:24 AM
Post: #18
RE: Revisiting browser and connectivity defaults
Perhaps I am not using the REST Api correctly, but it appears that the speed variation that we had it coded to (in case the defaults changed) has been overwritten. It looks like all of our pages load MUCH faster than previous runs with this morning runs.

This TERRIBLE page here:
http://www.webpagetest.org/result/130315_8W_M0R/
Normally takes around 13 seconds to completely load the page with 2.* mb of data.

With this morning's run it was less than 4 seconds.
http://www.webpagetest.org/result/130316_Y0_FAV/

While we will likely revisit the params we're using down the road, the unexpected change in speeds will throw off our data. Which is why we used the hard coded values on the API rather than depend on defaults.

I'll look into this more tonight when I get a chance to see if something is not set right for our calls to your service.

FWIW I agree with the settings you are defaulting to, though I might put Chrome ahead of IE9 just because of the number of webkit related versions. Well, at least for our customers.

Thank you,
Mike
Find all posts by this user
Quote this message in a reply
03-17-2013, 06:35 AM
Post: #19
RE: Revisiting browser and connectivity defaults
(03-16-2013 03:12 PM)sbardoux Wrote:  Quick question, I've been running tests pointint to stage.mint.com for a couple of weeks now and it seems that today around 5pm Pacific time the outcome of the test changed, apparently some contents I preload from the login page are getting reloaded (not cached) on the page after login and the second refresh seem also to start from scratch.
Not sure how it would be related to this change, any idea?

If you dont have much time to spare, no worry i'll try to look into it.

Thanks

Do you have before and after test URLs? It's easy enough to just run a test on DSL with IE8 and see if the behavior reverts. My guess is that it's more tied to the browser than the connectivity speed.
Visit this user's website Find all posts by this user
Quote this message in a reply
03-17-2013, 06:39 AM
Post: #20
RE: Revisiting browser and connectivity defaults
(03-17-2013 06:24 AM)mle_ii Wrote:  Perhaps I am not using the REST Api correctly, but it appears that the speed variation that we had it coded to (in case the defaults changed) has been overwritten. It looks like all of our pages load MUCH faster than previous runs with this morning runs.

This TERRIBLE page here:
http://www.webpagetest.org/result/130315_8W_M0R/
Normally takes around 13 seconds to completely load the page with 2.* mb of data.

With this morning's run it was less than 4 seconds.
http://www.webpagetest.org/result/130316_Y0_FAV/

While we will likely revisit the params we're using down the road, the unexpected change in speeds will throw off our data. Which is why we used the hard coded values on the API rather than depend on defaults.

I'll look into this more tonight when I get a chance to see if something is not set right for our calls to your service.

FWIW I agree with the settings you are defaulting to, though I might put Chrome ahead of IE9 just because of the number of webkit related versions. Well, at least for our customers.

Thank you,
Mike

Looks like your query parameters are fine. I'm checking to see if I had a tester that didn't traffic shape correctly (the latency numbers look like there was no traffic shaping whatsoever). I re-ran the test it it came out as expected: http://www.webpagetest.org/result/130316_M0_KW2/ so I'm hoping it's just a specific tester with an issue.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)