Which would you rather have: A rich design or a fast user experience? Users want both, but sometimes the interplay between design and performance feels like a fixed sum game: One side’s gain is the other side’s loss. Design and performance are indeed connected, but it’s more like the yin and yang. They aren’t opposing forces, but instead complement each other. Users want an experience that is rich and fast. The trick for us as designers and developers is figuring out how to do that.
The answer is to adopt an approach that considers both design and performance from the outset. With this approach, designs are conceived by teams of designers and developers working together. Developers benefit by participating in the product definition process. Designers benefit from understanding more about how designs are implemented. There’s an emphasis on early prototyping and tracking performance from the get-go.
With new metrics that focus on what a user actually sees as the page loads, we can now bridge the technical and language gaps that have hindered the seamless creation of great user experiences. In this presentation, Steve Souders, former Chief Performance Yahoo! and Google head performance engineer, explains how promoting a process that brings design and performance together at the beginning of a project helps deliver a web experience that is both fast and rich.
High Performance Mobile (SF/SV Web Perf)Steve Souders
1. The document discusses optimizing websites for high performance mobile experiences. It provides 14 best practices for mobile optimization, including making fewer HTTP requests, using content delivery networks, gzipping components, and optimizing images.
2. Mobile optimization is important because mobile internet usage is growing rapidly. Performance impacts metrics like user experience and revenue.
3. Tools for measuring and improving mobile performance are introduced, such as PcapPerf for analyzing network traffic and Weinre for debugging JavaScript on mobile devices. Faster mobile sites will have an advantage as mobile becomes the primary internet platform.
How many photo carousels have you built? Date pickers? Dynamic tables and charts? Wouldn't it be great if there was a way to make these custom elements encapsulated and reusable? Welcome to Web Components! The building blocks are well known: HTML templates, custom elements, HTML imports, and shadow DOM. It's fairly easy to build simple examples. But what happens when performance degrades? Join this discussion of the synchronous and asynchronous nature of web components, and how they can impact the rendering of the entire page.
The document discusses the speed of the modern web. It summarizes key metrics around connection speeds, browser speeds, page weights, adoption of best practices, and page load times based on data from various sources. While some metrics like connection speeds and page load times are improving, pages overall are getting heavier and adoption of best practices is flat. The document advocates watching video growth, developing better performance metrics, promoting best practices more widely, utilizing multiple CPUs, and improving caching.
The document discusses techniques for prebrowsing or prefetching resources to improve page load performance. It describes how developers can use <link> tags with rel="dns-prefetch", rel="prefetch", and rel="prerender" to hint to browsers on resources that could be pre-resolved, pre-downloaded or pre-rendered before they are needed. It also explains how browsers perform internal prefetching optimizations like DNS pre-resolution, TCP pre-connection and prefetching of likely-needed resources during page transitions using predictors. The goal is to get resources the browser will need before it needs them to reduce load times.
The document discusses techniques for improving frontend web performance, including splitting codepayloads, loading scripts without blocking, and not scattering scripts across pages. It recommends focusing first on optimizing frontend performance since 80-90% of end user response time is spent loading frontend resources. Specific techniques include splitting JavaScript payloads into above-the-fold and below-the-fold code, using techniques like XHR and iframes to load scripts asynchronously without blocking page rendering, and avoiding placing inline scripts between stylesheets and other page resources.
The document discusses techniques for loading JavaScript files to optimize website performance. It describes methods like splitting the initial payload, loading scripts asynchronously without blocking parsing and rendering, and deferring non-critical scripts. Examples of major sites like Gmail, Facebook, Google and Wikipedia that use these techniques are also provided.
High Performance Mobile (SF/SV Web Perf)Steve Souders
1. The document discusses optimizing websites for high performance mobile experiences. It provides 14 best practices for mobile optimization, including making fewer HTTP requests, using content delivery networks, gzipping components, and optimizing images.
2. Mobile optimization is important because mobile internet usage is growing rapidly. Performance impacts metrics like user experience and revenue.
3. Tools for measuring and improving mobile performance are introduced, such as PcapPerf for analyzing network traffic and Weinre for debugging JavaScript on mobile devices. Faster mobile sites will have an advantage as mobile becomes the primary internet platform.
How many photo carousels have you built? Date pickers? Dynamic tables and charts? Wouldn't it be great if there was a way to make these custom elements encapsulated and reusable? Welcome to Web Components! The building blocks are well known: HTML templates, custom elements, HTML imports, and shadow DOM. It's fairly easy to build simple examples. But what happens when performance degrades? Join this discussion of the synchronous and asynchronous nature of web components, and how they can impact the rendering of the entire page.
The document discusses the speed of the modern web. It summarizes key metrics around connection speeds, browser speeds, page weights, adoption of best practices, and page load times based on data from various sources. While some metrics like connection speeds and page load times are improving, pages overall are getting heavier and adoption of best practices is flat. The document advocates watching video growth, developing better performance metrics, promoting best practices more widely, utilizing multiple CPUs, and improving caching.
The document discusses techniques for prebrowsing or prefetching resources to improve page load performance. It describes how developers can use <link> tags with rel="dns-prefetch", rel="prefetch", and rel="prerender" to hint to browsers on resources that could be pre-resolved, pre-downloaded or pre-rendered before they are needed. It also explains how browsers perform internal prefetching optimizations like DNS pre-resolution, TCP pre-connection and prefetching of likely-needed resources during page transitions using predictors. The goal is to get resources the browser will need before it needs them to reduce load times.
The document discusses techniques for improving frontend web performance, including splitting codepayloads, loading scripts without blocking, and not scattering scripts across pages. It recommends focusing first on optimizing frontend performance since 80-90% of end user response time is spent loading frontend resources. Specific techniques include splitting JavaScript payloads into above-the-fold and below-the-fold code, using techniques like XHR and iframes to load scripts asynchronously without blocking page rendering, and avoiding placing inline scripts between stylesheets and other page resources.
The document discusses techniques for loading JavaScript files to optimize website performance. It describes methods like splitting the initial payload, loading scripts asynchronously without blocking parsing and rendering, and deferring non-critical scripts. Examples of major sites like Gmail, Facebook, Google and Wikipedia that use these techniques are also provided.
This document summarizes Steve Souders' presentation on web performance optimization (WPO). It discusses how speed is the most important website feature and outlines techniques to improve performance like optimizing assets, reducing page weight, and leveraging caching. It also covers emerging trends like SPDY and improvements to third-party content. The key takeaways are that WPO matters significantly, new standards are coming, and guarding against slow third-party code.
This document discusses strategies for improving JavaScript performance on websites. It begins by noting that JavaScript is often the number one cause of slow web pages. It then reviews the history of JavaScript loading approaches, from loading scripts in the page head in 1995 to more modern async and deferred loading. It discusses using localStorage as a cache and the Google Analytics async snippet as examples. It concludes by recommending tools and resources for measuring and improving JavaScript performance, including WebPagetest.org, ControlJS, and Steve Souders' own site and books.
Web Directions South - Even Faster Web SitesSteve Souders
The document discusses techniques for optimizing web page performance, including loading scripts asynchronously without blocking page rendering, splitting scripts into critical and non-critical parts, leveraging content delivery networks, minimizing downloads, and using new web standards like the Navigation Timing API. It emphasizes the importance of front-end optimization and progressive enhancement to improve site speed. Examples are given of how major sites like Google, Facebook, and Wikipedia optimize script loading.
Every URL visited from the Facebook iPhone app is done through a webview. Same with Twitter. Even if you don't have a mobile app, your website gets a lot of traffic from webviews. And yet, testing on webviews is challenging. There are significant performances differences between UIWebView vs WkWebView, and similarly for Android webview vs the new Chromium webview. And what about home screen apps?! In this talk, Steve Souders discusses the differences across webviews and how that affects performance of mobile web apps.
Presentation at WebPerfDays Amsterdam, May 18 2013.
This newish browser API can be used to gain insight in the load time of individual page resources. Does the API behave consistently and as expected? Short answer: no, not really. Long answer: view the presentation ;-)
Making users happy is a goal that unifies everyone on the team. The key then is to establish metrics that reflect user happiness. In the world of performance, we haven’t always done a great job of this. Often, performance metrics track how our pages are built which might not be correlated with a joyous user experience, and we start optimizing our stack for the sake of optimizing our stack. Luckily, momentum is building around UX-centered metrics such as start render time, time-to-interact, and first meaningful paint. Steve Souders discusses these new metrics that help us build web apps that produce the fast, joyous experiences our users want.
This document summarizes Christopher Schmitt's presentation on adaptive images in responsive web design. It discusses using feature testing versus browser sniffing to determine the appropriate image to serve, including testing browser width, screen resolution, and bandwidth. It then covers various techniques for serving adaptive images, such as using .htaccess files, the <picture> element, srcset attributes, and JavaScript libraries. It emphasizes using a mobile-first approach and progressive enhancement to provide the best experience for all devices.
All of us have a lurking failure in our websites: 3rd party scripts from ads, widgets, and analytics. How is it that one script can bring down your website?
1. Synchronous scripts block page rendering, so scripts should be loaded asynchronously.
2. Front-end dependencies like social media widgets can cause slowdowns if they fail to load. Blackholing domains in tests can show these slowdowns.
3. "Bootstrap scripts" from content delivery networks often have short cache times, increasing chances of failures. But they can be made self-updating while keeping long cache times.
As browsers explode with new capabilities and migrate onto devices users can be left wondering, “what’s taking so long?” Learn how HTML, CSS, JavaScript, and the web itself conspire against a fast-running application and simple tips to create a snappy interface that delight users instead of frustrating them.
HTML5: Markup Evolved documents the evolution of HTML from its origins in 1991 to the present day. It discusses key milestones like HTML 4.0 in 1999 and the unification of HTML5 efforts by the W3C and WHATWG in 2009. The document outlines new HTML5 elements, attributes, and multimedia capabilities like canvas, audio, and video. It encourages adopting HTML5 gradually through evolution rather than revolution. Resources for learning HTML5 are provided.
The document discusses techniques for improving frontend web performance, including splitting code into critical and non-critical sections, loading scripts asynchronously without blocking other downloads, and avoiding scattering scripts throughout a page. It provides examples of sites that could benefit from these techniques and recommends tools like YSlow for auditing performance. The overall message is that frontend optimizations like JavaScript improvements can significantly speed up sites.
Slides from my Ignite (20 slides, auto-advancing every 15 secs) talk at WebPerfDays, Mountain View.
Not sure they will make sense standalone but talk was recorded and will be available at some point.
Would also like to work this up into a longer talk at some point.
The document discusses techniques for improving frontend web performance, with a focus on optimizing JavaScript loading. It recommends splitting code downloads into above-the-fold and enhancements sections, loading scripts asynchronously and in parallel without blocking, and avoiding scattered inline scripts. Key techniques include loading scripts with XMLHttpRequest, in iframes, or dynamically creating script elements.
1. The document discusses the debate around relying on JavaScript for web applications and progressive enhancement.
2. It argues that while JavaScript can break, the web has evolved to focus more on capable client-side devices rather than availability of JavaScript.
3. It suggests embracing new paradigms like components and functional programming to build high quality, error-handling code rather than avoiding JavaScript.
Our application got popular and now breaks under load. The document discusses common issues that cause applications to break as user load increases, such as overuse of shared scopes, inefficient database queries, and slow client-side performance. It provides examples of better approaches and techniques to optimize performance, such as using distributed caching, improving query efficiency through joins, compressing assets, and prioritizing critical CSS and JavaScript.
1) The document discusses responsive video formats and delivery methods for different devices.
2) It covers video codecs like H.264 and VP8, as well as formats like MP4, WebM and OGG.
3) Adaptive streaming technologies like Apple's HLS and MPEG-DASH are presented as ways to deliver the most appropriate video quality based on a user's bandwidth and device capabilities.
Design & Performance - Steve Souders at Fastly Altitude 2015Fastly
Fastly Altitude - June 25, 2015. Chief SpeedCurver Steve Souders explains how design and web performance are more interconnected than ever before. Users want a fast website with a rich design, but sometimes the interplay between design and performance feels like a fixed sum game: one side's gain is the other side's loss. Design and performance are indeed connected, but it's more like the yin and yang. They aren't opposing forces, but instead complement each other. Bringing these processes together produces experiences that are rich and fast.
Video from the talk: http://fastly.us/Altitude2015_Design-Performance
Steve's bio: Steve Souders is a co-founder at SpeedCurve, where he develops web performance services. His book, High Performance Web Sites, explains his best practices for performance; it was #1 in Amazon's Computer and Internet bestsellers. His follow-up book, Even Faster Web Sites, provides performance tips for today's Web 2.0 applications. Steve is the creator of many performance tools and services including YSlow, the HTTP Archive, Cuzillion, Jdrop, SpriteMe, ControlJS, and Browserscope. He serves as co-chair of Velocity, the web performance and operations conference from O'Reilly, and is co-founder of the Firebug Working Group.
Christopher Schmitt presented on adaptive images in responsive web design. He discussed using browser features like width, resolution and bandwidth to determine the best image to serve rather than browser sniffing. Feature testing methods included JavaScript, jQuery and CSS media queries. Workarounds for older browsers included background images, SVGs and font-based solutions. Compressed JPEG images were also suggested to reduce file sizes.
This document summarizes Steve Souders' presentation on web performance optimization (WPO). It discusses how speed is the most important website feature and outlines techniques to improve performance like optimizing assets, reducing page weight, and leveraging caching. It also covers emerging trends like SPDY and improvements to third-party content. The key takeaways are that WPO matters significantly, new standards are coming, and guarding against slow third-party code.
This document discusses strategies for improving JavaScript performance on websites. It begins by noting that JavaScript is often the number one cause of slow web pages. It then reviews the history of JavaScript loading approaches, from loading scripts in the page head in 1995 to more modern async and deferred loading. It discusses using localStorage as a cache and the Google Analytics async snippet as examples. It concludes by recommending tools and resources for measuring and improving JavaScript performance, including WebPagetest.org, ControlJS, and Steve Souders' own site and books.
Web Directions South - Even Faster Web SitesSteve Souders
The document discusses techniques for optimizing web page performance, including loading scripts asynchronously without blocking page rendering, splitting scripts into critical and non-critical parts, leveraging content delivery networks, minimizing downloads, and using new web standards like the Navigation Timing API. It emphasizes the importance of front-end optimization and progressive enhancement to improve site speed. Examples are given of how major sites like Google, Facebook, and Wikipedia optimize script loading.
Every URL visited from the Facebook iPhone app is done through a webview. Same with Twitter. Even if you don't have a mobile app, your website gets a lot of traffic from webviews. And yet, testing on webviews is challenging. There are significant performances differences between UIWebView vs WkWebView, and similarly for Android webview vs the new Chromium webview. And what about home screen apps?! In this talk, Steve Souders discusses the differences across webviews and how that affects performance of mobile web apps.
Presentation at WebPerfDays Amsterdam, May 18 2013.
This newish browser API can be used to gain insight in the load time of individual page resources. Does the API behave consistently and as expected? Short answer: no, not really. Long answer: view the presentation ;-)
Making users happy is a goal that unifies everyone on the team. The key then is to establish metrics that reflect user happiness. In the world of performance, we haven’t always done a great job of this. Often, performance metrics track how our pages are built which might not be correlated with a joyous user experience, and we start optimizing our stack for the sake of optimizing our stack. Luckily, momentum is building around UX-centered metrics such as start render time, time-to-interact, and first meaningful paint. Steve Souders discusses these new metrics that help us build web apps that produce the fast, joyous experiences our users want.
This document summarizes Christopher Schmitt's presentation on adaptive images in responsive web design. It discusses using feature testing versus browser sniffing to determine the appropriate image to serve, including testing browser width, screen resolution, and bandwidth. It then covers various techniques for serving adaptive images, such as using .htaccess files, the <picture> element, srcset attributes, and JavaScript libraries. It emphasizes using a mobile-first approach and progressive enhancement to provide the best experience for all devices.
All of us have a lurking failure in our websites: 3rd party scripts from ads, widgets, and analytics. How is it that one script can bring down your website?
1. Synchronous scripts block page rendering, so scripts should be loaded asynchronously.
2. Front-end dependencies like social media widgets can cause slowdowns if they fail to load. Blackholing domains in tests can show these slowdowns.
3. "Bootstrap scripts" from content delivery networks often have short cache times, increasing chances of failures. But they can be made self-updating while keeping long cache times.
As browsers explode with new capabilities and migrate onto devices users can be left wondering, “what’s taking so long?” Learn how HTML, CSS, JavaScript, and the web itself conspire against a fast-running application and simple tips to create a snappy interface that delight users instead of frustrating them.
HTML5: Markup Evolved documents the evolution of HTML from its origins in 1991 to the present day. It discusses key milestones like HTML 4.0 in 1999 and the unification of HTML5 efforts by the W3C and WHATWG in 2009. The document outlines new HTML5 elements, attributes, and multimedia capabilities like canvas, audio, and video. It encourages adopting HTML5 gradually through evolution rather than revolution. Resources for learning HTML5 are provided.
The document discusses techniques for improving frontend web performance, including splitting code into critical and non-critical sections, loading scripts asynchronously without blocking other downloads, and avoiding scattering scripts throughout a page. It provides examples of sites that could benefit from these techniques and recommends tools like YSlow for auditing performance. The overall message is that frontend optimizations like JavaScript improvements can significantly speed up sites.
Slides from my Ignite (20 slides, auto-advancing every 15 secs) talk at WebPerfDays, Mountain View.
Not sure they will make sense standalone but talk was recorded and will be available at some point.
Would also like to work this up into a longer talk at some point.
The document discusses techniques for improving frontend web performance, with a focus on optimizing JavaScript loading. It recommends splitting code downloads into above-the-fold and enhancements sections, loading scripts asynchronously and in parallel without blocking, and avoiding scattered inline scripts. Key techniques include loading scripts with XMLHttpRequest, in iframes, or dynamically creating script elements.
1. The document discusses the debate around relying on JavaScript for web applications and progressive enhancement.
2. It argues that while JavaScript can break, the web has evolved to focus more on capable client-side devices rather than availability of JavaScript.
3. It suggests embracing new paradigms like components and functional programming to build high quality, error-handling code rather than avoiding JavaScript.
Our application got popular and now breaks under load. The document discusses common issues that cause applications to break as user load increases, such as overuse of shared scopes, inefficient database queries, and slow client-side performance. It provides examples of better approaches and techniques to optimize performance, such as using distributed caching, improving query efficiency through joins, compressing assets, and prioritizing critical CSS and JavaScript.
1) The document discusses responsive video formats and delivery methods for different devices.
2) It covers video codecs like H.264 and VP8, as well as formats like MP4, WebM and OGG.
3) Adaptive streaming technologies like Apple's HLS and MPEG-DASH are presented as ways to deliver the most appropriate video quality based on a user's bandwidth and device capabilities.
Design & Performance - Steve Souders at Fastly Altitude 2015Fastly
Fastly Altitude - June 25, 2015. Chief SpeedCurver Steve Souders explains how design and web performance are more interconnected than ever before. Users want a fast website with a rich design, but sometimes the interplay between design and performance feels like a fixed sum game: one side's gain is the other side's loss. Design and performance are indeed connected, but it's more like the yin and yang. They aren't opposing forces, but instead complement each other. Bringing these processes together produces experiences that are rich and fast.
Video from the talk: http://fastly.us/Altitude2015_Design-Performance
Steve's bio: Steve Souders is a co-founder at SpeedCurve, where he develops web performance services. His book, High Performance Web Sites, explains his best practices for performance; it was #1 in Amazon's Computer and Internet bestsellers. His follow-up book, Even Faster Web Sites, provides performance tips for today's Web 2.0 applications. Steve is the creator of many performance tools and services including YSlow, the HTTP Archive, Cuzillion, Jdrop, SpriteMe, ControlJS, and Browserscope. He serves as co-chair of Velocity, the web performance and operations conference from O'Reilly, and is co-founder of the Firebug Working Group.
Christopher Schmitt presented on adaptive images in responsive web design. He discussed using browser features like width, resolution and bandwidth to determine the best image to serve rather than browser sniffing. Feature testing methods included JavaScript, jQuery and CSS media queries. Workarounds for older browsers included background images, SVGs and font-based solutions. Compressed JPEG images were also suggested to reduce file sizes.
The document discusses adaptive images in responsive web design. It covers using the browser's user agent string and feature testing to determine screen resolution and bandwidth instead of browser sniffing. Methods presented include using viewport width with JavaScript, jQuery, and CSS media queries; checking screen resolution directly and considering retina displays; and avoiding bandwidth speed tests. Workarounds discussed are using background-size: 100% with images, SVG, and a "Clown Car" SVG technique loading different image files via CSS media queries.
This document discusses adaptive images in responsive web design. It begins by introducing the speaker, Christopher Schmitt, and his credentials. It then explores using the browser's user agent string and feature detection to determine screen resolution and bandwidth rather than browser sniffing. The document discusses using CSS media queries, jQuery, and the picture element to serve adaptive images. It also proposes some workaround techniques like background sizing and SVG to improve responsive images.
The document discusses adaptive images in responsive web design. It covers techniques like using the browser width and screen resolution to determine the appropriate image size via JavaScript or media queries. It also discusses checking bandwidth and using techniques like picture, srcset, .htaccess rewriting, and single pixel GIFs to serve the right image. The document recommends using CSS media queries for design and covers workaround techniques like background-size, SVG, and font-based solutions.
The document discusses the importance of website performance and provides tips to build responsive websites. It notes that users expect pages to load within 2 seconds and will leave slow sites. The tips include reducing HTTP requests, gzipping and minifying components, optimizing images, delivering JavaScript and CSS efficiently, lazy loading images, and inlining critical CSS. Following these foundations and techniques can significantly improve load times and user experience.
The document discusses various techniques designers can use to improve website performance, including optimizing images, using CSS sprites, icon fonts, data URI schemes, and maintaining consistency with styles and rules. It provides examples of how to optimize images, create CSS sprites, use icon fonts, embed images via data URIs, and improve consistency. It also includes links to resources about gzip compression and gradient button styles.
Fisl 11 - Dicas de Desenvolvimento Web com RubyFabio Akita
Performance de sites não tem a ver com a linguagem usada por baixo. O impacto maior é a arquitetura. Nesta palestra falo sobre YSlow, Resque e Solr como algumas das coisas que podemos fazer para melhorar a performance/escalabilidade de aplicações web.
The document summarizes Christopher Schmitt's presentation at RWD Summit 2014 on adaptive images in responsive web design. It discusses using feature testing over browser sniffing to determine screen resolution and bandwidth. It presents techniques like srcset, picture, and JavaScript solutions to serve appropriately sized images. It also covers workarounds like background-size, SVG, and font-based solutions when native techniques are not supported. The focus is on building responsive images that scale with the device and load quickly.
1. The document discusses various techniques for implementing adaptive images in responsive web design, including using the browser's user agent string, feature testing dimensions with JavaScript, and CSS media queries.
2. It describes approaches like modifying .htaccess files and using the <picture> element to serve different image sizes, as well as libraries that simplify the process like HiSRC.
3. Workarounds discussed include using background images, SVG images, font-based solutions, and compressed JPEG files to improve performance on different devices.
Consegi 2010 - Dicas de Desenvolvimento Web com RubyFabio Akita
Esta é a palestra que dei no Consegi 2010 em Brasília. Sobre dicas gerais sobre web, em particular implementando com Ruby on Rails. YSlow, Full Text Search e Tarefas Assíncronas.
[CSSDevConf] Adaptive Images in Responsive Web Design 2014Christopher Schmitt
The web doesn't stop at the desktop anymore. Our image assets need to do more than look good in one context. In this talk, I look at how images like JPEG, GIFs, SVG, Icons, Unicode, and more can be used in a multi-device environment.
This document discusses responsive image techniques for adaptive web design. It begins by explaining browser sniffing versus feature testing, and recommends using feature testing to determine browser width, screen resolution, and bandwidth instead of browser sniffing. It then covers techniques like using background-size to control image sizes, SVG for smaller file sizes, and font-based solutions. The document also discusses server-side techniques like .htaccess rewrite rules and client-side techniques like picture and HiSRC. It advocates for a mobile-first approach using CSS media queries and a single pixel GIF for responsive images.
NYC WebPerf Meetup Feb 2020 - Measuring the Adoption of Web Performance Techn...Paul Calvano
Performance optimization is a cyclical process. We are constantly learning new ways to optimize, while simultaneously adopting new technologies and techniques that negatively impact performance. The HTTP Archive provides a great historical record of the technical side of the web, with almost 10 years of history and an ever growing dataset of sites.
During this session Paul will provide a brief overview of the HTTP Archive and then dive into some insights into the adoption of common web performance techniques and some of their measurable impacts.
The document discusses various techniques for optimizing web performance, including:
- Minifying assets like CSS, JavaScript, and images to reduce file sizes
- Leveraging caching, compression, and browser parallelization to speed up page loads
- Implementing responsive design patterns and techniques like image sprites and media queries
- Optimizing assets further with techniques like image optimization, lazy loading, and prefetching
This document is the HTML code for the upload page on the SlideShare website. It includes metadata, scripts, and styling to display the page content which encourages users to discover, share and present presentations, infographics and videos on the largest professional content sharing community. The page code provides options for users to upload, login or sign up for an account.
Christopher Schmitt, "Adaptive Images for Responsive Web Design"WebVisions
The open web doesn't stop at our desktop. Smart phones and tablets not only contain more computing power and better browsers than the computers that started the Internet economy, they have better displays.
Presented at WebVisions Barcelona 2013.
This document discusses techniques for responsive images on the web. It begins by explaining how to use browser width, screen resolution, and bandwidth detection to serve appropriately sized images. It then discusses .htaccess and JavaScript solutions like Filament Group's responsive images and HiSRC. It argues that CSS media queries are best for layout, while these techniques focus on images. Background-size, SVG, and Modernizr checks are presented as workarounds. Overall, the document provides an overview of different responsive image implementation strategies.
Smartphones and tablets not only contain more computing power and better browsers than the computers that started the Internet economy. They also have better displays, which demands more of us when we use images. This session will work through tips and tricks to develop future friendly images in our sites and apps.
This document discusses various techniques for responsive images in web design, including browser sniffing versus feature testing, image sizes for different screen resolutions and bandwidths, and different implementation methods like .htaccess files, the <picture> element, and JavaScript libraries. It covers topics like using the browser width to determine layouts, screen resolution detection, and bandwidth testing. Workarounds discussed include using background images, SVGs, icon fonts, and compressed JPEGs. The document advocates a mobile-first approach and using CSS media queries to adapt designs based on screen size.
This document discusses ways to make JavaScript faster in web pages. It recommends loading scripts asynchronously or with defer, preloading scripts, reducing CPU time spent evaluating scripts and function calls, budgeting third-party scripts, ensuring proper compression of scripts, and reviewing code coverage to optimize performance.
Which would you rather have: a website that’s fast or a website that’s perceived as fast? The answer is “Both!” The list of performance best practices is long and well known, but there’s been less focus on the user’s perception of speed. In this presentation Steve Souders provides examples of how the perception of speed is completely independent of actual speed, and techniques for leveraging this perception gap to create websites that feel fast.
How many photo carousels have you built? Date pickers? Dynamic tables and charts? Wouldn't it be great if there was a way to make these custom elements encapsulated and reusable? Welcome to Web Components! The building blocks are well known: HTML templates, custom elements, HTML imports, and shadow DOM. It's fairly easy to build simple examples. But what happens when performance degrades? Join this discussion of the synchronous and asynchronous nature of web components, and how they can impact the rendering of the entire page.
Cache is King discusses the importance of caching for website performance. It shows that enabling caching through techniques like setting Cache-Control headers can reduce page load times significantly. Specifically, using max-age to set expiration times for cacheable assets avoids unnecessary HTTP requests. For dynamic content, no-cache must be used to prevent caching. The document advocates being explicit with caching directives and measuring caching behavior to identify opportunities to optimize websites for cached access.
This document summarizes Steve Souders' presentation on web performance optimization (WPO). It discusses how speed is the most important website feature and outlines techniques to improve performance like optimizing assets, reducing page weight, and addressing third-party content. It also previews upcoming developments in WPO like browser tools, standards, and the growing focus on mobile and ensuring speed remains a key differentiator.
This document summarizes Steve Souders' presentation on front-end performance. It discusses the importance of front-end optimization, providing statistics on how much JavaScript impacts page load times. It also offers best practices for optimizing assets like JavaScript, CSS, images and caching. These include techniques like concatenating and minifying files, leveraging the browser cache, using CDNs and prioritizing visible content. The document emphasizes strategies like progressive enhancement and rendering to improve perceived performance.
CouchDB is a document-oriented NoSQL database that uses JSON documents with schema-free design. It features a built-in map/reduce function for querying indexes, and uses HTTP for an API and replication. CouchDB is robust, scales well, and is designed for high availability through its append-only writing and multi-version concurrency control.
Browserscope is an open-source project that profiles browsers to foster innovation and help web developers. It uses crowdsourcing to run tests on a wide variety of browsers and systems, aggregating the results to reduce biases and immediately detect changes in new and existing browsers. The current test categories examine network performance, Acid3 compliance, JavaScript and CSS capabilities, and rich text editing functions.
Presented at SXSW '09, this talk covers five best practices from my next book: Load scripts without blocking, Coupling asynchronous scripts, Don't scatter inline scripts, Use iframes sparingly, and Flush the document early.
Upcycling for Everyone project exhibition postersKyungeun Sung
'Upcycling for Everyone' project exhibition posters, funded by De Montfort University's QR funding for participatory research and AHRC-funded International Upcycling Research Network project. Exhibition launch at LCB Depot on 5th July 2024.
This is Stage one of my Future Deep Strike Aircraft project to develop a replacement for the FB-111 / F-111F / F-15E and B-1B. This stage covers requirements and threats. Stage 2 will cover Design Studies, and the CCA Wingman.
17. Speed is more important
than design embellishment.
People are filling
small gaps in their
day with news. It
must load fast on all
touchpoints.
The design should
feel light and nimble,
always fresh and up
to date. Never
heavy, slow to load
or clogged up with
content.
Users expect sites
to render in under 2
seconds.
DAN/TBWA
This talk is about creating better websites by bringing designers & developers closer together
Perhaps your experience with bringing designers & developers is a bit like this - but without the pillows.
Certainly, navigating between design and implementation often feels like a fixed sum game.
One side’s win is the other side’s loss.
https://www.flickr.com/photos/timdorr/4396870234/in/photolist-7Gx7ku-7GtaDx-7Gx4Ub-7Gta8t-7GtadX-7GvYZ1-3nArNu-3nArUy-3nApNY-3nvYmr-3nAq8N-3nApG1-3nAq2q-3nvYJg-3nw1xc-3nAtnq-3nvVBg-3nAtad-3nAtUo-3nw1jX-3nvZti-3nvXm6-3nAr7d-3nAqfL-3nAuPb-3nAsRf-3nAssL-3nvZHt-3nAroy-3nArvb-3nAqUE-3nAph1-3nvXf4-3nArGG-3nvVb8-3nAscS-3nAtAW-3nAueq-3nvYwD-3nArZN-3nAr27-3nAqs5-oM1oiq-bCU3k4-3sZr4-682gYi-6eDdv3-qSGcRS-aFFtxX-7QzWQc
But really, they’re both after the same thing: creating a great user experience!
Design & development ARE connected, but they’re more like the yin and the yang.
They aren't opposing forces, but instead complement each other.
Users want an experience that is rich and fast. The trick is figuring out how to deliver that.
Similar to DevOps from Velocity.
https://www.flickr.com/photos/easyflow/3377137372/in/photolist-69qHhq-5JUiYP-55ZfsE-dYmwEQ-5Ca1VD-7zq7En-kVv8dK-mqM9Jp-5J3uv9-f4JB8M-qZznd-f4MRgN-f4xAET-bpDYeX-GroML-7qoFXr-55nSfk-rbJwH-6RFZt1-6qnVXy-jtkLG-cEGq9-4xp87D-eeUgzz-c7QHf-6qk9JT-7PjaWF-4gf1tv-7sK9B3-4VtxzW-6qvWgT-8UB4U-8t9NNr-bDvQY-972WQq-6Fkgen-4RSnyY-8T7px8-6rWXPz-6rWU3n-5fgGGe-Hq1J7-cvqi-7Hs86U-9Vo8SK-gzpzde-666Ch9-4CzyT6-3hx5nr-dReBgT
A lot of the thinking behind Design+Performance came from long discussions with my business partner Mark Zeman.
He has a lengthy career as a designer and creative director, but sadly can’t be here today.
So I’m going to borrow from Yemeni Perez-Cruz to represent designers.
two minutes is slow
but we know good performance is key to great user experiences
but we know good performance is key to great user experiences
and now Google is even demanding that your websites be quick if you don’t want to get demoted in their search results
so where are we?
https://www.flickr.com/photos/jronaldlee/5775587577/in/photolist-9NnoYa-nYYp6g-63bGJj-KrzjB-6nYgX1-8KY39y-kz3M7y-fo68C6-5onBza-apBT72-6g9eSA-9WNvKw-4Gb2FP-2V7jsj-6G7Ynq-2tbdKU-9Kip9s-4TL5Sc-iJQYR-gi6ri6-pfx24Z-BgDwR-9NgMy1-of8g8U-49queL-atRJTH-ax64Nq-fSUV1Q-4qvBPj-4Se4NE-aegPJ4-ptxVJE-ptM5zP-ptMNBV-q95ZVa-kcfpje-mPZDqk-7FPG6G-cqvvXs-rwFCJA-bVYoNj-6McJox-CXYYb-5bMxiG-49mrhe-6q5uNW-7DpdiH-6MgWby-5n89ro-dVXS9w
It is possible to bring design and performance closer together. Here’s how…
https://www.flickr.com/photos/easyflow/3377137372/in/photolist-69qHhq-5JUiYP-55ZfsE-dYmwEQ-5Ca1VD-7zq7En-kVv8dK-mqM9Jp-5J3uv9-f4JB8M-qZznd-f4MRgN-f4xAET-bpDYeX-GroML-7qoFXr-55nSfk-rbJwH-6RFZt1-6qnVXy-jtkLG-cEGq9-4xp87D-eeUgzz-c7QHf-6qk9JT-7PjaWF-4gf1tv-7sK9B3-4VtxzW-6qvWgT-8UB4U-8t9NNr-bDvQY-972WQq-6Fkgen-4RSnyY-8T7px8-6rWXPz-6rWU3n-5fgGGe-Hq1J7-cvqi-7Hs86U-9Vo8SK-gzpzde-666Ch9-4CzyT6-3hx5nr-dReBgT
None of this works unless you have the right people in the room the whole way through the process.
It’s hard to create this relationship halfway through the process
bring designers & developers together from the get go
With everyone gathered together, discuss project goals and capture guiding principles.
Make sure performance is addressed.
https://www.flickr.com/photos/nihaogirl/4922776916/in/photolist-ndeSfc-51eh43-51a5LR-74FetH-4TeuNB-df5nYf-5Vo2Wn-5Nmjzn-51a5zV-51egkE-51a546-8v1w55-5t8PLi-9Zxguz-7wK1Le-6RAgsL
Here is an example of a principle from the design of a news website. The research showed that users consume news in small quick chunks and so it was more important that it loaded extremely fast than be visually rich with lots of brand assets. People are waiting at the bus stop and they have less than a minute to scan a few articles on their phone - it has to be fast.
There is even a specific mention for when the site should be loaded and that was used as a performance budget.
Here is an example of a principle from the design of a news website. The research showed that users consume news in small quick chunks and so it was more important that it loaded extremely fast than be visually rich with lots of brand assets. People are waiting at the bus stop and they have less than a minute to scan a few articles on their phone - it has to be fast.
There is even a specific mention for when the site should be loaded and that was used as a performance budget.
It means all the knowledge is in one room, everybody is working on the prototype from day one. Designers are not working in photoshop to create full layouts - they are creating individual assets that go into a prototype. Developers are working with existing data sources and manipulating real content. Researchers are capturing users needs and gauging reactions to each prototype. Team members have a specialisation but are expected to contribute to all aspects of the project.
Everybody is contributing to the prototype and the conversions are all embodied in one place. So every one has a shared vision and can see how well the project principles and performance principles are being met.
Here's a moment that I love - the client is in the room, the developer is experimenting with changing layout and the designer is consulting on the various options they are playing with. All the discussion revolves around the prototype on screen.
And by having a prototype from day one we can immediately assess it's performance and ensure it's delivering the user experience we need.
But one of the challenges with performance is that it is invisible. How do we monitor and make visible the performance all the way through the process - for everybody, not just this small interdisciplinary team, but also the wider organisation we need to have conversations with.
But one of the challenges with performance is that it is invisible. How do we monitor and make visible the performance all the way through the process - for everybody, not just this small interdisciplinary team, but also the wider organisation we need to have conversations with.
https://www.flickr.com/photos/josterpi/3174097491/in/photolist-5Qu5AP-h4vYQc-qDkDsE-6tDQ53-ap4pYT-6VrZjk-md5yR5-5PondA-5PVcKC-bvavRn-bxsk7Z-QudsT-6S1ivp-9hwNYa-8UjqcP-ap7amu-9zgR8a-qf1yJ9-qgz457-4JXfm4-99eAKF-6cyvEr-mFUttz-e2FfcF-37ddmA-wBwq6-63iZnr-wBwiC-9XMHpn-ph8ANF-9XQzJE-ZsAKM-iyQpBa-7jgbx4-6QJSTZ-7jk5tw-wBwgS-wBwca-bA44J-8Mdwca-qMZeNs-7P5RjE-6o8M7d-9hP5RB-4zySd-aAqBn3-NGjcd-cH8cQU-8USCg9-8KMjFj
But what exactly should we be measuring?
We know page load time is NOT necessarily correlate to UX.
examples of how onload does NOT correlate to UX
Amazon: http://www.webpagetest.org/result/150420_GV_E3/
Gmail: http://www.webpagetest.org/result/150420_S9_704a92a60b0b134daec3d42d649c3010/
We need metrics that more accurately measure the UX. They won’t be perfect until human brains fire JavaScript events.
https://www.flickr.com/photos/goincase/2220266628/in/photolist-4ocrV7-9VVXjZ-8fy57p-9VXuKx-feNNWa-ff47y9-feNNTF-nLarQF-9VW2PP-9VYLNQ-9W1j4A-nJm5dy-9VYN9m-9VRLJ4-8hYyha-9VYV3J-GnW5B-zyZxy-oagedz-9tDdWs-eizvPP-bqgVNX-9VYoh3-9VVxfr-9VW2fT-8c4wFn-9VVZXv-8hYt5H-8hYAMX-c2Ygh-jsLvXT-jsMYFD-84vT4z-8twLz9-jsNznU-8pghjG-7BGCEF-8P8gMg-8PbmJq-8Pbmww-993hrU-6jcP8W-6j8C1g-6jcMT5-6j8AEM-6j8Amc-6j8zUr-zyZuG-9VXtkD-as27uZ
We need metrics that focus on what the user sees!
https://www.flickr.com/photos/cataniamichele/2855661699/sizes/l
It's the price we pay to download huge images, right?????
NO! Hero images are typically download quickly but are delayed by JS & CSS.
"sweater" image finishes downloading at 2057.
500 ms before hero is rendered
https://speedcurve.com/test/150427_9S_16/hja21ghdsja6743ghjfdskjhs2133j/
"Evening" image finishes downloading at 618ms.
2697 ms before hero is rendered
https://speedcurve.com/test/150427_YF_132/hja21ghdsja6743ghjfdskjhs2133j/
"paris" bed image finishes downloading at 712 ms.
~700 ms before hero is rendered
sync scripts at bottom get promoted
https://speedcurve.com/test/150427_6A_PR/hja21ghdsja6743ghjfdskjhs2133j/
Notice these are BLOCKING scripts!
The rule "put scripts at the bottom" stopped mattering with IE8.
"paris" bed image finishes downloading at 712 ms.
~700 ms before hero is rendered
sync scripts at bottom get promoted
https://speedcurve.com/test/150427_6A_PR/
How do we know when the image rendered? Filmstrips!!
too early
It's not wrong, it's just answering a different question: "When did it finish downloading?"
too early
too early
too early
The only that works!
Those previous tests covered other slow (blocking) assets.
What if the image itself is slow?
And this brings us back to where we started - defining (and measuring) what matters most to the UX.
Because that’s what unites the entire team - creating a fantastic UX - which also means a FAST UX.
http://www.digitaljournal.com/img/1/8/1/6/4/9/i/1/3/8/o/P1100045.JPG
flickr.com/photos/myklroventine/4062102754/
"thank you" by nj dodge: http://flickr.com/photos/nj_dodge/187190601/
Verrazano-Narrows Bridge