Patrick Meenan mentioned first paint time improvements in Chrome 41. I noticed a ~25% improvement in the first view SpeedIndex times for one of our tests. It was easy to spot when the auto update from Chrome 40 to 41 happened:
I compared the individual tests before and after the update and this really is all about first paint times. The total time for the page to be visually complete was roughly the same.
Two weeks ago I mentioned dnsperf.com. After that I reached out to @jimaek about adding WordPress.com to the list of measured providers.
It has been super exciting to see WordPress.com DNS performance rank #3 worldwide:
We are behind second place EdgeCast by just 0.66ms.
Serious kudos to our systems and network operations teams on including DNS as part of our Anycast network, which made this level of performance possible.
DNSPerf.com tracks the response time for various providers.
You can drill down to see the response time history for each provider as well. To pick one example: namecheap.
From a presentation on the internals of the H2O web server ( something I had previously mentioned ) by Kazuho Oku, slide 21 ( emphasis is mine ):
Characteristics of a fast program:
1. Executes less instructions
– speed is a result of simplicity, not complexity
Getting the same result with less work and less complexity is a good thing.
Richard Hipp on improving SQLite performance, 50% faster than 3.7.17:
This is 50% faster at the low-level grunt work of moving bits on and off disk and search b-trees. We have achieved this by incorporating hundreds of micro-optimizations. Each micro-optimization might improve the performance by as little as 0.05%. If we get one that improves performance by 0.25%, that is considered a huge win. Each of these optimizations is unmeasurable on a real-world system (we have to use cachegrind to get repeatable run-times) but if you do enough of them, they add up.
More often than not getting a big improvement in performance is about doing lots of little things.
Xiao Yu mentioned perfmap at work last week:
A bookmarklet to create a front-end performance heatmap of resources loaded in the browser using the Resource Timing API. A browser with support for the Resource Timing API is required.
It gives you a quick way to see how far into the page load images on the page finished loading.
If you are going to use this regularly I’d recommend editing the bookmarklet to load perfmap.js from a trusted source that you control.
I ran across a jsperf.com test of a for loop vs foreach and I was surprised at the difference when running the test in Chrome 38:
The for loop consistently came out over 40 times faster than the foreach.
“Project Express” from Hibernia Networks is a new trans-Atlantic fiber connection from New York to London. It was started in 2011 but isn’t expected to be completed until later in 2014. From a 2012 Bloomberg news article about the project:
Project Express will be the fastest cable across the Atlantic, reducing the time it takes data to travel round-trip between New York and London to 59.6 milliseconds from the current top speed of 64.8 milliseconds
The cost for this new, shorter, fiber line is reportedly over $300M. A big price tag for a 5.2 millisecond reduction in round-trip time.
It should come as no surprise then that the main customer base for this new connection is high speed trading companies.
Steve Souders takeaway #1 after trying to figure out unexpected caching behavior in Chrome ( emphasis is mine ):
Remember that Chrome may do DNS prefetch, TCP pre-connect, and even prerender the entire page based on the confidences in chrome://predictors.
Apparently this isn’t new information, it was mentioned by Ilya Grigorik in High Performance Networking in Google Chrome. But if Steve Souders didn’t know about it already then I expect that it isn’t widely known.
Looking over the chrome://predictors/ results in my browser it is about what I’d expect. One thing that would be helpful is the ability to sort by individual columns. I’m most interested in which pages Chrome is mostly likely to attempt to prerender.
How we code interactions on the web has changed significantly with mobile touch devices. It isn’t just about hover, it is also about timing:
By default, if you tap on a touchscreen it takes about 300ms before a click event fires. It’s possible to remove this delay, but it’s complicated.
– via Suppressing the 300ms click delay – QuirksBlog.
Some browsers allow pages to turn off this delay when you have
width=device-width set. Unfortunately mobile Safari isn’t one of those.