Your Website is Too Damn Big

According to HTTP Archive, websites are approaching an average of 2MB per page. That's nearly double the average from just two years ago. I have some ideas why and how you can fix it.

Aug 2012 vs. Aug 2014

Type20122014Change
HTML48K58K+21%
JavaScript217K295K+35%
CSS39K54K+38%
Images694K1176K+69%
Other *18K131K+627%
Total1,105K1,855K+68%

* Custom fonts and vector icons seem to be most of "Other"

But what's to blame?

The three bigges are:

  • Images: most likely due to retina displays, web developers are under more pressure than ever to keep the eye candy pretty at an additional average cost of nearly 500K per page since 2012.

  • Custom fonts & vector icons: also due to retina displays (and to a lesser extent mobile devices), these techniques (e.g. icoMoon and SVG glyphs) are super cool but

Continue...

Urgent Call to Inaction from the W3C

Rarely do I find a need to call out the W3C folks (or anyone, for that matter), but the recent post by Daniel Glazman (@glazou), co-chair of the W3C CSS working group, pushed me over the edge.

In his article, he calls for everyone to, get this, stop using -webkit in their sites. He equates webkit, now a popular engine for most new mobile browsers, to IE6. Moreover, he calls it a “threat to the open web”.

Seriously?

This from the group responsible for years of delays in approving standards? Remember, these are the fine folks who for the past three years have cautioned web developers from using HTML5 (a term used a bit liberally to also include new CSS3, video, local storage, web sockets and other goodies) because they’re still working on drafts for it. Take the canvas tag, a webkit mainstay since 2005, which is still a

Continue...

Tip: faster mousemove events in webOS 1.4.5

Warning: this is a short-term solution, it may cause interesting results in future versions of the webOS SDK, so use wisely.

One minor frustration I’ve run into with making JavaScript webOS apps (games in particular) is the mousemove events don’t seem to fire very often on custom controls. This is particularly noticeable when users finger-paint on canvas tags or drag elements around. I suspect that this quirk in the webOS webkit was introduced as a performance improvement, but running up against it can be painful.

A fix I’ve discovered is this simple CSS addition to any elements which need higher resolution mouse movement (er, touch movement, whichever):

myelement {  
    -webkit-user-drag: element;
}

Just put any valid CSS selector in place of “myelement” above, and you should notice a marked improvement in mouse movement precision for the element(s) in question.

This is not a future-proof solution, because if Palm

Continue...

Flicking and scrolling

So, when I made Jo, many of the controls were ported over from an older library used in my webOS titles. I was never completely happy with the flicky-scrolly-control, mostly due to sorting out event annoyances, especially between mobile platforms. Now it’s even worse, and I’m tempted to have platform-specific code for certain platforms which have their own enhanced gesture systems. More code, little build complexity, but possibly a big payoff. The animation will still be CSS3-based, so really it’s a matter of sorting out gestures from tap and drag events.

Continue...