サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
アメリカ大統領選
www.igvita.com
You've applied all the best practices, set up audits and tests to detect performance regressions, released the new application to the world, and... lo and behold, the telemetry is showing that despite your best efforts, there are still many users—including those on "fast devices" and 4G networks—that are falling off the fast path: janky animations and scrolling, slow loading pages and API calls, a
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 20, 2014 Synchronous scripts are bad because they force the browser to block DOM construction, fetch the script, and execute it before the browser can continue processing the rest of the page. This, of course, should not be news, and is the reason why we have been evangelizing the use of asynchronous scripts. Here is the canonical example: <!-- BAD: blocking external script
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 December 16, 2013 Network latency is one of our primary performance bottlenecks on the web. In the worst case, new navigation requires a DNS lookup, TCP handshake, two roundtrips to negotiate the TLS tunnel, and finally a minimum of another roundtrip for the actual HTTP request and response — that's five network roundtrips to get the first few bytes of the HTML document! Modern
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 October 20, 2011 Ever obsess about trying to find the "best and fastest" internet provider? Having recently gone through the marketing vortex of comparing a dozen different plans, I was then reminded of a simple fact: the primary metric (bandwidth) used by the industry is actually highly misleading. It turns out, for most web-browsing use cases, an internet connection over seve
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
High Performance Browser Networking What every developer must know about networking in the browser to build faster, more responsive applications. TCP, UDP and SSL optimization HTTP 1.1 & HTTP 2.0 performance tips Wireless and mobile network performance WebSocket, WebRTC, DataChannel, and more Part I: TCP, UDP & TLS Performance early release An in-depth look at performance characteristics of TCP, U
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
A whirlwind tour of DevTools tips and tricks Part I: DevTools tips, tricks and awesome features (video) Part II: Extending DevTools, Debug Protocol, Extensions, ... (video) Follow along @ bit.ly/devtools-tips Elements & Console Drag & Drop to reorder elements $0 to inspect selected element in console Break on node removal - delete me cmd-? to become a keyboard ninja Customize your settings! Disab
次のページ
このページを最初にブックマークしてみませんか?
『Ilya Grigorik』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く