Mobile CSS3: Pointers and Pitfalls in the mobile space

Slides: estelle.github.com/mobileperf/30.html
Name: Estelle Weyl
Blog: standardista.com
Twitter: @estellevw

Latency

Step 1: Don't Redirect!!!!

Step 2: Reduce Requests

Sprites

Memory

High memory usage causes a slow UI

When you are out of memory, you are out of memory

Browser crashes to free up memory

Sprites: Best choice?

Not enough to GZip

Rendered media are still the same size.

Reduce File Size
Reduce Image Size

Video, Audio, Images and Text can be compressed to save bandwidth, but they're uncompressed in the browser.

Reduce File Size

Image Alpha

Reduce Image Size

Don't send big images to small screens?
Images 1024px or bigger are too big for memory

sencha uses user agent sniffing,not browser size

Change your user agent and click on links above

CSS Masking

jpeg plus framemask less than transparent png
88KB + 4KB < 551KB

div {
  background-image:url(images/frame.jpg);
  -webkit-mask: url(images/framemask.png);
}

Masking example

Download Zip

Is CSS3 the Solution?

Properties

rounded Corners
box-shadow
text-shadow
background-position
background-repeat
multiple background images
border-image
gradients
@media queries

Benefits

Fewer HTTP Requests
Updatable
Scalable
Transitionable
Animatable
Fewer DOM Nodes

CSS3 ISN'T always the Solution!

UI Features can ruin your web app

Enlarged Fonts
Box Shadow (inset)
Text Indent
Gradients
background-size: cover
Sprites (of large images)
‘Non-rendered’ content
Recalculating / Repainting the UI

Static images may render faster than CSS effects

Fonts

Large and Small Fonts

Open it!

Large and Small Fonts

www.fontsquirrel.com

Shadows

Not rendered as static bitmap
Evaluated each repaint

Shaders

Visit Site

Text-indent

MyLogo Text

Logo

Use CSS Clip
Position text up instead of left

Large Gradients

Keep gradients small
Requires CPU to create
Stored in memory
Memory: Radial > Linear
Render Speed:
Images often faster than Gradients

transitions

code {
   color: black;
   font-size: 85%;
   background-color: rgba(255,255,255,0.9);
   transition: all 2s ease-in 50ms;
}
code:hover {
   color: red;
   font-size: 120%;
   background-color: rgba(255,255,255,0.8);
}

Requires reflow!

transitions with transforms

code {
   color: black;
   font-size: 85%;
   background-color: rgba(255,255,255,0.9);
   transition: all 2s ease-in 50ms;
}
code:hover {
   color: red;
   transform: scale(1.4);
   transform-origin: 0 0;
   background-color: rgba(255,255,255,0.8);
}

Only repaints

Hardware Acceleration: 3d Transforms

 div {
  transform: translateZ(0);
 }

translateZ(0)

Composited mage in memory == H x W x 4

Take advantage of hardware acceleration, but don't abuse it. GPU accelerated elements eat video memory

Images

Use background images, instead of foreground images.

Background images are first rendered with image data send to Core Animation. Safari doesn't render <img> first. The decoded image file is sent, as is, pre-rendered, to the Core Animation as a new layer. Foreground images is sent to Core Animation as image data which it has to keep in graphics memory. This uses more memory.

Repaint

When visual changes do NOT require recalculation of layout

Visibility
Colors
Transforms
Background images
Transparency

Reflow

When visual changes REQUIRE recalculation of layout

Page load, Layout & orientation change
DOM Changes: Adding, removing, updating nodes
JS style information request
Changing value of display property
Changing to CSS property alters box model value
Resizing, zooming and scrolling (desktop), but not necessarily on mobile devices (viewport)

The larger a DOM tree, the more expensive a reflow is
Opera lists repaint and reflow as one of the 3 main contributors to sluggishness
Reflow of an element causes the subsequent reflow of all child and ancestor elements as well as any elements following it in the DOM.

Reflow

Minimize the DOM

Minimize number of nodes
- Uses up memory
- Measures each node for each repaint
Cache DOM lookups
- Store them!
Minimize DOM manipulations
- Batch DOM queries & DOM manipulations separately

More nodes = more expensive!

Reuse the DOM

Pool Elements and Objects

Reuse instead of Allocate and Destroy

Create a pool of DOM elements (more than you need)
Use the nodes you created
Release back into pool
Go to step 2

So, how you doin'?

How long to load your page?

WebWait.com

Weinre

Download & Install Node.js (includes NPM)
Install Weinre
```
npm -g install weinre
```
Start Weinre
```
weinre
```

Add Weinre to web page

<script src="http://localhost:8080/target/target-script-min.js#anonymous"></script>

Open the inspector
```
http://localhost:8080/client/
```

Adobe Shadow/Edge Inspect

Download Adobe Shadow/Edge Insepect desktop application
If you're on Windows 7, you might also have to download and install bonjour.
Download and install the Adobe Inspect Chrome Extension browser plugin
Install the mobile app on each of your devices (free in the app stores)
Run the application on your desktop, then minimize the window
Open the browser extension in Chrome and turn it on
Run the application in your devices
- Click on your desktop when found
Enter the "pairing" number given by the phone into the Chrome extension pop up window

Basically, Weinre on crack, and free version is like automated Weinre.

Tools

Activity Monitor
Chrome Developer Tools - Timeline tab
Emulators

Other Tips

Test in Real Environments

iPhone showing which apps are running in the background

Test on Phone:
- Simulator != Emulator
- Cap your memory
Test with many apps open
Test on multiple devices
Test on mobile network

Tricks

Use tools
- Even basic ones, like Activity Monitor
Scale down (not up)
Use average size fonts
Don't disable zoom (except for games)

Conclusion

Follow performance recommendations
Minimize Latency
Manage memory
Use CSS Judiciously
Use JS Minimally (and NOT for animation)
Batch query and manipulations separately
Reuse the DOM
Keep Mobile in Mind

Remember...

Your users may not be tethered

and their memory may be very limited.

Thank you

Slides: estelle.github.com/mobileperf
Name: Estelle Weyl
Blog: standardista.com
Twitter: @estellevw