Google Speed Experiment Reference

A common data point I see brought in web performance discussions is a reference to a test Google ran to test the impact of slower search results on the number of searches a user performs. I found the original blog post at Speed Matters:

Our experiments demonstrate that slowing down the search results page by 100 to 400 milliseconds has a measurable impact on the number of searches per user of -0.2% to -0.6% (averaged over four or six weeks depending on the experiment).

The impact extends beyond the initial test period:

Users exposed to the 400 ms delay for six weeks did 0.21% fewer searches on average during the five week period after we stopped injecting the delay.

If you are going to reference this test and the corresponding data, please link back to original Google blog post. Hopefully that will save others the time of having to hunt down the original information.

Google Project Fi, @gmail.com Only

The “network of networks” approach of Google Project Fi is an interesting move. I like the idea of being able to leverage multiple networks, in this case Sprint, T-Mobile, and wifi connections.

Any chance Google Fiber cities will see Google wifi access points that specifically target Project Fi users?

I clicked on “request invite”, which provided this disappointing response:

google-fi-gmail

For now, Project Fi is available only for accounts with an @gmail.com address

Just in case you weren’t sure that non-@gmail.com accounts are second class Google citizens.

Combine this with the pain Slack is having with multiple user accounts and I wonder if user management is the next level up on scaling challenges.

Google PageSpeed Insights: Chrome 27 and iOS 6 Safari

I’ve been using Google PageSpeed Insights quite a bit recently. There isn’t much information on how exactly the tests are run, which can make it hard to reproduce the results. Then I noticed the user agent strings coming from PageSpeed Insights ( emphasis mine ):

Desktop

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko; Google Page Speed Insights) Chrome/27.0.1453 Safari/537.36

Mobile

Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko; Google Page Speed Insights) Version/6.0 Mobile/10A525 Safari/8536.25

The only difference between these and normal user agent strings is the ; Google Page Speed Insights.

If these user agent strings are what they claim to be, the Insight desktop is using Chrome 27 released in May 2013 and Insight mobile is using Safari from iOS 6 released in Nov 2012.

This explains some of the inconsistency I noticed in comparing PageSpeed Insights results with Chrome mobile device emulation.

GMT vs UTC

Some times Google will try to just tell you the answer to your search query. For example, GMT vs. UTC, includes this at the top of the results page:

gmt-vs-utc-google

My understanding is that there is a small difference, fraction of a second. For my non-computing needs that difference is small enough to not matter.

New Google Contacts

The new Google Contacts management features look nice. Unfortunately the part with the biggest impact for me came at the very end:

P.S. The new Contacts isn’t yet available for Google Apps customers, but we’re working on it.

Not exactly the first time that Google Apps users have been left out of new features. I’m starting to regret running my main account though Google Apps.

Google Giving Weight to HTTPS in Search Results

https-all-the-things

Maybe not everything, but certainly more than we are doing now.

So how do you encourage more sites to use HTTPS? Well, if you are Google, you tweak the SEO black box:

we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content — while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

From HTTPS as a ranking signal on the Google Webmaster Central Blog.

The call to have more sites use HTTPS has been out for some time. It is hard to be motivated enough to over come the technical and financial hurdles to make the move ( and for some sites those hurdles are non-trivial ). The SEO approach that Google is taking is the equivalent of hitting sites in the wallet ( in some cases that might be the literal result ). When the possibility of loosing money is involved then it is easier to get people’s attention.

This might be the single best use of the crazy Google SEO situation I’ve ever seen.

Earlier this summer Automattic talked about working towards providing all *.wordpress.com sites with HTTPS by the end of 2014. This is something that I’m really excited to see happen.

If you still aren’t supporting HTTPS for your site, I’d encourage you to map out a plan to get there. Tim Bray posted a simple outline of the why and how of switching to HTTPS. If you are looking for a more technical view of how HTTPS works check out the TLS chapter of “High Performance Browser Networking”, which is free to read online.

Awkward Moment For Google And Feedly

The Google Cloud Platform blog recently had a rather awkward moment posting about the success of Feedly, emphasis is mine:

In the middle of last year, our servers were overwhelmed with hundreds of thousands of new signups, and we experienced our first service outage. The first thing we did was move all of our static content to App Engine. Within an hour we were up and running again with 10 times the capacity we had before. This turned out to be a good thing – we added millions more users over the next few months and more than doubled in size.

I seem to recall Google telling millions of users to pack up their stuff and leave around the middle of last year. Feels strange to see Google excited to brag about their ability to send millions of users to a competitor. At least they used to be competitors, before Google decided to get out of the reader space.

Read Access on Google Servers with XXE

Detectify explains how they gained read access to production servers at Google:

One system caught our eyes. The Google Toolbar button gallery. We looked at each other and jokingly said “this looks vuln!”, not knowing how right we were.

googlexxe_passwd_blurred_873

They were able to leverage XML External Entity ( XXE ) processing to read local files on Google’s production servers. If you haven’t read up on XXE go watch Mike Adams talk at WordCamp SF 2013, the video is only 30 minutes.

Be very careful when processing XML, it can come back to bite you in very bad ways.