Performance, like any other feature, doesn’t just “happen”; it has to be designed and built. To do performance well, you have to think about it, study it, write extra code for it, test it, and support it.
Since you can’t know how your application is going to perform in production, you need to write your application so that it’s easy to fix performance in production.
Slides from Nic Jansma on measuring the performance of single page applications:
This is an area that I’ll be spending some time on in 2016.
Back in August Digiday wrote about how GQ cut its webpage load time by 80 percent ( emphasis mine ):
Before GQ relaunched its website July 1, pages took a painfully long seven seconds to load. With GQ’s mobile visitor at 53 percent of its traffic and growing, that was an unacceptable lag.
Always good to hear about sites doing more to improve the performance of their site ( mobile or not ). Unfortunately the only data point they provided was that the page took “seven seconds to load”. It isn’t clear what they were measuring that took seven seconds, or under what conditions the test was run.
So I went to webpagetest.org and ran my own tests:
- Chrome, Cable ( 5Mbps/1Mbps 28ms RTT ) from Dulles, VA: http://www.webpagetest.org/result/151019_PP_R1Q/
- Chrome ( mobile emu ), 3GSlow ( 780Kpbs/330Kbps 200ms RTT ) from Dulles, VA: http://www.webpagetest.org/result/151019_FQ_RJ5/
The mobile site is definitely lighter than the desktop one. Fully loaded desktop first view is 9.5MB and mobile is 5.1MB. Unfortunately under these test conditions the first view mobile site still took 61.6 seconds to fully load.
When you control the server and client sides of an application you can come up with some impressive performance hacks. Facebook’s changes to preview photos is a good example of that:
There are a few tables within the JPEG header, which accounts for its size. The question then became: Would it be possible to generate a fixed header that could be stored on client and therefore not need to be transmitted? In that scenario, only the payload would need to be sent, which would make this the winning format. The investigation began.
For some slow cases they were able to improve page load performance by 30 percent.
Soasta on how they deal with real user monitoring in AngularJS:
First, we now listen for AngularJS routing events, such as $routeChangeStart. Once we see that the visitor is about to view new content, we start listening in preparation for gathering performance metrics for the soft navigation.
Second, and most importantly, when the page is first loading, and when a soft navigation starts, we begin monitoring the HTML document for any new downloadable resources that get inserted. We do this via a MutationObserver.
Real user monitoring techniques for single page apps are becoming a big deal, and don’t easily have a one size fits all solution.
MapLatency.com: global checks for ping, dns, page load, and HTTP GET.
Addy Osmani on CSS Performance Tooling.
Wondering what CSS properties trigger paint, layout, and composite? Then CSS Triggers is for you.
stats.js is a nifty little performance monitor:
This class provides a simple info box that will help you monitor your code performance.
– FPS Frames rendered in the last second. The higher the number the better.
– MS Milliseconds needed to render a frame. The lower the number the better.
– MB MBytes of allocated memory. (Run Chrome with –enable-precise-memory-info)
The FPS monitor looks like this: