Cheating on mobile web development

How messed up mobile web development is ?

A question worth an essay of thousand words. Well the thing that pisses me off a lot is how 90% of the browsers for mobile devices made this usability trick that expands the mobile address bar when you scroll down. Jeez that is the most annoying thing ever created.

There are several points:

  1. It's extremely stupid. Okay for smaller screens - maaaaybe, just maybe could be of some use. But nothing above 5" needs this.

  2. Messes up with fixed position elements

  3. Repainting is slow annoying and mostly filled with disappointment.

Getting one disappointment fixed.

Get rid of the 'dynamic address bar'

It only occures when the user moves(scrolls) the <body> up or down. It won't detect any inner div scrolling . So what people usualy do is cheat the mobile browser that there is no body scrolling.
As many mobile frameworks suggest - stop scrolling the <body>. Here is something simple to ditch the fixed position.
scroll

Give the body a hint to get out

body { 
    overflow: hidden;
}

Wrap your entire content

<div id="wrapper">
    ...
</div>

and make it your new body ( a reminder for those who don't need to scroll horizontally split the overflow to overflow-x and overflow-y )

#wrapper { 
    overflow: auto; 
    position: relative; 
    width: 100%;
    height: 100%;
    margin: 0;
    padding: 0
}

Keeping stuff inside the wrapper prevents the mobile to get that you are actually scrolling. Which simple and yet effective if you want to keep your site out of the mobile rendering issues.

Skip Repainting in Chrome

At some point everyone had to kick in the transform just because your box glitches in Chrome. That's cool, but it really hits the performance. I am not talking about using it once (which is okay). I am talking about the times where you had 5-6 fixed or absolute containers mashing up your design.

Keep it clean, keep it classy.
Using a lot of transform properties could really become nasty because of the constantly forced repainting of your page. It messes up the fixed position containers and tons other stuff.

By definition transform property is not rendered along with the other CSS properties.

The CSS transform property lets you modify the coordinate space of the CSS visual formatting model. Using it, elements can be translated, rotated, scaled, and skewed.

If the property has a value different than none, a stacking context will be created. In that case the object will act as a containing block for position: fixed elements that it contains.

Folks usually use that lead by the popular belief that translations are faster than moving the element with left top and so on. In Webkit it sure is, since it forces the graphics acceleration. But mostly as a fix it comes handy especially when you are lazy and not into debugging your front-end for bottlenecks (for sure most clients won't pay for this).

It's important to note that forcing the hardware acceleration for mobile devices is a must not - power hungry web sites are not something a mobile user would enjoy. But if you want a clean front-end you need to skip transform 'fixes' as much as you can.

Lately we've encountered a devastating bug in Chrome related to Slimming Paint and fixed position containers that requires this fix, but despite that you can fix every other visual glitch otherwise.

We should take a breath from flaming transforms and make a NB about the NB in using it - do not overlap it. If you transformed a parent and forced the acceleration - do not transform a children. It's a really bad habbit.

Few word on pre-/catching/fetching

Pre-fetching our pages allows users to take the app offline and also enables no waiting between navigation actions. Of course, we don’t want to choke the device’s bandwidth when the device comes online, so we need to use this feature sparingly.

With caching, we want a concurrent or asynchronous approach when fetching and caching these pages. We also need to use localStorage (since it’s well supported amongst devices) which unfortunately isn’t asynchronous.

How do we do that, the simple way.
- Get all the CSS & JS on first load
- Put it in localStorage
- Set cookies with the script names
- Get the cookies and embed only the new scripts
- Fetch the localStorage resources on load

As a pro-caching kinda guy I am against all such techniques aimed to reduce bandwidth by storing shit-load of stuff on the client's device. But as the logical approach it is what should be done.

Just a reminder when you are doing front-end performance optimizations, leave the caching aside until you fix everything else.


Helpful:
» Standartista Velocity Presentation
» Working Off the Grid with HTML5 Offline
» Fluid animation with accelerated composition
» Increase Your Site’s Performance with Hardware-Accelerated CSS


  1. 2 Sep 2015 (spell errors)

  2. 3 Sep 2015 (few words on pre-/catching/fetching: added)

Tsvetan "Cv3" Topalov

I am full-stack developer by mind and saas ninja by heart. If you want to share some thoughts @tsvetowntopalov (NSFW: I express my thoughts and heart here you might feel offended at some point.)

loopback

Subscribe to Tsvetan Topalov's Personal Space

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!