3 Tips to Deliver Fast Performance Across Mobile Web
On-Demand Webinar
Seems like everyone’s doing Responsive Web Design these days! Are you using React, Angular or others to create a mobile-friendly web experience?
Newsflash: Mobile-friendly doesn’t always equal customer-friendly, when it comes to performance. We’re talking about 60% of your traffic—how do you avoid disaster?
Learn the basics of high-performance mobile development through the examination of real-world, performance-killing code examples. You’ll also hear about:
Why 4.5 seconds on Chrome can be 15 seconds on a Galaxy S5 Chromium
How to identify major issues within mobile page construction
Best practices for managing CSS and JavaScript
Things to consider going global with your Web application
Join web performance experts Klaus Enzenhofer and Stefan Baumgartner from Dynatrace to ensure your mobile properties are delighting your customers!
Unleash Your Potential - Namagunga Girls Coding Club
3 Tips to Deliver Fast Performance Across Mobile Web
1. 3 Tips to Deliver Fast Performance
Across Mobile Web
Please Standby: Webinar to Begin
Shortly
Unable to listen via your speakers? Dial in:
Toll Free: 1 (866) 952-8437
Access Code: 888-100-511
International: Click “telephone” in audio section,
then click “additional numbers”
2. 3 Tips to Deliver Fast Performance
Across Mobile Web
Klaus Enzenhofer
Senior Technology Strategist, Dynatrace
Stefan Baumgartner
Web Development, Dynatrace
3. 3 Tips to Deliver Fast Performance
Across Mobile Web
Stefan Baumgartner @ddprrt
Klaus Enzenhofer @kenzenhofer
6. Network
Same Page
4.5 sec 15 secSanity Check
Browser CheckChrome 49 Chrome Mobile 33
Server Side
Local WLANLocal WLAN
Only difference is Browser & Device
7. Why did they look at the performance
on the mobile device?
16. Let‘s take a look at the timings!
Navigation Start: 0 ms
Domain Lookup End: 269 ms
Connect End: 330 ms
Response Start: 517 ms
Response End: 518 ms
Dom Loading: 519 ms
Dom Interactive: 519 ms
DomContentLoaded Event End: 520 ms
Dom Complete: 520 ms
30. Single page application frameworks are aware
of this trend
- As long as you have valid routes (= URLs), you have
the ability to render the state on the server
- The first two requests are the document and the
styles of your application
- Then the JS framework kicks in
55. <img src=”screenshot-600.png”
srcset="screenshot-200.png 200w,
screenshot-400.png 400w,
screenshot-600.png 600w,
screenshot-800.png 800w,
screenshot-1000.png 1000w,
screenshot-1200.png 1200w,
screenshot-1400.png 1400w,
screenshot-1600.png 1600w”
sizes="(min-width: 900px) 50vw, 100vw"
alt=”Super screenshot of our product.">
These sources are available. For each “width unit”
there’s a reduced version of our original screenshot
The sizes define which source to choose from. Retina screens
are also checked
A low-res fallback image for browsers that don’t know srcset
73. 4.5 sec 15 sec
UserDeveloper Operator
UserDeveloper Operator
How to?
2.5 sec2 sec
Happy Developer != Happy User
Your user might travel and mobile data is expensive
The returning user will appriciate your
caching strategy
74. You don‘t know how happy your users are?
https://www.dynatrace.com/trial/
76. Connect with us!
Participate in our Forum :
community.dynatrace.com
Like us on Facebook :
facebook.com/dynatrace
Follow us on LinkedIn :
linkedin.com/company/dynatrace
Follow us on Twitter :
twitter.com/dynatrace
Watch our Videos & Demos :
youtube.com/dynatrace
Read our Blog :
application-performance-blog.com
Editor's Notes
Austrians that love Performance
Were sitting together in the same classrooms at University
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…
Response Time story:
What does < 3 sec response time mean? Does it mean your app’s complete, or does it start loading. User Exerpience vs Developer Experience. SLA fulfilled
Truth is: Most SPAs kick in after “on load” the ”fun” starts here.
0 sec Response time blank screen
What if JS does not load
Your app depends on stable connection and high JS computational power
Solution: Progressive Rendering. Server side first. JS kicks in later
Two resources to load: Critical CSS file (Styles for main view), Finished HTML Suddenly Response time is important again
Everything then is Async and highly questionable
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…
UX vs DX
Alright Klaus, let’s take a look at the user first… why is the user still wearing his sad face even though our SLA seems to be fulfilled.
Well it’s most likely due to the fact the user is seeing something like this. Can you figure out what this application should do? No? Me neither… That’s because it’s missing one vital part to be of use: The content. So why is this happening?
Let’s see how an URL request is constructed. You all have seen this before. We do a DNS lookup to see where we get our resources from, connect to the server, let the server handle the response and download the resource. Usually, the first request you’re doing is to an HTML page that contains all the markup and references to the content we want to display.
So once this first HTML file is downloaded, we have the ability to control what’s happening in the front-end.
With a single page application framework we usually do something like this: Downloading the framework’s JavaScript file! Resulting in a blocking request until we get some content on screen.
We’re also downloading our own application of course, resulting in much likely a more longer request than before. Still blocking until we get some contents on screen. On mobile, this takes even longer because of network latency. Every request adds several round trips until you get to an actual response. And I’m just counting the response time of the resources here, not the time it needs to actually interpret and execute the JavaScript code that we just downloaded.
Once this is done, we finally see the content rendered. This can take up to several seconds. If you follow the guidelines of your framework, you load the JavaScript files and the end of your application, and most likely asynchronous and deferred. Which means that those requests don’t add up to the response time.
The actual response time of your application triggers when the original HTML file is downloaded! Resulting in this huge gap between response time and perceived render time.
Even worse… there’s the possibility that some of your code might break. Or imagine having a flaky internet connection, where some requests just get cancelled and won’t get transferred at all. This can happen on mobile. More often than we like. The result? Your user triggering a 500 mill response time but waiting for ages to actually see something.
So why not use the first request and try to get the most important thing out there before we request the application: Content for the visitor.
Deliver the most important content with the first request, everything that comes after that is just an enhancement.
This is a trend all major single page applications frameworks are aware of. Every framework now uses routes, which are de facto URLs, to keep the state of the application. With those routes, they also have the opportunity to render said state on the server. So the first request that you receive on the client is actually a server-rendered version of the state the JS app would deliver once it’s loaded. Just then, the JavaScript framework and application is loaded and kicks in.
Let’s take a look into that in detail.
Usually, we request the app, it delivers a static HTML file, we request the JavaScript application, and after that’s rendered, we make calls to an API server. Classic SPA.
With server side rendering we want to make the first response count. Deliver everything that is needed to actually see content and allow the user to interact with the application. Then the JavaScript application loads and takes over. Perfect idea of progressive enhancement with single page applications!
There are lots of solutions already out there. If you use Ember, having server side rendering comes for free. You install Fastboot, and fastboot does everything for you.
It’s a little more complex in the React ecosystem. As usual, you have lots of choices which are all varying in the details. Also, there’s no switch-on solution, you have to do a lot by yourself. On the plus-side: There are solutions that work with other server environments than Node.js.
Angular 2 also has a server side rendering solution called “Universal Angular 2”, which is pretty much in the vein of Ember’s fastboot.
So with that, we make our user somewhat happier... But we still have a sad operator
UX vs DX
1. Bandwidth topic and dataplan
2. “Klausi did a Journey”. Australia story 4$ per MB
3. What does my site cost www.whatdoesmysitecost.com
4. Roaming???
5. Local: Income vs data plan
6. Header vs Payload HTTP1 Problem
Solutions:
Reduce to essentials Tooling Uncss, Treeshaking, Do I need this fancy pop-up?, Responsive Images
You know that already, there’s lots of ways to reduce the payload we’re sending to the client. Running your images through ImageOptim, minifying and gzipping your CSS and JavaScript, all things that are by the book. So let’s what else can we do and what’s directly geared towards mobile web.
First, there’s responsive images.
The idea of responsive images is that you have a ton of different screen sizes, why download the same image to all those varying screens. Why not tailor the payload of an image as well as the content of an image to the screen at hat. The Responsive Images Community Group did an outstanding work in specify a standard. There’s a lot to this standard, including new elements and new browser algorithms, but I want to show you a quick example that’s sort of a quick win with Responsive images.
So.. This is a spiced up image element. The colored parts are brand new. You see a property called “srcset” and one called “sizes”, and they all feature different values.
The srcset property features a list of images that are defined for a certain “width unit”. I call it width unit because it’s not pixel on Retina screens. So this is the set where the browser can choose the images from. The sizes property define the rules which image to choose. First we start with the exception, which says that at a minimum resolutin of 900px, take a screenshot that’s at least half the width of the viewport. For all other cases, take one that’s at least 100% of the viewport. The browser evaluates those rules, gets a width unit value, and selects one of the images defined above. If the browser doesn’t know those properties, he still falls back to the original src attribute. As easy as that. Quick win for reducing the payload on smaller screens.
Next, reduce styles. The advanced edition. Not only can you reduce stylesheets by minifying and gzipping them, but there’s also a nice tool out there that allows us to filter styles that aren’t used.
It’s called UnCSS and is super helpful if you use frameworks like bootstrap. Bootstrap comes with a gazillion of components, but most sites only use roughly 20% of it. This tool checks which parts of this framework are used on that page, the rest is removed.
Last, but not least, there’s a new technique out there called tree shaking, which is something like UnCSS but for JavaScript, especially if you use the new ES16 standard.
Take a look at the code. With ES16 you are able to do modules, and export various functions from a module. The code on the upper left is a “math” library. In our application code in the lower left corner, we just import one function from this library, namely “cube”. The output on the right is a bundle created through tree shaking. Instead of including the whole “math.js” file, we just include the part that we need. This can reduce your application code significantly. And all major frameworks are going to build up on that. Which means even more reduced application files in the future!
Tools that support tree shaking already are things like Rollup.js
And Google’s Closure compiler… this godfather of JavaScript minifying tools is also the one that’s being used in AngularJS 2.
Alright, … so we came down to reducing the costs and the requests and the payload. User is happy because he’s getting a fast app, and the operator is getting a much smaller bill than before.
But this is just for the first view.. Let’s do something for the returning visitor to pump our game up even more. You know by now that you should find good cache headers and aim for leaving as much content on the client, rather than requesting in further and further… but there’s one new thing that you can use which ups your offline game even more, and especially on mobile.
It’s called service worker… let me show you quickly how this works:
Su, usually the browser is request a resource from the world wide web. That’s the blue arrow. The response delivers this resource to the client, and the client stores it in the cache.
With service workers, you have a man in the middle which can check each request and can help you modifying it. So instead of talking to the web server directly, the service worker passes each request through, and checks if it should do something with it. A typical call is browser does a request… service worker analyises this request and passes it to the webserver. The response is getting stored into a cache by the service worker and delivered to the client.
So… let’s assume the web server is down... Or not reachable because your client is offline. In that case, the service worker sees that the connection is not there, and will request the resource from the cache instead from the web. The biggest benefit compared to existing solutions: This works offline. No internet connection required!
Here’s some sample code. I don’t want to get too much into detail given the time, but registering a service worker is done with the appropriate call… A service worker is nothing more than a JavaScript file that uses certain APIs. This service worker now is getting installed and is avaiable to the client.
The upper portion of the code creates a cache on install. It also tells the cache which resources to store. The second portion of the code listens on each fetch request. Everytime a resource is requested, the service worker checks if there’s something in store, otherwise it will pass it to the network. This adds offline functionality to your app!
This is of course just a basic scenario. If you need more, I highly recommend going to the service worker toolbox. It provides a great API and lots of recipes for advanced use cases
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…
Gleiche Bedingungen. Only difference: Device and Browser!
HTTP2 vs HTTP1
More Calculation Power
…