Links tagged: performance
The Simplest Way to Load CSS Asynchronously | Filament Group, Inc.
One of the most impactful things we can do to improve page performance and resilience is to load CSS in a way that does not delay page rendering. That’s because by default, browsers will load external CSS synchronously—halting all page rendering while the CSS is downloaded and parsed—both of which incur potential delays. Of course, at least a portion of a site’s CSS should be loaded before the page should be allowed to start rendering, and to get that initial CSS to the browser immediately, we recommend inlining (or HTTP2 server-pushing) the CSS. For sites with a small amount of overall, that alone might be enough, but if the CSS is large (say, bigger than 15 to 20kb), it can help performance to split it up by priority. Once split, less-critical CSS should be loaded in the background—AKA asynchronously. In this post, I aim to describe up our preferred way to do that these days, which has actually been around for years.
July 25th 2019
Create performance budgets and set alerts | SpeedCurve Support
How to create and edit performance budgets for your LUX and Synthetic metrics in your Favorites dashboards
July 11th 2019
leeoniya/dropcss: A simple, thorough and fast unused-CSS cleaner
DropCSS is an unused CSS cleaner; it takes your HTML and CSS as input and returns only the used CSS as output.
March 25th 2019
Chromium Blog: Chrome Lite Pages - For a faster, leaner loading experience
Chrome on Android’s Data Saver feature helps by automatically optimizing web pages to make them load faster. When users are facing network or data constraints, Data Saver may reduce data use by up to 90% and load pages two times faster, and by making pages load faster, a larger fraction of pages actually finish loading on slow networks. Now, we are securely extending performance improvements beyond HTTP pages to HTTPS pages and providing direct feedback to the developers who want it.
March 20th 2019
How browsers schedule and execute scripts can impact the performance of web pages. While techniques like <script defer>, <link rel=preload> (and others) influence script loading, knowing how browsers interpret them can also be helpful. Thanks to Kouhei Ueno, we now have an up to date summary of script scheduling in Chrome.
February 20th 2019
React 16.x Roadmap – React Blog
You might have heard about features like “Hooks”, “Suspense”, and “Concurrent Rendering” in the previous blog posts and talks. In this post, we’ll look at how they fit together and the expected timeline for their availability in a stable release of React.
February 12th 2019
February 6th 2019
Why Bandwidth Still Matters - DEV Community 👩💻👨💻
I remember going to a local mall in New Jersey and walking into a T-Mobile store back in 2014. I had just moved to the US the previous year, and I was just about sick of using Google Voice to keep in touch with people. Opening my laptop just to send a text or make a call wasn't very convenient. Unfortunately, it was all I could afford to do because I didn't even have a working phone at that time. I was a recent graduate and very unemployed. So I said to myself that the minute I get hired for a job I was going to get myself a new phone.
January 1st 2019
November 27th 2017
Can You Afford It?: Real-world Web Performance Budgets – Infrequently Noted
performance budgets are an essential but under-appreciated part of product success and team health. Most partners we work with are not aware of the real-world operating environment and make inappropriate technology choices as a result. We set a budget in *time of <= 5 seconds first-load Time-to-Interactive and <= 2s for subsequent loads. We constrain ourselves to a real-world baseline device + network configuration to measure progress. The default global baseline is a ~$200 Android device on a 400Kbps link with a 400ms round-trip-time (“RTT”). This translates into a budget of ~150-170KB of critical-path resources, depending on composition — the more JS you include, the smaller the bundle must be.*
October 23rd 2017
The State of the Web – Karolina Szczur – Medium
The Internet is growing exponentially, and so is the Web platform we create. Often though we fail to reflect on the greater picture of connectivity and contexts the audience of our work might find themselves in. Even a short glance at the state of the World Wide Web shows that we haven’t been building with empathy, situation variability awareness, let alone performance in mind.
September 25th 2017
Progressive Image Rendering
Stephan Lavavej has a great page outlining the difference between fancy interlacing and plain old progressive rendering:
There are four ways to transmit an image over the Internet. Over a fast connection there won't be any apparent difference, but over a modem connection the difference is stunningly obvious. Choosing the right way can make your connection seem much faster than it really is.
Wait until every bit of image data has been sucked through the modem before displaying the whole image. So blindingly dumb that not even Internet Explorer does it.
Display image data as it is received, resulting in a top-down filling in of the image. One variant -- the one that everyone has seen -- of JPEG does this. This is noninterlaced display, and both GIF and PNG are capable of it as well. Non-interlaced images are smaller than interlaced images.
Use a one-dimensional interlacing scheme. This is how GIF interlacing works. Every eighth horizontal line is transmitted in the first "pass", filling up the dimensions of the image in 1/8th of the time that the entire image will take to download. The next pass transmits every fourth line, making the image less distorted. The next pass transmits every second line, making the image even less distorted, and the fourth and final pass transmits the remaining lines.
Use a two-dimensional interlacing scheme. This is how PNG interlacing works. Instead of four passes through the image, PNG makes seven passes. In 1/64 of the time that the whole image will take to display, one pass is already completed, showing the image in a very rough manner. Successive passes fill in more information, never distorting the pixels by more than a factor of two to one.
Here's a demo of simple progressive as-received rendering:
And here's a demo of the superior PNG style two-dimensional interlaced rendering:
You don't get this for free, of course -- turning this feature on adds about 20% to the size of PNG images, and about 10% to the size of JPEG and GIF images. Whether this improved rendering behavior is worth the bandwidth cost I leave as an exercise to the reader.
I am not aware of any browsers that actually bilinearly interpolate the low-resolution incremental images, as shown in the sample screenshots on Stefan's page. But that would be really cool! Why doesn't Firefox add this?
This Just In: Internet Makes Books Obsolete
UI Follies, Volume III
Written by Jeff Atwood
Indoor enthusiast. Co-founder of Stack Overflow and Discourse. Disclaimer: I have no idea what I'm talking about. Find me here: http://twitter.com/codinghorror
August 7th 2017
ImageOptim — better Save for Web
Removes bloated metadata. Saves disk space & bandwidth by compressing images without losing quality.
August 7th 2017
Trick users into thinking your site's faster than it is | Creative Bloq
Before getting to the psychological part of performance optimisation, let's answer one question: what is web performance? For the majority of frontend developers, the answer would cover things like page response time, speed of animations, load times.
July 19th 2017
Secrets of High Performing Teams: Science Edition • Jez Humble - YouTube
This presentation was recorded at GOTO Copenhagen 2016
July 7th 2017
Optimising the front end for the browser
Recently my whole team got a chance to spend some time spiking out our proposed upgrade to our codebase, potentially using React. This really got me thinking about how we should build our front end. Pretty quickly I realised that the browser would be a large factor in our approach and equally large bottleneck in our knowledge.
June 28th 2017
The State of Online Retail Performance
While almost half of all consumers browse via their
phones, only 1 in 5 complete transactions on mobile
• Optimal load times for peak conversions ranged from
1.8 to 2.7 seconds across device types (page 6).
• Just a 100-millisecond delay in load time hurt
conversion rates by up to 7% (page 7).
• Bounce rates were highest among mobile shoppers and
lowest among those using tablets (page 9).
• Optimal load times for lowest bounce rates ranged
from 700ms to 1.2s across all device types (page 10).
• A two-second delay in load time hurt bounce rates
by up to 103% (page 10).
• Pages with the lowest bounce rates had start render
times ranging from 0.9 to 1.5 seconds (page 12).
• A two-second delay correlated with up to a 51%
decrease in session length (page 14).
June 28th 2017
Performance Tooling Today
Perf-tooling is a collection of powerful resources which will help you to improve your workflow and to deliver better and faster websites.
May 18th 2017
Aerotwist - Don't Guess it, Test it!
I recently was invited to give a talk at Spotify in Stockholm, Sweden to the local developer community. My talk centered around performance, since that’s the topic that fills my days at Google, specifically site and application performance.
May 15th 2017
WebPageTest is an incredibly useful resource for any web developer, but the information it provides becomes much more powerful when monitored regularly, rather than at isolated events. SpeedTracker runs on top of WebPageTest and makes periodic performance tests on your website and shows a visualisation of how the various performance metrics evolve over time.
May 9th 2017
Tarantool - Get your data in RAM. Get compute close to data. Enjoy the performance.
Get your data in RAM. Get compute close to data. Enjoy the performance.
May 4th 2017