
Our best practices are killing mobile web performance - nkurz
http://molily.de/mobile-web-performance/
======
gabemart
Why isn't there a way for devices to indicate to a server if they are on a
slow or data-capped connection?

It seems like "responsive" web design is based entirely around the size or
pixel-density of a device's screen. But why can't the experience respond to
the speed of a user's connection, or the amount of data the user can afford to
download?

My phone already knows I have a hard data cap when I'm off wifi. Why can't it
include a field in its request to every web server indicating I would like the
smallest amount of data possible, and then properly configured servers can
respond by omitting large images, videos, font files, etc. We have srcset for
images, but AFAIK choosing which image to use is still based on screen size
rather than bandwidth. And we need to get beyond srcset - as a content
creator, I want to be able to mark some images and other heavy resources as
optional, so I don't reference to them at all to bandwidth-sensitive devices.

~~~
petercooper
_Why isn 't there a way for devices to indicate to a server if they are on a
slow or data-capped connection?_

There is. I'll update this post if I remember what it is, but I believe
there's a spec and Chrome Canary is supporting it. It uses an HTTP header.

~~~
toomanythings2
Navigation Timing API [https://developer.mozilla.org/en-
US/docs/Web/API/Navigation_...](https://developer.mozilla.org/en-
US/docs/Web/API/Navigation_timing_API)

I have a feeling there is something else but I have trouble remembering it,
too, and I bet I have it bookmarked to study when I have the need to use it.

~~~
petercooper
That's a good one, but it wasn't that.

It's something that literally gets clients to add an HTTP header to specify
that bandwidth should be "saved".

Actually, that reminded me of what it was called.. haha, it's
[https://developers.google.com/web/updates/2016/02/save-
data?...](https://developers.google.com/web/updates/2016/02/save-data?hl=en)
.. The header is: Save-Data: on.

------
panic
The worst is when you start scrolling and an ad "lazily loads" under your
finger, using your touch to switch you out of the browser and onto an app
store page. It makes you reluctant to even start interacting with a page
before you're sure it's done loading.

~~~
userbinator
I thought touch/scroll events were distinguished thus:

Finger down -> finger up = touch

Finger down -> move -> finger up = scroll

How does a scroll get interpreted as a touch? It sounds like a bug to me.

~~~
Twirrim
The ads pop up right underneath your finger in the lag between deciding to
scroll and your finger touching the screen to drag. With the page jerking
around underneath you that seems to end up being classified as a click rather
than a drag, and away you go to whatever piece of crap you really don't care
about.

------
return0
In europe, the requirement for the annoying cookie compliance popups puts the
final nail in the coffin for mobile browsing.

~~~
anc84
[https://addons.mozilla.org/en-US/firefox/addon/i-dont-
care-a...](https://addons.mozilla.org/en-US/firefox/addon/i-dont-care-about-
cookies/) works well for me.

~~~
silverwind
Another alternative is the Prebake filter set [1] for uBlock Origin.

[1] [https://github.com/liamja/Prebake](https://github.com/liamja/Prebake)

~~~
anc84
Thanks! One less add-on, one more list for me. :)

------
userbinator
Over the years I've developed a bit of a habitual response of repulsiveness
whenever I hear the term "best practices" being used as a dogmatic
justification for doing anything, often completely missing the actual
situation at hand. It basically says "I don't want to think."

Related article:
[http://www.satisfice.com/blog/archives/27](http://www.satisfice.com/blog/archives/27)

That said, a lot of what I see in web development seems to be churn and
features-for-the-sake-of-features bloat, and I think much of it has to do with
the fact that the basics of a useful page --- images, text, hyperlinks, and
some styling --- were essentially solved problems many years ago, so all web
developers are left with is constantly trying to "reinvent" and "innovate"
things that were, albeit not perfect, entirely usable. The "do everything in
JS" trend is one of the clearest examples of this, as well as the
"appification" of sites that are perfectly fine as a collection of statically
linked pages. Blogs are the most common example of this that I come across ---
instead of displaying the content using HTML, they require the browser to
download and execute a huge blob of JS that often exceeds the size of the post
content itself, just to show that exact same content, sometimes even making
another (AJAX! It's awesome, so let's try to use it everywhere!) request to
fetch that content in a different format, parse it, and then render it back
into HTML. It sounds very Rube Goldberg, yet a lot of developers think this
massive waste of resources is somehow normal.

Thanks to the Internet Archive, you can try visiting the BBC site from
(exactly!) 10 years ago on your mobile device:

[http://web.archive.org/web/20050521031013/http://www.bbc.co....](http://web.archive.org/web/20050521031013/http://www.bbc.co.uk/)

I don't have a mobile device with me at the moment, but it's clearly less
"fluffy" than the page today, and loads essentially instantly even from IA's
not-so-fast servers.

~~~
thinkstoomuch
I think "Best Practices" are a good thing, so long as you understand why they
are best practices and in what situations. They are bad thing when they are
simply dogmatic cargo-cult programming without that understanding.

Moreover, I think they're a good thing as a short hand when thinking about
problems. You don't have to think about why this is a best practice for every
problem you encounter, because if you did, you'd never get anything done.
i.e., Why don't we write all of our code in a single main method? Oh yeah,
because it becomes a nightmare to find bugs, update to add new features, reuse
algorithms inside it...etc...etc. Instead of going through the rationalization
every time, the Best Practices rule of thumb generally works out.

Where it doesn't work out is if you've never done the exercise of why they're
best practices in the first place. For every best practice I follow, I have
understood the justifications and as a result, have developed an intuitive
sense for when my situation is the exception to the rule. Or, if my intuition
fails me and it gets questioned, I can re-run the exercise and perhaps change
my mind.

------
cm3
Gratuitous use of background videos, large JS, large CSS, many fonts, and so
on degraded the desktop web performance as well. It's not a mobile-only
problem. Compare scrolling on HN with scrolling on a random startup page and
consider the provided content.

~~~
mrweasel
All kinds of site are guilty of bloating their sites, without any real reason.
Take PayPal, their site is slow enough as is, so why do I need to see a short
video of a barista just to login. That's kinda stupid and has nothing to do
with PayPal.

Aiming for a lighter site wouldn't just be good for mobile, it helps everyone.
There's currently to much focus on presentation and to little on content. Even
if the content is good, sometimes the presentation just get in the way.

------
ommunist
While most in this article is true and has to be considered, in the real world
of corporate production it will not work. Is is not user you have to care
about. You have to keep happy your ignorant PM, that is all. Unless you are
happy to put significant effort into inobtrusive education of your manager or
PM, your efforts to enhance user experience will be most likely doomed.

~~~
mercer
That's been my experience as well, and it's so demoralizing. I've worked on
many projects where we, the developers, took effort to produce a lean,
functional, snappy website, on for the PM's to then order us to implement
_multiple_ tracking tools, ad systems, and 'widgets' that would turn the site
into a bloated abomination and reduced it to a crawl.

The 'funny' part is that the sites would sometimes break without anyone
noticing, because every developer and PM would have an ad blocker installed
that filtered out the 'extras' that caused the breakage...

------
sourcd
My favorite is [https://www.schwab.com](https://www.schwab.com).

If you attempt to type your username & password while the page is loading,
it'll keep trying to clear & refocus the username field. It forces you to wait
for 5 to 10 seconds before you can use it. If you are typing without looking
at the page, you will often end up entering a part of your password in clear
in the username field. If you're impatient, you might even hit enter
accidentally and send your password as your username to the server. Yahoo mail
used to be like that, haven't used it in a long time.

------
csense
The biggest "best practice" that needs questioning is the excessive use of
client side JavaScript. 90% of the websites out there would be able to provide
all their functionality with server-side rendering, except that's considered
unfashionable or something. I think it's partly web designers inventing fads
to keep themselves relevant -- if you're a web developer, you have a financial
incentive to try to persuade your customers that their perfectly working site
needs redesigned every 3-5 years to feel "modern".

But as a user, that's not really relevant. I want to browse the web of 2004 on
the internet connection of 2016.

~~~
marknutter
So then how do you handle all your dynamic behavior, or are you actually
suggesting we go back to the click-wait-click-wait paradigm of stateless web
applications?

Having client side JavaScript should not really add much to the overhead. Yes,
the initial load time will be larger, but every subsequent request will be
quicker because the server doesn't need to generate the markup and send it
along the wire on every click.

~~~
sievebrain
Using JavaScript rarely seems to fix click-wait-click-wait. It just replaces
the browsers spinner with a javascript spinner.

Raw HTML provides prefetch hints. That, combined with fast servers and
replication to ensure those servers are near your users, are all a fast
website needs.

Of course if your website is actually an app then maybe it shouldn't be a
website to begin with.

------
alexc05
I wonder if Google altering their SEO rating to test for "page jank" would
impact this.

Remember the adage "you get what you measure" well, for a while Google has
been awarding time to document ready (or some such) as their page speed test.

What if they started measuring post page load stuff?

Seo teams could start to measure page stability and budget for it.

~~~
mtbcoder
I doubt it (perhaps smaller players might get hit though). Google apparently
measures for page speed but I don't see any evidence that the worst offenders
(e.g. major news sites) are losing page rank for having "heavy" pages. It
seems that if you have a powerful brand, you can operate above what Google
suggests webmasters do. At least that's how I see it from my perspective.

------
dave2000
I'm probably the wrong person to ask because I hate most websites which aren't
just JavaScript free pages with text and a few relevant, tasteful images, but
don't people who "design" websites actually check what they look like on
mobile devices, and how they act under the average 3g data speed?

~~~
CM30
Yeah, they do check how the sites look on mobile devices. They might also test
them under the average 3g data speed, though there are a lot of developers who
just use the office wifi and assume it'll work fine everywhere else.

~~~
Klathmon
And they should be chastised.

I generally only make "enterprisey" web apps these days, but I will make sure
they are usable all the way down to a 2G connection.

And you don't just do this on the $800 top of the line phone, you try it on
other OS's, last year's model, a model from 3 years ago, that 2 year old phone
from my mother in law that is still crapped up with games and other stuff so
it runs extra slow, and then you adjust accordingly.

And the thing is this really doesn't take that much longer, and in the grand
scheme of things budgeting for a few older devices to test on is cheap as
shit.

------
htor
Good points, but you should consider the experience of using a better mobile
browser. Opera Mini isn't exactly up to date with modern web standards..

~~~
yoodenvranx
I use the latest Chrome on Android and I have pretty much the same experience.

------
yoodenvranx
I am very happy to see that somebody finally wrote all of this down!

Perhaps it's time for a wall-of-shame which automatically gathers and displays
performance data for famous mobile websites to pressure people into fixing
stuff?

~~~
mattengi
Exactly,

"the page is jumping around"

This is what most annoying experience during mobile web browsing.

~~~
yoodenvranx
Just reading the word "jumping around" pisses me off a bit...

But seriously, after 20 years of web development this is what we end up with?
Millions and millions of man hours invested in this and the experience is
worse than ever.

Somebody should write a "mobile web is a ghetto" rant and then we should start
burning all of this down and start over with a fresh list of best practices.

------
manigandham
It's important to realize the _why_ for all this. Every site wants to be lean
and fast, but they arent because it's ultimately a trade-off between the time,
effort and talent available.

Even the BBC which has enough funding and a good tech staff is likely working
with some bloated content management system that automatically generates
overweight pages. Add in all the ads and other widget functionality, media and
various customizations and themes and this is what we end up with.

There won't be any major progress until there's a big cause to prioritize this
(as in a major loss of traffic or revenue) or there are tools that will
automatically reformat and optimize pages (certain CDNs are getting into this
heavily now).

~~~
JustSomeNobody
No, its because a handful of bloggers decided doing everything client side was
the proper and true way to develop a web site. Other developers, being easily
influenced, have followed that dogmatically instead of using their heads.

~~~
manigandham
Poor developers are covered under "talent" mentioned above.

------
return0
Let's just please stop using custom fonts. I can tolerate the other stuff, but
having to wait forever without being able to read anything because i m waiting
for your custom font to load is just stupid, and it happens often.

------
ENGNR
Universal rendering, works without javascript

And not filling the page with crap

------
wwweston
> “Unobtrusive JavaScript” is an decade-old technique I have already critized
> in an earlier article. JavaScript is considered “unobtrusive” when it adds
> additional behavior to an existing, self-sufficient HTML structure. Once the
> JavaScript kicks in, it changes the HTML DOM and adds behavior. Inevitably,
> this leads to significant content changes and reflows.

I completely agree with the author on the fact that this is a problem, but I
don't understand blaming it on "unobtrusive javascript." Adding behavior
doesn't require a reflow.

------
DocG
The number of times I have miscliked because page is still loading and jumped
the buttons. Or losing my already filled content.

And I'm on a fast 4g network and good phone, LG G3

------
liw
Mobile browsing is awful enough that I avoid it as much as possible. There's a
few sites I trust or need that I use (wikipedia, a couple of news sites, train
time tables), but otherwise I restrict my web browsing to the laptop.

It wouldn't need to be so, but as long as browsing on my phone makes me angry
and frustrated, there's no point in engaging the Internet on my phone. I'll
just use my phone was what it was intended for: reading ebooks.

~~~
anc84
What makes you so angry and frustrated about it?

~~~
liw
The article this discussion has a lot of the points that make it unpleasant to
me.

Everything is slow. I don't dare touch the page until it's fully loaded (and I
don't always know that has from the browser's progress bar) and stops jumping
around. Pages are designed for bigger screens (they don't fit on my phone's
screen in a useful way) or better eyes (fonts are really tiny). Also, the
phone is just a bad device for doing anything complicated, such as following a
link (hard to hit tiny links with thick fingers) or looking up information
from multiple sources ("tab" handling is abysmal, at least with Chrome on
Android). Etc.

~~~
anc84
Give a system-wide ad-blocker (AdAway) and Opera Mobile a try. You can zoom in
and it will reflow the text to make it nicely readable. I wish I could switch
to Firefox but the lack of reflow is an incredibly weird anti-feature.

~~~
noisem4ker
I was very sensitive about this problem, and incredibly angered when text
reflow was gradually dropped thanks to Google, and when of course Mozilla
happily followed suit. But I must admit that on the web of today it is rarely
an issue.

If you want text reflow on touch working on Firefox for Android, you've got
this:

Text Reflow by david2097152 [https://addons.mozilla.org/en-
US/android/addon/text-reflow/](https://addons.mozilla.org/en-
US/android/addon/text-reflow/)

and its always-active fork:

Android Text Reflow by richmoz [https://addons.mozilla.org/en-
US/android/addon/text-reflow/](https://addons.mozilla.org/en-
US/android/addon/text-reflow/)

This could also come in handy:

Fit Text To Width by Jarrad [https://addons.mozilla.org/en-
US/android/addon/fit-text-to-w...](https://addons.mozilla.org/en-
US/android/addon/fit-text-to-width/)

~~~
anc84
Oh, I too thought those would be workarounds but they are not.

The first two say: _" This means it will only reflow ONE THING AT A TIME. If
the page has 50 paragraphs, you will have to tap once on all 50 to reflow the
whole thing."_

The third one simply does nothing for me.

~~~
noisem4ker
Just tap on the next paragraph when scrolling. Scroll, tap, repeat. Your thumb
will do that automatically while you're still reading the paragraph above.

EDIT: I just tried the third one by zooming in on a few desktop sites and I'm
impressed. Make sure text size is set to "tiny" in the accessibility settings.
It definitely works for me™.

------
nickpsecurity
The two things that aggravate me most about web sites are (a) important stuff
loads last only to find it's not even worth reading and (b) reflows where page
content jumps around as I'm reading it or trying to click a link. Wait, let's
add inability to scroll or content freezing for some amount of time due to
crap I don't need. Author of this piece is on point tackling all three
problems. If most sites did, it would prevent most of the headaches I have
going to them.

It's not just a gripe either. I often avoid sites that do this stuff in favor
of others that might have content or service I need without the headaches. The
ones that have little competition or all do stupid stuff still get my visits.
Just fewer of them due to the headaches. I doubt I'm the only one that reacts
these ways.

------
coldcode
I wish Google would penalize websites based on bloat like they do websites
that are not mobile-enabled. Of course they won't/can't since the bloat
contributes to their bottom line.

------
dangoldin
Nice read. Google's been working on AMP
([https://www.ampproject.org/](https://www.ampproject.org/)) to deal with
this. They're applying a pretty strict policy to speed up rendering on mobile
pages by trying to be as specific as they can upfront to determine the layout
up front.

