How removing caching improved mobile performance by 25% | Hacker News Reader

How removing caching improved mobile performance by 25%

engineering.klarna.com

116 pointsthijser41 comments

Well, specifically removing the html5 offline application cache if you don't need offline functionality.

That it causes duplicate requests, and apparently more of them in chrome mobile than other browsers, is interesting though.

Agreed ^ this title is a big misleading / clickbaity

Not sure why they went that way either..."Offline Cache Causes Duplicate Asset Downloads" would have caught my attention just fine.

Not a web technology expert, but apparently the appcache feature is deprecated (https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_...) and this dead horse has already been beaten to... er, death? before (http://alistapart.com/article/application-cache-is-a-doucheb...).

I could be missing something, though.

EDIT:

Forgot to mention that both links come straight from that article.

Service workers are the way to go now.

But they aren't available in Safari.

And on mobile, where appcache should be most relevant, Safari can have a significant market share.

They'll come around. And in the meantime, at least Chrome users can benefit.

Until they come around, all iOS users are without service workers, because Chrome on iOS is backed by WKWebView [1]. AFAIK, any custom browser on iOS is required to use WKWebView.

[1] http://stackoverflow.com/questions/29895387/service-workers-...

I want Web Push!!

Take a spin at DronaHQ. It allows you to build offline web apps that works cross platform

iOS Safari has become the IE of mobile?

Thanks for the heads up.

> Never use the application cache (or service workers) unless you actually need offline features.

I disagree. Appcache is deprecated and you should never use it under any circumstances. On the other hand, service workers are cool and there are reasons to use them even if you don't need offline features.

Safari does not support Service Workers AT ALL, so not using AppCache effectively kills offline support for iOS (source: https://jakearchibald.github.io/isserviceworkerready/). Also, according to http://caniuse.com/#feat=serviceworkers, IE/Edge as well as Safari Desktop and Android 4.x do not support AppCache (compared to near-universal support for AppCache, http://caniuse.com/#feat=offline-apps). This means: use AppCache or lose offline on anything that's not FF/Chrome (on desktops, offline doesn't even matter that much!) or the newest Android.

Also, the Service Worker API just plainly sucks when compared with AppCache Manifests. It's a real pity that AC is going down the drain.

The Service Worker API is very general so it's like a one time cost of implementing something like the AC manifest using the API.

This, and IndexedDB API are ugly. Any recommendations on wrapper libraries?

I've been happy with localForage to do simple K/V in Service Workers.

Don't know about cache wrapping libraries... I know e.g. Webpack has an offline plugin thing that works with either AppCache or SW.

Dexie is good. http://dexie.org/

Also, aren't Service Workers transparent, which the AppCache isn't?

DronaHQ does the same like PWA for all devices. Check it out

Since when is only testing in Chrome an acceptable way to develop web applications?

I wish the author had shown us some other browser results. I'm curious if the iframe changes affected Safari, Firefox, or Edge. (Others have noted that app cache is deprecated).

Since Chrome is, by far, the most popular browser:

https://upload.wikimedia.org/wikipedia/commons/5/5a/Browser_...

Chrome also has some of the best dev tools built in.

I wonder how much that is distorted by the aggressive preloading that chrome does and by android (since testing chrome on desktop and mobile is not really the same thing)?

> Since Chrome is, by far, the most popular browser:

2002 called. You're a terrible person.

You would be right if it weren't for Chromium.

Is its a point of view only in people that are to young to have lived the debacle of IE6 years ? Or do some senor devs actually think testing in chrome only is ok ? Cause I read it more and more, and I find it very alarming. If this becomes a trend, we are going to live in pain all over again.

> If this becomes a trend, we are going to live in pain all over again.

It's painfully obvious that we're heading that way.

In a way Safari[0] and Apple's tight-fisted control on iOS is a blessing because no matter how much developers gripe about Mobile Safari (for plenty of good reasons mind) they damn well have to test the sucker.

[0] despite being "the new IE" to people who have no understanding of what it actually was and why it was a problem.

Compared to Chrome the Safari dev tools are downright embarrassing.

So true.

I sometimes have to debug some stuff on Safari and it feels like IE7 debugging back in the days.

To clarify, I'm not arguing that it's okay to test only in chrome, merely offering up a reason why that is so commonly the case.

Lots of folks here like to compare Chrome's dominance with that of IE6 back in the day.

Unlike Chrome, IE6 was never popular because of merit. Unlike Chrome, IE6 held back progress on the web - Chrome is still pushing it forward. Until that changes, can we quit with this tired comparison?

This article just displays the author's lack of knowledge of the subject matter he is developing with. Something tells me it was written just to get the company's name out there.

There's no shame in not being an expert.

And isn't getting their name out there the point of a company blog?

Not when it demonstrates such technical incompetence.

The fact that it's on the front page of HN shows that it seems to be interesting to people. Otherwise it wouldn't be here.

Did you know you can use Firefox Developer Tools to remotely debug mobile Chrome? It's still in heavy development, but I'm guessing it's easier than trying to quiesce browser activity and tease out network events manually. https://developer.mozilla.org/en-US/docs/Tools/Valence

Did this have any improvement on the conversion rate?

Is this considered a bug in appcache (deprecation aside)? Why would it download twice at all?

Yeah I missed this completely as well. Two requests for each resource because of the two iframes ("main" and "fullscreen")? It seems to me there's a huge logical leap between "..we were unknowingly downloading much more content than was necessary" and the next paragraph - probably just my unfamiliarity with webdev.

In the image on the article, you'll see that I pointed at a duplicate loading of fullscreen.css. If appcache weren't loading this in parallel, it would only be loaded once (by the fullscreen iframe).

I noticed the duplicate downloads. After all, they're the entire premise behind the investigation. But why does appcache download already requested assets?

Reply on news.ycombinator.com