はてなブックマーク

You've optimized every aspect of your page—it's fast, and you can prove it. However, for better or worse, you also need to include a resource that you do not control (e.g. owned by a different subteam or a third-party), and by doing so you lose most, if not all, guarantees about the runtime performance of your page - e.g. an included script resource can execute any code it wants, at any point in y

As anyone and everyone in the web performance community will tell you, the size of the average page is continuously getting bigger: more JavaScript, more image and video bytes, growing use of web fonts, and so on. In fact, as of December 2015, the HTTP Archive shows that the average desktop site weighs in at 2227KB, and mobile is up to 1253KB. Except, what is an "average page", exactly? Intuitivel

Great applications do not lose user's progress and app state. They automatically save the necessary data without interrupting the user and transparently restore themselves as and when necessary - e.g. after coming back from a background state or an unexpected shutdown. Unfortunately, many web applications get this wrong because they fail to account for the mobile lifecycle: they're listening for t

The "simple" act of initiating an HTTP request can incur many roundtrips before the actual request bytes are routed to the server: the browser may have to resolve the DNS name, perform the TCP handshake, and negotiate the TLS tunnel if a secure socket is required. All accounted for, that's anywhere from one to three — and more in unoptimized cases — roundtrips of latency to set up the socket befor

Some people, when confronted with a problem, think: “I'll use UA/device detection!” Now they have two problems... But, despite all of its pitfalls, UA/device detection is a fact of life, a growing business, and an enabling business requirement for many. The problem is that UA/device detection often frequently misclassifies capable clients (e.g. IE11 was forced to change their UA); leads to compati

By Ilya Grigorik on September 16, 2014 A "webfont" is a set of resources, not just a single download. A single resource that includes all stylistic variants, which we may not need, plus all the characters, which may go unused, would simply be too large — tens of megabytes for a font with good unicode and stylistic coverage! As a result, the CSS @font-face rule allows us define a font family that i

By Ilya Grigorik on May 05, 2014 Cryptocurrencies, and Bitcoin in particular, have been getting a lot of attention from just about every angle: regulation, governance, taxation, technology, product innovation, and the list goes on. The very concept of a "peer-to-peer (decentralized) electronic cash system" turns many of our previously held assumptions about money and finance on their head. That sa

By Ilya Grigorik on January 31, 2014 Web font adoption continues to accelerate across the web: according to HTTP Archive, ~37% of top 300K sites are using web fonts as of early 2014, which translates to a 2x+ increase over the past twelve months. Of course, this should not be all that surprising to most of us. Typography has always been an important part of good design, branding, and readability a

By Ilya Grigorik on November 27, 2013 Good news, browser support for the latest draft of “Compression Extensions” for WebSocket protocol — a much needed and overdue feature — will be landing in early 2014: Chrome M32+ (available in Canary already), and Firefox and Webkit implementations should follow. Specifically, it enables the client and server to negotiate a compression algorithm and its param

By Ilya Grigorik on October 24, 2013 TLS record size can have significant impact on the page load time performance of your application. In fact, in the worst case, which unfortunately is also the most common case on the web today, it can delay processing of received data by up to several roundtrips! On mobile networks, this can translate to hundreds of milliseconds of unnecessary latency. The good

By Ilya Grigorik on August 29, 2013 Note: Updated Oct 30, 2013 to reflect new Client Hints draft. High-density displays pack multiple physical pixels per CSS pixel, and the ratio between the two is known as the device pixel ratio (DPR). To deliver the best visual quality, a HiDPI image that matches the DPR value of the device should be served to the client. The question is, how? The answer to date

By Ilya Grigorik on June 20, 2013 HTTP Archive is a treasure trove of web performance data. Launched in late 2010, the project crawls over 300,000 most popular sites twice a month and records how the web is built: number and types of resources, size of each resource, whether the resources are compressed or marked as cacheable, times to render the page, time to first paint, and so on - you get the

By Ilya Grigorik on June 12, 2013 HTTP 2.0 enables the server to send multiple responses (in parallel) for a single client request - aka, server push. Except, why would we ever want to do such a thing? Well, an average page requires dozens of additional assets, such as JavaScript, CSS, and images, and references to all of these assets are embedded in the very HTML that the server is producing! Hen

By Ilya Grigorik on May 01, 2013 Deploying new image formats on the web is a challenge, but not an unsolvable one, and one that would pay high dividends in terms of performance. In fact, there are many ways to tackle the problem: client-side logic, server negotiation, and hybrid strategies. There is a time and place for each one - they are not exclusive. Having said that, I'm partial to server neg

By Ilya Grigorik on March 07, 2013 At the risk of sounding repetitive... An average page is now over 1300 kB in size and over 60% of that is in images. Hence, if you have limited time, then inspecting and optimizing your image assets will likely yield the highest rate of return. Case in point, the new data compression proxy for Chrome applies dozens of different content optimizations, but image op

The following is a draft chapter for the upcoming "The Performance of Open Source Applications" (POSA), a sequel to The Architecture of Open Source Applications. POSA is a collection of essays about performance optimization, designing for performance, managing performance as part of a development process, and more. The book will be published in Spring 2013 under a Creative Commons license with roy

Clearly, three hours of web performance content is not enough. I gave an updated version of the below workshop at Fluent 2013, the videos for which are now online on YouTube - check it out! Delivering a fast and optimized user experience in the browser requires careful thinking across many layers of the stack - TCP and up. In a rather ambitious undertaking, when I got the chance to run a three hou

By Ilya Grigorik on December 18, 2012 An average page is now over 1200kB in size and 60% of that is in images. With all the focus on performance and speed across the web performance industry, you would think that innovating on better image formats would be a top agenda item. Not so. Instead, we are living in a self-imposed world of scarcity of formats, effectively limiting ourselves to gif’s, png’

By Ilya Grigorik on October 31, 2012 SPDY is an experimental protocol developed at Google, designed to reduce the latency of web pages. Specifically, its goal is to address the limitations of HTTP 1.1 and to remove existing bottlenecks: head of line blocking, inefficient use of underlying TCP connections, and header bloat amongst others. However, while all of this sounds great in writing, deployin

By Ilya Grigorik on October 10, 2012 One of the best investments any development team can make is towards better tooling and automation of common workflows. Turns out, many web performance best practices are prime candidates for this type of automation: preprocessing, minification, concatenating and spriting assets, optimizing images, and so on. One way to achieve this is through a build step prio