Page MenuHomePhabricator

Performance review of Wikipedia KaiOS app
Closed, ResolvedPublic

Description

Description

This is a Wikipedia mobile app for KaiOS. It is built with web technologies but is installed on the phone like a native app.

Preview environment

It is rather easy to run it locally in a browser. Just clone the repo and run npm install and npm run dev. Set your browser resolution to 240x290 for a realistic experience.

Which code to review

https://github.com/wikimedia/wikipedia-kaios

Performance assessment

Please initiate the performance assessment by answering the below:

  • What work has been done to ensure the best possible performance of the feature?

We're not looking for "best possible performance" but best possible time to market with adequate performance. We expect the features that don't require fetching data to feel snappy and those that do to feel responsive (not frozen). However, we have yet to design the article loading screen.

  • What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance?

We've found the css engine (Firefox 48) to be the main weakness. Laying out a large article can take 10 seconds or more. For this reason we only keep a single section in the DOM at a time and try to keep reflows to a minimum.

We transform the article API output quite a bit. This can take 250ms or more or very large articles.

  • Are there potential optimisations that haven't been performed yet?

Breaking down large components into as many pure components as reasonable will greatly reduce the amount of rendering preact has to do.

Removing or memoizing calls to getBoundingClientRect() or other expensive DOM APIs could help.

We have to rewrite useNavigation so it doesn't renumber all the nodes all the time. We don't need it anymore.

Maybe include the i18n files in the bundle instead of fetching individual <lang>.json files on startup.

  • Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: performance-team@wikimedia.org.

We use the console's time/timeEnd functions for ad-hoc measurements but nothing is in place permanently.

Event Timeline

Krinkle triaged this task as Medium priority.Dec 19 2019, 5:49 PM

Note to self: Look at our previous "Wikipedia for FirefoxOS" and "Wikipedia for Windows 8 Metro" apps that were previously developed and abandoned (and were also web-based apps).

@Krinkle We are planning to release this app in the next couple of weeks. Would you please give us an indication of when this is likely to be reviewed by you/your team?

Hi @AMuigai I want to check if its ready for testing?

I don't have a Kai os phone at the moment (@Krinkle has one) but I tried locally in Chrome and all content don't generate for me, for example going to Barack Obama, scrolling to the next page after the top image is empty? I can see the small scroll bar is changing when going to the following pages but they are all white. Or is that a Chrome thing where it doesn't work as expected?

Screen Shot 2020-02-18 at 1.18.40 PM.png (562×556 px, 376 KB)
Screen Shot 2020-02-18 at 1.18.46 PM.png (570×534 px, 17 KB)

I got three things:

  1. Will the application be automatically installed on phones or will it be downloaded (thinking about the payload for loading the app the first time)?
  2. How do I build it as it will be deployed for the user, is npm install and npm run dev still the correct way?
  3. At the moment we load a font from Google, that's not ok for users privacy, that needs to be changed.

@AMuigai I can start doing the performance review (we in the performance team discussed it in our weekly meeting). I think the best way to do it is if we do it together with one of you, then I can share how and what I test, and you can share how it's built so I don't focus on wrong thing. Then I will learn more about the app and one of you learn more about performance? :)

I'll be on leave early next week but back on the 27, I can start whenever then when one of your team mates have time. At that time I'll make sure I have an Kai OS phone.

I'm happy to do that, there isn't a proper development guide in the repo yet so it's better to do it together, and let's schedule a day time when you back.

Great lets do it @hueitan ! I'll work on a short list of things that I will add on the task tomorrow, so you have some time to read through.

Ok, there a couple of things I want to start with:

  • Since this will run on many different low end devices, I think we should instrument/collect metrics from real users so that we can find potential problems in the future. There's an API called the User Timing AP I that we can use to internally measure our code, its been around since Firefox 30 something so it should work. From the outside I would measure API calls, parse times of content etc. But you that knows the app better maybe have other input. Thinking we could integrate it with https://github.com/wikimedia/wikipedia-kaios/pull/131.
  • Its important that you feel that everything is ready when we start to test, do you know when you are? :)
  • Since there's no good way to automate performance testing on Kai OS devices (at least that I've found) I think the easiest way it just to compare, so I think we should compare the current mobile version for example https://en.m.wikipedia.org/wiki/Barack_Obama with the Kai OS version, coming from search, direct hit etc. Sounds ok?

I don't have a Kaios phone at the moment (@Krinkle has one) but I tried locally in Chrome

Please use firefox and see if it works. If it doesn't please let me know.
Since the OS is based on FirefoxOS we optimise for that browser since the experience on the phone is similar.

Great lets do it @hueitan ! I'll work on a short list of things that I will add on the task tomorrow, so you have some time to read through.

if u setup a meeting for this please invite me so I can attend as well

Assuming this task is about the KaiOS-Wikipedia-app project, hence adding that project tag so people who don't know or don't care about random WMF team tags can also find this task when searching for projects which they are interested in.

Kai OS application performance review

I've had two meetings with @hueitan and @Jpita and will summarize what we've been talking about here. For me there has been two things that makes it harder to test the performance on Kai OS and get realistic numbers:

  • There's no tools today to do synthetic testing on Kai OS
  • I have no tools to run my phone on a limited connectivity today but that will be fixed in the future in T247727

I've gone through the application and tested in on my Nokia 2720. I have one more thing I want to do and that is have a closer look at the API cache in the application and see if there's an easy way to still keep the cache simple but have some kind of limit in the cache.

Collect metrics from real users

There's one thing that I think is the most important thing and that is collect performance data from real users. We can do that with the User Timing API and beacon back the data. From my point of view the interesting metrics are the time it takes to get data from the API and the time it takes to parse the result on the phone. The parse time is interesting since the phones running Kai OS usually is low on CPU and memory compared to other phones. The API is interesting since if the API call hasn't been cached on the server, the call can take a couple of seconds (or more). Here's an example when the call to get the media for the Obama page takes 1,8 s. I've seen faster but I've also seen slower. If you hook devtools you will see the same thing as me, when the API call isn't cached.

Screen Shot 2020-02-27 at 9.07.43 AM.png (752×2 px, 322 KB)

That time will be on top of the connection the user has. So if you run on a slow connection the API call will be added on top on that.

At the moment the page is rendered after all the three API calls has finished and are parsed. One idea could be async load the media api call and start to render the page without it (T246681) since it looks like that API call is the one that takes the most time. However I would wait with that and first make sure we collect data from our users.

If we don't collect metrics, we don't know if this is a problem or how many users that are affected. Collect metrics T246684 and then if we see that it is a problem we should try fix it.

Limit caching

I really like the approach of the API cache that it is implemented, its super simple and simple code, great! I'm a little worried that we could reach the limit of memory for users on Kai OS. I haven't got around to crash the app yet, and maybe its not possible but I would feel a little better if there's a limit of cached API calls. I'm thinking splitting the cache for pages and the rest and then set the limit of X cached pages and still trying to keep the cache simple. I'll try to do a PR up for discussion and then you all can decide how you wanna do it with.

Search

We send a request for every key stroke. That means when I cycling through each key, we send a request to the backend. @hueitan told me you have multiple ways of solving that and you could add the task numbers just to keep track of them that would be great!

I also not sure about the pattern of sending search result for just one or two characters, I know we do that on desktop and mobile today but I think Kai OS is most used where you have slower connection speed and I feel unsure if you as a user would actually get the result before you entered the next character? I haven't been able to simulate a slow connection to verify it, but maybe someone in the team have?

Summary

For me the important thing is to get metrics from real users, that will give us a better picture of how the application is doing in the wild.

I also have one non-performance related feedback. I think in future versions we should aim for beacon back errors, or at least number of catched errors. Since we fully run on the users phone, we should make sure that we get information back if things aren't working. I don't mean the same as T226986, just lightweight collect errors so we can see how we are doing. Right now the only way we will know if the application works correct is when we get a new page view right?

Extras

I also tested the mobile web on Kai OS and it generated T246767 and T246315.

Thanks for the summary @Peter

We send a request for every key stroke. That means when I cycling through each key, we send a request to the backend. @hueitan told me you have multiple ways of solving that and you could add the task numbers just to keep track of them that would be great!

It's here T246786: Trigger search only for confirmed characters

@Peter when I need to control the network behaviour I use a tool like Charles, it allows you to create a proxy and funnel the network calls through that proxy.
You can filter calls and change the speed of the connection.
That one is not open source and I haven't found a good open source one (or user friendly).

@Jpita yes but can you set Firefox on the phone to use the proxy? I didn't find a way to do that but maybe there's a way, the documentation isn't super detailed. I can have a look again.

On Android I usually use https://github.com/Genymobile/gnirehtet to reverse the traffic to my local machine and then set the connectivity on my own my machine using https://github.com/sitespeedio/throttle.

Yes, you change the wireless settings on the phone to go through the proxy
created on your computer.

Thanks for the performance testing @Peter, @hueitan and @Jpita.

Given that the first review was completed, and tasks related to improving performance created, I am closing this as resolved.