The document discusses optimizing mobile web apps for performance and battery life. It outlines 5 tips: 1) Don't rely too heavily on network access due to high latency and battery drain. 2) Show content while loading to improve the user experience. 3) Leverage HTML5 features like localStorage, app caching, and web workers. 4) Offload animations and rendering to the GPU using CSS transforms where possible. 5) Keep the DOM simple and use event listeners carefully to improve efficiency. The document provides examples and recommendations for optimizing images, JavaScript, rendering, and the development process for better mobile web optimization.
We all know Mobile is different, but by how much?
This presentation attempts to quantify the difference between mobile and non-mobile, focusing on CPU, network and browser differences.
Slides for my Adobe MAX 2011 presentation on Optimizing Sites for Mobile Devices. In this hands-on lab, I explore the concept of developing a mobile strategy that approaches mobile as an equal partner in the design process, and explores techniques to help site content deploy across devices and contexts.
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.
We all know Mobile is different, but by how much?
This presentation attempts to quantify the difference between mobile and non-mobile, focusing on CPU, network and browser differences.
Slides for my Adobe MAX 2011 presentation on Optimizing Sites for Mobile Devices. In this hands-on lab, I explore the concept of developing a mobile strategy that approaches mobile as an equal partner in the design process, and explores techniques to help site content deploy across devices and contexts.
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.
Delivering Optimal Images for Phones and Tablets on the Modern WebJoshua Marantz
Evolving mobile hardware and networks have made it challenging for web sites to deliver an optimal experience to each client. If you send the same image to both a WiFi Retina tablet and a 3G phone, you compromise speed and bandwidth cost against image quality. We'll look at using HTML and CSS image markup, CDNs, HTTP caching directives and how WPO can deliver a great UX with minimal effort.
Presented at SCREENS 2013 in Toronto.
Details at fitc.ca/screens
In this talk, Digiflare lead iOS developer Justin Howlett will discuss the impact of performance on User Experience. Justin will discuss easy to implement platform agnostic techniques, technologies and libraries to improve your user experience through performance. Although most techniques and technologies are platform agnostic many of the case studies and examples will be presented in native Objective-C for iOS.
Raiders of the Fast Start: Frontend Performance Archaeology - Performance.now...Katie Sylor-Miller
Raiders of the Fast Start: Frontend Performance Archeology
There are a lot of books, articles, and online tutorials out there with fantastic advice on how to make your websites performant. It all seems easy in theory, but applying best practices to real-world code is anything but straightforward. Diagnosing and fixing frontend performance issues on a large legacy codebase is like being an archaeologist excavating the remains of a lost civilization. You don’t know what you will find until you start digging!
Pick up your trowels and come along with Etsy’s Frontend Systems team as we become archaeologists digging into frontend performance on our large, legacy mobile codebase. I’ll share real-life lessons you can use to guide your own excavations into legacy code:
What tools and metrics we used to diagnose issues and track progress.
How we went beyond server-driven best practices to focus on the client.
Which fixes successfully increased conversion, and which didn’t.
Our work, like all good archaeology, went beyond artifacts and unearthed new insights into our culture. We at Etsy pride ourselves on our culture of performance, but, like all cultures, it needs to adapt and reinvent itself to account for changes to the landscape. Based on what we’ve learned, we are making the case for a new, organization-wide, frontend-focused performance culture that will solve the problems we face today.
Talk delivered in New York, Sep 19, 2016 during an O'Reilly meetup before Velocity Conference about Web Performance and Images, including HTTP Client Hints and new Image Formats
Optimizing for a faster user experience Pt 2: How-to.James Christie
From my presentation "I feel the need..the need for speed: Optimizing the User Experience", given at UXPA Boston 2014. This is the second half of the talk. The first half (are we slow? How slow? Why? And Why That's a Problem) used a ton of animation and rapid patter, and just doesn't make much sense on SlideShare without audio. I need to upload that to YouTube, someday.
AWS Webcast - Accelerating Application Performance Using In-Memory Caching in...Amazon Web Services
This webinar covers both introductory as well as advanced topics related to ElastiCache and is intended for current memcached users as well as those already using ElastiCache. During this session we will go over various scenarios and use-cases that can benefit by enabling caching, discuss the features provided by ElastiCache, and review best-practices, design patterns, and anti-patterns related to ElastiCache. The webinar will also include a demo where we enable ElastiCache for a web application and show the resulting performance improvements.
Presented at Web Directions Code, Melbourne
If you have a website—particularly one that generates revenue for your organization—you need a Progressive Web App. So where do you begin? How do you decide which features of a Progressive Web App make sense for your users? What tools can make the process easier (or harder)? In this practical session, Jason will guide you through the key design decisions you’ll need to make about your Progressive Web App and how those decisions impact the scope of your project. He'll also teach you how to avoid common pitfalls and help you take full advantage of Progressive Web App technology.
Measuring Web Performance (HighEdWeb FL Edition)Dave Olsen
Today, a web page can be delivered to desktop computers, televisions, or handheld devices like tablets or phones. While a technique like responsive design helps ensure that our web sites look good across that spectrum of devices we may forget that we need to make sure that our web sites also perform well across that same spectrum. More and more of our users are shifting their Internet usage to these more varied platforms and connection speeds with some moving entirely to mobile Internet.
In this session we’ll look at the tools that can help you understand, measure and improve the web performance of your web sites and applications. The talk will also discuss how new server-side techniques might help us optimize our front-end performance. Finally, since the best way to test is to have devices in your hand, we’ll discuss some tips for getting your hands on them cheaply.
This presentation builds upon Dave’s “Optimization for Mobile” chapter in Smashing Magazine’s “The Mobile Book.”
This talk was given at HighEdWeb Florida.
2017 Silicon Valley Code Camp: Instant Mobile WebLisa Huang
Instant Mobile Web presentation for Silicon Valley Code Camp 2017.
Session: https://www.siliconvalley-codecamp.com/Session/2017/instant-mobile-web-an-accelerated-mobile-pages-primer
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.
When creating mobile apps, solid performance is now mandatory. We'll expose the patterns and anti-patterns that will impact this critical trait of your apps, while building a performant mobile app live.
This presentation was made in NextStep Global 2015. See the recording https://www.outsystems.com/nextstep/2015/mobile-apps-that-perform/
Everything You Know is Not Quite Right Anymore: Rethinking Best Practices to ...Dave Olsen
We’re entering a new era where an increasing number of devices with wildly divergent features -- including phones, tablets, game consoles, and TVs -- are connected to the Internet. As the way people access the Internet changes, there is an urgent need to rethink how we use the web to communicate. This doesn't mean creating separate solutions for each device but rather preparing our existing content to meet this increasingly unpredictable future. Dave Olsen and Doug Gapinski will share and examine examples that show how responsive design will help institutions rethink and adjust for the future-friendly web.
Primary topics that are covered are: understanding the reality of web development today, example RWD design patterns, and understanding how to test and optimize the performance of your RWD website.
Everything You Know is Not Quite Right Anymore: Rethinking Best Web Practices...Doug Gapinski
We’ve entered a new era where an increasing number of devices with wildly divergent features— including phones, tablets, game consoles, and TVs—are connected to the Internet. As the way people access the Internet changes, there is an urgent need to rethink how we use the web to communicate.
This doesn't mean creating separate solutions for each device but rather preparing our existing content to meet an unpredictable future. Responsive web design means changing how we plan and evaluate performance. Dave Olsen and Doug Gapinski share and examine examples to help institutions rethink and adjust for the future-friendly web.
Presenters
Dave Olsen
Professional Technologist, West Virginia University
Doug Gapinski
Strategist, mStoner
Delivering Optimal Images for Phones and Tablets on the Modern WebJoshua Marantz
Evolving mobile hardware and networks have made it challenging for web sites to deliver an optimal experience to each client. If you send the same image to both a WiFi Retina tablet and a 3G phone, you compromise speed and bandwidth cost against image quality. We'll look at using HTML and CSS image markup, CDNs, HTTP caching directives and how WPO can deliver a great UX with minimal effort.
Presented at SCREENS 2013 in Toronto.
Details at fitc.ca/screens
In this talk, Digiflare lead iOS developer Justin Howlett will discuss the impact of performance on User Experience. Justin will discuss easy to implement platform agnostic techniques, technologies and libraries to improve your user experience through performance. Although most techniques and technologies are platform agnostic many of the case studies and examples will be presented in native Objective-C for iOS.
Raiders of the Fast Start: Frontend Performance Archaeology - Performance.now...Katie Sylor-Miller
Raiders of the Fast Start: Frontend Performance Archeology
There are a lot of books, articles, and online tutorials out there with fantastic advice on how to make your websites performant. It all seems easy in theory, but applying best practices to real-world code is anything but straightforward. Diagnosing and fixing frontend performance issues on a large legacy codebase is like being an archaeologist excavating the remains of a lost civilization. You don’t know what you will find until you start digging!
Pick up your trowels and come along with Etsy’s Frontend Systems team as we become archaeologists digging into frontend performance on our large, legacy mobile codebase. I’ll share real-life lessons you can use to guide your own excavations into legacy code:
What tools and metrics we used to diagnose issues and track progress.
How we went beyond server-driven best practices to focus on the client.
Which fixes successfully increased conversion, and which didn’t.
Our work, like all good archaeology, went beyond artifacts and unearthed new insights into our culture. We at Etsy pride ourselves on our culture of performance, but, like all cultures, it needs to adapt and reinvent itself to account for changes to the landscape. Based on what we’ve learned, we are making the case for a new, organization-wide, frontend-focused performance culture that will solve the problems we face today.
Talk delivered in New York, Sep 19, 2016 during an O'Reilly meetup before Velocity Conference about Web Performance and Images, including HTTP Client Hints and new Image Formats
Optimizing for a faster user experience Pt 2: How-to.James Christie
From my presentation "I feel the need..the need for speed: Optimizing the User Experience", given at UXPA Boston 2014. This is the second half of the talk. The first half (are we slow? How slow? Why? And Why That's a Problem) used a ton of animation and rapid patter, and just doesn't make much sense on SlideShare without audio. I need to upload that to YouTube, someday.
AWS Webcast - Accelerating Application Performance Using In-Memory Caching in...Amazon Web Services
This webinar covers both introductory as well as advanced topics related to ElastiCache and is intended for current memcached users as well as those already using ElastiCache. During this session we will go over various scenarios and use-cases that can benefit by enabling caching, discuss the features provided by ElastiCache, and review best-practices, design patterns, and anti-patterns related to ElastiCache. The webinar will also include a demo where we enable ElastiCache for a web application and show the resulting performance improvements.
Presented at Web Directions Code, Melbourne
If you have a website—particularly one that generates revenue for your organization—you need a Progressive Web App. So where do you begin? How do you decide which features of a Progressive Web App make sense for your users? What tools can make the process easier (or harder)? In this practical session, Jason will guide you through the key design decisions you’ll need to make about your Progressive Web App and how those decisions impact the scope of your project. He'll also teach you how to avoid common pitfalls and help you take full advantage of Progressive Web App technology.
Measuring Web Performance (HighEdWeb FL Edition)Dave Olsen
Today, a web page can be delivered to desktop computers, televisions, or handheld devices like tablets or phones. While a technique like responsive design helps ensure that our web sites look good across that spectrum of devices we may forget that we need to make sure that our web sites also perform well across that same spectrum. More and more of our users are shifting their Internet usage to these more varied platforms and connection speeds with some moving entirely to mobile Internet.
In this session we’ll look at the tools that can help you understand, measure and improve the web performance of your web sites and applications. The talk will also discuss how new server-side techniques might help us optimize our front-end performance. Finally, since the best way to test is to have devices in your hand, we’ll discuss some tips for getting your hands on them cheaply.
This presentation builds upon Dave’s “Optimization for Mobile” chapter in Smashing Magazine’s “The Mobile Book.”
This talk was given at HighEdWeb Florida.
2017 Silicon Valley Code Camp: Instant Mobile WebLisa Huang
Instant Mobile Web presentation for Silicon Valley Code Camp 2017.
Session: https://www.siliconvalley-codecamp.com/Session/2017/instant-mobile-web-an-accelerated-mobile-pages-primer
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.
When creating mobile apps, solid performance is now mandatory. We'll expose the patterns and anti-patterns that will impact this critical trait of your apps, while building a performant mobile app live.
This presentation was made in NextStep Global 2015. See the recording https://www.outsystems.com/nextstep/2015/mobile-apps-that-perform/
Everything You Know is Not Quite Right Anymore: Rethinking Best Practices to ...Dave Olsen
We’re entering a new era where an increasing number of devices with wildly divergent features -- including phones, tablets, game consoles, and TVs -- are connected to the Internet. As the way people access the Internet changes, there is an urgent need to rethink how we use the web to communicate. This doesn't mean creating separate solutions for each device but rather preparing our existing content to meet this increasingly unpredictable future. Dave Olsen and Doug Gapinski will share and examine examples that show how responsive design will help institutions rethink and adjust for the future-friendly web.
Primary topics that are covered are: understanding the reality of web development today, example RWD design patterns, and understanding how to test and optimize the performance of your RWD website.
Everything You Know is Not Quite Right Anymore: Rethinking Best Web Practices...Doug Gapinski
We’ve entered a new era where an increasing number of devices with wildly divergent features— including phones, tablets, game consoles, and TVs—are connected to the Internet. As the way people access the Internet changes, there is an urgent need to rethink how we use the web to communicate.
This doesn't mean creating separate solutions for each device but rather preparing our existing content to meet an unpredictable future. Responsive web design means changing how we plan and evaluate performance. Dave Olsen and Doug Gapinski share and examine examples to help institutions rethink and adjust for the future-friendly web.
Presenters
Dave Olsen
Professional Technologist, West Virginia University
Doug Gapinski
Strategist, mStoner
The Server Side of Responsive Web DesignDave Olsen
Responsive web design has become an important tool for front-end developers as they develop mobile-optimized solutions for clients. Browser-detection has been an important tool for server-side developers for the same task for much longer. Unfortunately, both techniques have certain limitations. Depending on project requirements, team make-up and deployment environment combining these two techniques might lead to intriguing solutions for your organization. We'll discuss when it makes sense to take this extra step and we'll explore techniques for combining server-side technology, like server-side feature-detection, with your responsive web designs to deliver the most flexible solutions possible.
Todays web front-end applications architecture. All resources shared at the end of presentation.
Full sources on:
https://lnkd.in/gyQuFKK
https://lnkd.in/gZK8Sp3
The Dark Side of Single Page ApplicationsDor Kalev
The story of all the pitfalls we had while transferring FTBpro.com from the good old web to a Backbone single page application... and all the great solutions we've came up with
Lets look at an example of what a performant website can look like. This discuss what concepts should we be considering when looking at website performance. Next we will go over two areas pertaining to website performance: 1) website performance tweaks that you as a web developer can directly make 2) website performance tweaks that you may have to work with your hosting provider or IT department to achieve
Performance Optimization for Mobile Web | Fresh Tilled SoilFresh Tilled Soil
In this presentation Fresh Tilled Soil takes a discerning look at how the mobile web has been transformed to date, and where it will go from here. We'll talk about the latest tools for testing and debugging websites, newest HTML5/CSS3/JavaScript technologies, and the best strategies for mobile website performance & optimization. Finally, we’ll reveal some of the exciting, not yet released web API’s that will bring the mobile-web user experience to a whole new level!
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
20. ๏ MANY + LARGE HTTP REQUESTS
= MORE DATA
= MORE POWER USAGE
= HIGH BATTERY DRAIN
๏ UNNECESSARY ANIMATIONS
= HIGH USE OF CPU AND MEMORY
= MORE POWER USAGE
= HIGH BATTERY DRAIN
22. WWW 2012 – Session: Mobile Web Performance April 16–20, 2012, Lyon, France
Who Killed My Battery:
Analyzing Mobile Browser Energy Consumption
Narendran Thiagarajan† Gaurav Aggarwal† Angela Nicoara*
naren@cs.stanford.edu agaurav@cs.stanford.edu angela.nicoara@telekom.com
Dan Boneh† Jatinder Pal Singh‡
dabo@cs.stanford.edu jatinder@stanford.edu
†
Department of Computer Science, Stanford University, CA
*
Deutsche Telekom R&D Laboratories USA, Los Altos, CA
‡
Department of Electrical Engineering, Stanford University, CA
ABSTRACT sites are poorly optimized for energy use and rendering them in the
Despite the growing popularity of mobile web browsing, the energy browser takes more power than necessary. Partly this is due to a
consumed by a phone browser while surfing the web is poorly un- weak understanding of the browser’s energy use.
derstood. We present an infrastructure for measuring the precise In this paper we set out to analyze the energy consumption of
energy used by a mobile browser to render web pages. We then the Android browser at popular web sites such as Facebook, Ama-
measure the energy needed to render financial, e-commerce, email, zon, and many others. Our experimental setup includes a multi-
blogging, news and social networking sites. Our tools are suffi- meter hooked up to the phone battery that measures the phone’s
ciently precise to measure the energy needed to render individual energy consumption as the phone loads and renders web pages. We
web elements, such as cascade style sheets (CSS), Javascript, im- patched the default Android browser to help us measure the precise
ages, and plug-in objects. Our results show that for popular sites, energy used from the moment the browser begins navigating to the
downloading and parsing cascade style sheets and Javascript con- desired web site until the page is fully rendered. The patch also lets
sumes a significant fraction of the total energy needed to render the us measure the exact energy needed to render a page excluding the
page. Using the data we collected we make concrete recommen- energy consumed by the radio. Our setup is described in detail in
dations on how to design web pages so as to minimize the energy Section 2. In that section we also describe the energy model for the
needed to render the page. As an example, by modifying scripts on phone’s radio which is similar to models presented in [18, 10].
the Wikipedia mobile site we reduced by 30% the energy needed to Using our experimental setup we measured the energy needed
download and render Wikipedia pages with no change to the user to render popular web sites as well as the energy needed to render
experience. We conclude by estimating the point at which offload- individual web elements such as images, Javascript, and Cascade
ing browser computations to a remote proxy can save energy on the Style Sheets (CSS). We find that complex Javascript and CSS can
be as expensive to render as images. Moreover, dynamic Javascript
26. Network
• High latency.
• Bandwidth costs money
(for all parties).
• Might not be there.
• It will definitely drain
the battery.
http://www.flickr.com/photos/robert-dolan/3864148280/
27. How do you
solve a
problem like
the network?
Do everything Steve
Souders tells you to.
28. • Enable Gzip.
• Reduce number of
requests.
• Reduce size of
responses.
• Expires Headers / Etags
• Use a CDN.
• Deliver device specific
content.
• Don’t use the network
unless we absolutely
positively need to.
29. Images
• Optimization tools (ImageOptim,
ImageAlpha).
• Sprites to reduce requests.
• Device specific images.
• Base64 inline (pros & cons).
• CSS and Unicode Glyphs to replace images.
• CSS image masks for alpha.
34. HTML5
• LocalStorage
• AppCache
• Network / Connection API
• Battery API
• Web workers and shared web workers
• Things we don’t need libraries for:
• JSON, QuerySelector, ClassLists
37. The GPU
• translate3d, scale3d, rotate3d
• Beware of the 1024px texture size limit
• Interaction between the CPU and GPU
• Don’t load too much on to it (~10Mb total
storage)
38. Rendering and Updates
• Avoid reflows
• Carefully use opacity/transparency fades.
• requestAnimationFrame
41. Build
process
• Build process
• Testing and
debugging
http://floridakeysgirl.com/wp-content/uploads/2010/10/IMG_1147-e1288555102991.jpg
42. Debugging and Testing
• Desktop Webkit
• Simulator / Emulators
• weinre - WEb INspector REmote
• Charles proxy
• Mobile Perf Bookmarklet (YSlow, DOM
Monster)
• PhantomJS, Selenium
• Real devices, with real OSs
43. Recap
• Prime Directive: Respect the battery.
• #1 Don’t rely too much on the network.
• #2 Show something while loading.
• #3 Use HTML5 extensions.
• #4 Use hardware acceleration.
• #5 Keep the DOM simple. Use event listeners
carefully and appropriately.
I’m going to start by talking about how I got here and why I’m up here talking about Building awesome mobile web apps.\n\nTraditionally I’m a full-stack web dev\nOver the past few years a I’m chosen my side, said good bye to PHP and MySQL\n and focusing on frontend.\n\nToday I work for Disney Interactive, building HTML5 games, \nBefore this I worked for Tapulous of the successful ‘Tap Tap Revenge’ franchise. \n\n\n
\n
I used to work for these guys. I worked on building websites for a few large broadcasters including the BBC and BSkyB. I also did a fair bit consultancy and freelancing work too.\n
Today work for Tapulous, makers of the successful ‘Tap Tap Revenge’ franchise. Tapulous is also part of Disney Mobile who make games such as ‘Where’s My Water’ and ‘Pirates of the Caribbean’.\nCorporate Inception\n\n
\n
Ok what do we mean by a mobile web app?\n\n1). Could be a standalone web app running in Mobile Safari, Chrome, Firefox, Opera Mobile or Windows Mobile 7 browser. Simply accessed via a URL\n\n2) The web app could be part of Native App and presented with a WebView container. The web app my represent all or just part of the main App.\n\nOur HTML, CSS, JavaScript and other assets may be packaged within the app or delivered via a network.\n\nThese include Ads, news, dynamic content.\n\nExamples include the iTunes store app, iAds.\n
Ok what do we mean by a mobile web app?\n\n1). Could be a standalone web app running in Mobile Safari, Chrome, Firefox, Opera Mobile or Windows Mobile 7 browser. Simply accessed via a URL\n\n2) The web app could be part of Native App and presented with a WebView container. The web app my represent all or just part of the main App.\n\nOur HTML, CSS, JavaScript and other assets may be packaged within the app or delivered via a network.\n\nThese include Ads, news, dynamic content.\n\nExamples include the iTunes store app, iAds.\n
Ok what do we mean by a mobile web app?\n\n1). Could be a standalone web app running in Mobile Safari, Chrome, Firefox, Opera Mobile or Windows Mobile 7 browser. Simply accessed via a URL\n\n2) The web app could be part of Native App and presented with a WebView container. The web app my represent all or just part of the main App.\n\nOur HTML, CSS, JavaScript and other assets may be packaged within the app or delivered via a network.\n\nThese include Ads, news, dynamic content.\n\nExamples include the iTunes store app, iAds.\n
Ok what do we mean by a mobile web app?\n\n1). Could be a standalone web app running in Mobile Safari, Chrome, Firefox, Opera Mobile or Windows Mobile 7 browser. Simply accessed via a URL\n\n2) The web app could be part of Native App and presented with a WebView container. The web app my represent all or just part of the main App.\n\nOur HTML, CSS, JavaScript and other assets may be packaged within the app or delivered via a network.\n\nThese include Ads, news, dynamic content.\n\nExamples include the iTunes store app, iAds.\n
Let me start by defining what I think a mobile web app is.\nCos those last screenshots didn’t look Web, cos they not.\n
Google maps, Twitter, Facebook, LinkedIn\nSingle page load with lots user interaction\n
Native App with webviews.\nNetwork loaded or prepacked\nTap Tap Revenge, Tap Tap Glee, LinkedIn\nApple use web views too for iTunes, iAd and many other apps.\nPhonegap - Great for cross device and app store discovery.\n\n
A lot of this talk is about things problems which I encountered over the past 2 years\nand possible solutions we found. How HTML5 Helps\n
I like to think of the Mobile web as the Wild West, everyone is rushing to stake a claim.\nLots of experimentation\nNew device APIs being built.\nFast paced change.\nCompeting technologies and platforms.\nIn some ways there is also an element of history repeating itself. 90s-2000s\nAlso a battle between Native and Web components.\n\n
I said I was going to talk about this, but what...\n
It’s kind of fitting, since Disney is all-about giving great guest experiences.\n\nThis is what all web app developers want to do. However on mobile we have a few challenges...\n\nI hope the same applies to this talk.\n\nGreat / fast apps make more money\n
\n
The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
The first thing we have to deal with is a user’s exceptions. In the mobile world they are kind of spoilt by native apps and expect a web app to look and feel as responsive. This exception is quite different from the normal web, where users click links and spend time reading. On the mobile, the user is probably going to spend less time reading and more time navigating, so we need to react quicker.\n\nSo we need to over a level of refinement which are as close to a native view as possible, but still have the dynamism of a web view. If we transition from a Native view to a web view we want to avoid avoid a jarring experience. One thing which I’m not intending to talk about is how we can make out web view look like a native App, this is non-trial and in the case of Android there are so many different skins and user experiences that I’m not touching that with a 10 foot pole.\n\nAt the same time as matching a users expectations we need to deal with the mobile network, which ain’t the same a hardline.\n\nOther factors include the limited CPU and Memory resources which are available on a mobile device. Also not all devices are equal, so something which is performant on one device might not be the same on another. \n\nThis kind of leads us on to the next point. With the advent the high density displays such as the Retina display we now have device pixel ratios of 2x, 1.5x and 1x depending on the device.\n
Mobile devices have processors which are less powerful than desktops.\nLess RAM\nA mobile phone’s spec is closer to a computer 5 years ago.\n
Multiple densities 1x, 1.5x, 2x\n2x => 4 times the pixels which means more data.\nA pixel is not a pixel\n\n
Mobile devices of course often reply on cellular networks.\nThey getting faster. They are still a lot slower than Ethernet or Broadband.\nAlso if we using public WiFI, generally these are also pretty slow too. \n
Finally, Mobile users have become accustomed to Native interfaces, which are responsive \n
Like blackboxes.\nIt’s hard to see how things are running on them.\nWether it is Debugging or Performance optimization.\n\n
Someone said HTML5 didn’t work for them.\nNon technical challenge.\nget rid of preconceptions.\n
All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
All this ==> Crappy user experience\n\nThings that the user will notice right away.\n
Not only that... It gets worse... What might a user notice later...\nLets also think about some side effects\n\nData usage - we don't want to abuse a user's quota.\nBattery life - lets not run a user's device battery down unnecessary.\n\nHere are real world example...\n
Not only that... It gets worse... What might a user notice later...\nLets also think about some side effects\n\nData usage - we don't want to abuse a user's quota.\nBattery life - lets not run a user's device battery down unnecessary.\n\nHere are real world example...\n
Not only that... It gets worse... What might a user notice later...\nLets also think about some side effects\n\nData usage - we don't want to abuse a user's quota.\nBattery life - lets not run a user's device battery down unnecessary.\n\nHere are real world example...\n
\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Lets look at what might be going on\n\nOh! there is a common theme.\nCause and Effect\n\nOccam's Razor\n\n\n
Be nice to a device's battery - Save energy.\nSingle most important rule which we MUST obey when building a mobile web App.\nThis is why Flash is not on the iOS. \nThe one thing which has changed little for the modern smart phone over the past 3 years in how long the battery lasts on a single charge.\n\n\n
Be nice to a device's battery - Save energy.\nSingle most important rule which we MUST obey when building a mobile web App.\nThis is why Flash is not on the iOS. \nThe one thing which has changed little for the modern smart phone over the past 3 years in how long the battery lasts on a single charge.\n\n\n
It’s not just me talking about this.\n
There a lots of optimization which we can make to our web app, some with have a greater impact on perceived performance than others. It’s useful to identify what techniques are going to most befit your users and work in implementing them first. There is no point on worrying about things way down here if you haven’t got the big stuff sorted.\n
\n
We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
We can single out crunch points in our app.\nBasically there are 2 high level areas\nThen individual components which can be optimized.\n
Of course if your app loads assets from the device then you can help minimize the load right off the bat. This is not always possible for example Browser based apps. There are also other reason why you may not want to do this, such as initial download size, keeping this content update etc.\n
\n
Why is it so bad?\n
Bandwidth costs money (for all parties).\n\nThe network also impacts our Load phase, which is in most cases the slowest.\n\nUsers don’t always have good connection Think London Underground / Metro.\n\nJust spinning up the 3G attanna costs power.\n
Bandwidth costs money (for all parties).\n\nThe network also impacts our Load phase, which is in most cases the slowest.\n\nUsers don’t always have good connection Think London Underground / Metro.\n\nJust spinning up the 3G attanna costs power.\n
Bandwidth costs money (for all parties).\n\nThe network also impacts our Load phase, which is in most cases the slowest.\n\nUsers don’t always have good connection Think London Underground / Metro.\n\nJust spinning up the 3G attanna costs power.\n
Bandwidth costs money (for all parties).\n\nThe network also impacts our Load phase, which is in most cases the slowest.\n\nUsers don’t always have good connection Think London Underground / Metro.\n\nJust spinning up the 3G attanna costs power.\n
This is may be obvious. But in the mobile world simple network optimizations matter a LOT!\n\nThere are so many things we can do...\n
This is may be obvious. But in the mobile world simple network optimizations matter a LOT!\n\nThere are so many things we can do...\n
This is may be obvious. But in the mobile world simple network optimizations matter a LOT!\n\nThere are so many things we can do...\n
This is may be obvious. But in the mobile world simple network optimizations matter a LOT!\n\nThere are so many things we can do...\n
Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
Enable Gzip - yep this one is so obvious, but it’s just a reminder.\nReduce number of requests...\n\nApplies to images, src, API data.\n\n\n\n
Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
Device specific: You can use @media ‘device-pixel-ratio’\nA problem this with is if you are also using cache manifests.\n\nUse CSS gradients, border-radius, ::before and ::after content to replace images.\n\nCSS marks demo\n
\n
\n
\n
\n
\n
\n
\n
\n
Use a local version getItems.\n
This sounds like a cop out, but sometimes it unavoidable.\nShow something sooner and indicate progress.\n\n\n
Lets look at the usage cycle of a web app...\n\n\n
Lets look at the usage cycle of a web app...\n\n\n
Lets look at the usage cycle of a web app...\n\n\n
Lets look at the usage cycle of a web app...\n\n\n
Lets look at the usage cycle of a web app...\n\n\n
Lets look at the usage cycle of a web app...\n\n\n
Lets look at the usage cycle of a web app...\n\n\n
Lets look at the usage cycle of a web app...\n\n\n
What is Cool about Mobile is\nOne beast has been slain\nLess legacy - People don’t keep there phones for long, unlike desktop IE.\nBring on HTML5...\n
Lets look at some of tools that HTML5 gives us to bring this all together.\n\n
LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
LocalStorage - KeyValue store, text content, 5Mb limit, well supported, lots of uses, Bing used it to store JavaScript and CSS content\nI use lot for caching JSON data.\n\nAppCache - can be useful, it’s very fiddly, but once you figure it out then it will help you a bit. The common consensus is that it needs more work.\n\nNetwork API - onLine / offLine checking and events\nConnection goes further - type off connection 3G, 4G, wifi - not well supported. \n\nBattery API - Samsung implemented, very early. \n\nWeb workers - Are good if you have a computational task which you don’t want to block UI thread.\n\n
Compablity\n
\n
\n
http://microjs.com/\n\nUse micro library, know what the library does.\n\nKnow the quality of the code.\nAvoid duplication of functionally.\n\nzepto, when.js, require.js, backbone.js...\n
http://microjs.com/\n\nUse micro library, know what the library does.\n\nKnow the quality of the code.\nAvoid duplication of functionally.\n\nzepto, when.js, require.js, backbone.js...\n
http://microjs.com/\n\nUse micro library, know what the library does.\n\nKnow the quality of the code.\nAvoid duplication of functionally.\n\nzepto, when.js, require.js, backbone.js...\n
http://microjs.com/\n\nUse micro library, know what the library does.\n\nKnow the quality of the code.\nAvoid duplication of functionally.\n\nzepto, when.js, require.js, backbone.js...\n
\n
\n
Whats happened is our big data payload request 16 is now coming from Localstorage and the other assets are coming for the AppCache.\n\nThere is still an issue with the parse time.\n\n
So lets take a look at a couple of things which will affect a user’s experience interacting with our app after it has loaded.\n\nFirst up animation. I mentioned that we have limited hardware resources available, one thing we do have access it the device’s GPU (Graphics Processing Unit).\n\nIn the reality we shouldn’t be trying to do any kind of animation on a mobile device unless we can offload it to the GPU.\n
We can make an element H/W accelerated by applying a CSS transform. This puts it on to the GPU as a surface or texture.\n\ndon’t put too much on it as this will cause textures to get flushed.\n\n
We can make an element H/W accelerated by applying a CSS transform. This puts it on to the GPU as a surface or texture.\n\ndon’t put too much on it as this will cause textures to get flushed.\n\n
We can make an element H/W accelerated by applying a CSS transform. This puts it on to the GPU as a surface or texture.\n\ndon’t put too much on it as this will cause textures to get flushed.\n\n
We can make an element H/W accelerated by applying a CSS transform. This puts it on to the GPU as a surface or texture.\n\ndon’t put too much on it as this will cause textures to get flushed.\n\n
Repaints can occur when ever a DOM style is updated.\nReflows (things like resizing of elements) can be more costly as they have to recalculate all the elements on the page.\n\nAvoid box shadows - Use border image or add element to a parent container and then don’t animate the contents so the can be saved as a texture.\n\nAvoid un-rendered content i.e. text-indent: -99999em - this makes the device render a large panel\n\nrequestAnimationFrame not tided to the UI thread, can be put to sleep / shutdown by the device. \n
Repaints can occur when ever a DOM style is updated.\nReflows (things like resizing of elements) can be more costly as they have to recalculate all the elements on the page.\n\nAvoid box shadows - Use border image or add element to a parent container and then don’t animate the contents so the can be saved as a texture.\n\nAvoid un-rendered content i.e. text-indent: -99999em - this makes the device render a large panel\n\nrequestAnimationFrame not tided to the UI thread, can be put to sleep / shutdown by the device. \n
Repaints can occur when ever a DOM style is updated.\nReflows (things like resizing of elements) can be more costly as they have to recalculate all the elements on the page.\n\nAvoid box shadows - Use border image or add element to a parent container and then don’t animate the contents so the can be saved as a texture.\n\nAvoid un-rendered content i.e. text-indent: -99999em - this makes the device render a large panel\n\nrequestAnimationFrame not tided to the UI thread, can be put to sleep / shutdown by the device. \n
RE-USE DOM ELEMENTS.\n\nUse touch events - Don’t use mouse events, these incur a 300ms delay. Bill Fisher’s talk yesterday covered some really great ways to deal with touch events.\n\nAlso the when placing listeners. Its generally to add them to a single parent not rather than to individual elements. Libraries like Zepto or JQuery help you with this though Delegate and Live.\n\nTake advantage of the Event model, capture and bubble phase.\n\n
Use touch events - Don’t use mouse events, these incur a 300ms delay.\n\nAlso the when placing listeners. Its generally to add them to a single parent not rather than to individual elements. Libraries like Zepto or JQuery help you with this though Delegate and Live.\n\nTake advantage of the Event model, capture and bubble phase.\n\nclosures\n
\n
You will need some kind of build process. I personally use ANT, cos I’m a sucker for XML, but you can use make, rake, jake... What’s important is that you need some kind of tool to transform your src code into something which you can deploy.\n\nWhat do we make our build do:\nResolve JS dependencies, concat, uglify, SASS\nBuild cache manifests.\nRun tests, JSLint, Jasmine + PhantomJS\nDeploy\n\nIssues you can find in minified code.\n\nBuild macros, pre processes.\n\ndebug and release builds.\n\n\n
You will need some kind of build process. I personally use ANT, cos I’m a sucker for XML, but you can use make, rake, jake... What’s important is that you need some kind of tool to transform your src code into something which you can deploy.\n\nWhat do we make our build do:\nResolve JS dependencies, concat, uglify, SASS\nBuild cache manifests.\nRun tests, JSLint, Jasmine + PhantomJS\nDeploy\n\nIssues you can find in minified code.\n\nBuild macros, pre processes.\n\ndebug and release builds.\n\n\n
Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
Istat Menu\nTest in the real world\nAvoid the latest and greatest (aka 4S and 5)\n
\n
\n
\n
\n
\n
\n
\n
\n
We are trying make 5* apps which people will tweet and blog about.\nOptimization is just a piece of the puzzle.\n