Page MenuHomePhabricator

Strategies to speed up combo wiki initial load time
Open, MediumPublic

Description

Locally, combo wiki takes a little over 4 seconds to load the page contents. The network tab shows this delay could be attributed to the loading of JS files, most of which might be unrelated to combowiki/payments.

We need to come up with strategies that would improve the initial page load speed before launch.

T437335 might helps

Event Timeline

Cstone triaged this task as Medium priority.Thu, Sep 10, 2:47 AM

Some small things I'm looking into is about the country blob we stored in <script> and is re-parsed, re-read on each page load. I noticed that currently we fetch the countries.yaml that is dependent on having a gateway chosen. However, I think that for this UI purpose we want the country dropdown to be a list of all countries we support across all gateway (or a fixed list of all countries)

For instance, if we didn't support iDeal payments in Gravy but only in Adyen directly, and if the deafult gateway chosen is Gravy on page load, we don't want to remove "NL" from the country list. We want to let the user select NL in the country selector, the page should reload and show 'iDeal' ecc. The point being; the country list in the country dropdown is independent from a the list of countries we do support in a specific gateway.

Because of this, I think we could improve performance by making this list of countries static and/or cached - avoiding the parsing of yaml files on each page load that is not even cached. I was wondering if we should just use all countries possible (aka use only built-in solutions in JS) for the dropdown at this point and have only the selected country trigger internal logic?

I think at the core this there is a potential "bug" (aka the list being tight to the currently selected gateway, when it shouldn't) and so by addressing this we can consider a more "static" solution to avoid having a big blob refetched from YAML files on page loads.

I believe that the server side logic is the main contributor of things potentially taking longer to load (at least on a first page load). Running a diagnostic on the browser DevTool it consistently shows me a slower than average High Time to First Byte (TTFB): The main document request (index.php) takes about an average of 800 ms to return the first byte. This delays the entire loading process from the start.

There is a difference between payments and combowiki on page load; in payments we get a lot of information for "free" so the page knows what it needs on page load and focuses on wiring it up. In comboWiki we are adding server side logic to get/parse information that previously was done in donate before; we should be mindful of adding this logic and how it could affect TTFB.

I think that the first defense for performance is to keep the server side logic to its minimum necessary, mostly when covering the new "donate page functionalities". Or to consider async flows so unlock page rendering (e.g. maybe with the writing the message to the queue and/or writing to session; should those lock the rendering of the page?).

So going back to the example of the country dropdown we added dynamic parsing of yaml files on each page load but I think we should instead do something similar as the current donate.wikimedia.org page does; store the country+currencies mapping in a new JSON file (like a new combowiki specific configuration file, which is not needed in our legacy payment configuration), which we can cache accordingly.

Here the JSON file used currently by the country dropdown in donate: https://donate.wikimedia.org/wiki/Module:Country_links/data.json?action=raw
Here the code where I found it: https://donate.wikimedia.org/wiki/MediaWiki:Common.js

Should we maybe simplify this and have a JSON asset we maintain in ComboWiki for this dropdown and have it work as it does now (aka with translations of the country by known page load language) but adding the currencies as well? Then we can look into how to have this asset always cached unless modified. This way we can remove a whole server side logic we currently on each page load while also restoring the intended behavior of the dropdown, since we don't want to risk limiting the country list based on the chosen gateway on page load.

Change #1339805 had a related patch set uploaded (by Laurabarluzzi; author: Laurabarluzzi):

[mediawiki/extensions/DonationInterface@master] Move country dropdown data into dedicated static json file and combowiki module

https://gerrit.wikimedia.org/r/1339805

Change #1339805 abandoned by Laurabarluzzi:

[mediawiki/extensions/DonationInterface@master] Move country dropdown data into dedicated static json file and combowiki module

Reason:

Looking into another approach that doesn't involve adding a new country and currency related configuration file.

https://gerrit.wikimedia.org/r/1339805