Kuma: Lazy load wiki-compat-tables.css

[peterbe]

Instead of making a big bundle, we should lazy load just the CSS needed for pages with a BCD table.

[schalkneethling]

I made a simple component a while back that dynamically loads the contributor list. As you know, this can super bloat the HTML for a number of docs pages. Mentioning it here as it might be something we want to implement, but also, because the way I did it might be relevant here?

https://github.com/schalkneethling/mdn-contributors-list

[peterbe]

dynamically loads the contributor list.

I'm not disagreeing but I'm skeptical. On a page like
view-source:https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity there's lots of contributor links.

I experimented with deleting them from the HTML:

▶ ls -l Specificity.*
-rw-r--r--  1 peterbe  wheel  79550 Aug 23 16:05 Specificity.html
-rw-r--r--  1 peterbe  wheel  21649 Aug 23 16:05 Specificity.html.gz
-rw-r--r--  1 peterbe  wheel  74688 Aug 23 16:05 Specificity.wo-contributors.html
-rw-r--r--  1 peterbe  wheel  20886 Aug 23 16:05 Specificity.wo-contributors.html.gz

I.e. you can save almost 5K on the HTML doc if you don't include them.

But the alternative is to not include them in the HTML, then have some JS code do an XHR for the list of contributors (presumably with other things) and then mutated the DOM as it comes in. That execution overhead might cost just as much paying for the 5KB upfront.

I like your thinking! but unfortunately, the only way to know is to experiment and measure, measure, and measure.
If we had stumptown-renderer you could make a PR that spins up a whole production site with a full implementation of that and then measure it on the internet.

[schalkneethling]

But the alternative is to not include them in the HTML, then have some JS code do an XHR for the list of contributors (presumably with other things) and then mutated the DOM as it comes in. That execution overhead might cost just as much paying for the 5KB upfront.

Well, the idea with this one is that it is loaded on user demand. So, the heading is present and a button that, once clicked, will load the list of contributors and add it to the page. So, when the document loads none of this will happen.

The not so great part is, unless we keep state, once you refresh the page, you will have to click the button and load it all again :(

I like your thinking! but unfortunately, the only way to know is to experiment and measure, measure, and measure.

:+1:

[peterbe]

idea with this one is that it is loaded on user demand.

That's a pretty big change to the UI that you have to click to see that list. It's actually a pretty good idea because as a web developer learning about Array.forEach I extremely rarely care about who contributed to it. Mind you, I often find that I like to see when it was last updated.

We might not have time for this now but I'd like to explore this idea with @atopal

[atopal]

I'd suggest a much simpler solution: let's just replace the whole section with "last edited on xx by MDN contributors" and that links to the revision history. If someone can come up with a good use case for having the full list on the article page itself, we should consider that, but nothing comes to mind.

[ExE-Boss]

MediaWiki also only lists the contributors on the history page.

[schalkneethling]

I'd suggest a much simpler solution: let's just replace the whole section with "last edited on xx by MDN contributors" and that links to the revision history. If someone can come up with a good use case for having the full list on the article page itself, we should consider that, but nothing comes to mind.

If that is a real option, then that would be the quickest and easiest win. Should we go ahead with this @atopal?

[elham9066]

زندگی زیباست 🤗

در تاریخ چهارشنبه ۲۸ اوت ۲۰۱۹،‏ ۴:۵۰ ب.ظ Schalk Neethling <
[email protected]> نوشت:

I'd suggest a much simpler solution: let's just replace the whole section
with "last edited on xx by MDN contributors" and that links to the revision
history. If someone can come up with a good use case for having the full
list on the article page itself, we should consider that, but nothing comes
to mind.

If that is a real option, then that would be the quickest and easiest win.
Should we go ahead with this @atopal https://github.com/atopal?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/kuma/issues/5669?email_source=notifications&email_token=AHBJI4VMUXVESMQ7R5DNFMLQGZURJA5CNFSM4IOGNZHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5K5TKY#issuecomment-525719979,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHBJI4RSYGL4QM6Q3QYORIDQGZURJANCNFSM4IOGNZHA
.

[peterbe]

زندگی زیباست 🤗

Google translate tells me this says "Life is beautiful" but please can we stick to English for issues and PRs in this repository?

[peterbe]

Let's move the discussion about contributors list of to https://github.com/mozilla/kuma/issues/5717

[atopal]

To get back to the actual topic of this issue: Almost every reference page has a compat data table, so there is probably limited upside from lazy loading, especially if it leads to layout thrashing. Still worth testing though.

[peterbe]

there is probably limited upside from lazy loading

I second the word "probably" :) We just don't know and it takes more time to measure than it does to just do it.

[peterbe]

Anyway, I'm not sure it's worth testing. I would prefer to just do it.
https://developer.mozilla.org/static/build/styles/wiki-compat-tables.1d3c442ac0f3.css is 4.5KB (17.6KB uncompressed). That's almost 16% of the main CSS bundle (on the react side). If removing unused CSS is so valuable this here would definitely be worth doing.

[atopal]

yeah, let's do this then. Now we can test live, via the real user metrics.