Show code examples faster

[atopal]

The film strip and waterfall views here show how the interactive editor for JS and CSS example content is loaded pretty much as the last thing. On the cable connection from Dulles, that's a 1 second delta between seeing examples on pages with and without the editors.

• CSS: https://www.webpagetest.org/video/compare.php?tests=170918_YA_297895ccef96bac955492827f323e0ef,170918_3T_4467b85bdc8fb0841f08c9a040967542
• JS: https://www.webpagetest.org/video/compare.php?tests=170918_FR_89f1f709dbdb3b35ab14ea89321ea659,170918_NX_a0ef0656de920ddbd47054fd80608ac6

The main issue to be addressed here is that code examples should be shown faster, which may or may not be the same as improving load times for the editors.

[schalkneethling]

interactive editor for JS and CSS example content is loaded pretty much as the last thing
The main issue to be addressed here is that code examples should be shown faster

I am guessing here the browser makes some optimisations, focusing on content from the origin domain first, and then loading content from external sources. As the plaint text examples are contained within the iframe of the editor, it is loaded later along with the editor code.

[schalkneethling]

@atopal I have made optimizations to the source files that are built by the page generator. I now minify all sources. This should definitely improve the performance overall.

Not sure that it will solve the problem 100%, but would interested to see the impact.

#284

[atopal]

Thanks Schalk! Here are a few things that jump out at me, but I'm no performance expert and have no idea how feasible any of this is:

• It's a bit inconsistent, but we lose quite a bit of time due to the different domains, DNS, SSL handshake etc. Using either the usual CDN or being on developer.mozilla.org, even if only for the html file might solve that.
• It looks like the html of the iframe is loaded quite quickly, but then it takes some time before other assets are loaded, maybe preloading is an option, don't know whether that makes sense for the assets used in the iframe or the iframe itself like <link rel="preload" href="https://example.com/widget.html" as="document"> (got that from SO)
• The loading of web fonts is unpredictable, I think the number of parallel requests is limited, so that probably delays loading of the iframe assets. Maybe this won't be an issue with the pre-loading.

[schalkneethling]

@atopal Here is something we can try, although it would need to be added on the Kuma side to all page types(I guess article) that can contain an interactive example. Because we connect to the CDN, and the CDN is also https there is most likely an initial handshake that may slow things down a bit.

If we add the following to the head of those pages

<link rel="dns-prefetch" href="https://interactive-examples.mdn.mozilla.net" pr="0.75" />
<link rel="preconnect" href="https://interactive-examples.mdn.mozilla.net" pr="0.75" />

We may be able to negate it some. Something to keep in mind with this, is that these are hints, and could be completely ignored by the user agent.

dns-prefetch and preconnect can be used in the current navigation context, whereas prefetch and prerender is a speculative fetch, and so can only be used within the next navigation context i.e. if navigation to the resource specified is the most likely destination from the current page

That does not fit our purpose as the resource is loaded on the same page.

Thoughts @wbamberg @stephaniehobson

Fonts

The benefit we gain over the cost to load the web font is so low, that here I would vote to simply use the system sans-serif and safe some bytes, and one less request.

[schalkneethling]

@atopal Also, are you seeing any entries on GA for:

category: exampleType,
action: 'Load time in ms: ' + duration,
label: 'Performance'

[schalkneethling]

We could also potentially inline any critical CSS to improve load time some. Not sure how much benefit we will get in this particular case, as there is not a lot of CSS in general. Worth a shot though.

[atopal]

Well, the nice thing is that we can try any sort of optimization and simply look at the results to see whether it has an impact or not :)

[stephaniehobson]

I'm seeing stuff in GA for the analytics :)

I think the pre-fetch/preconnect is a good idea. The iframe is definitely a low priority for the browser and that seems likely to speed up getting it. I have another much more complicated idea* if we're not happy after that.

Font loading is not render blocking and shouldn't be slowing the iframe down. I wouldn't spend time on that before trying the other things (But I thought we had decided not to use webfonts?)

* we could pre-fetch the non javascript version with kumascript and display that while we ajax load the iframe in, and swap the pre-loaded HTML with the iframe once all the assets have arrived.

[schalkneethling]

But I thought we had decided not to use webfonts?

Indeed we are not :) There are some of the specific CSS examples that do load FiraSans but, they are not part of the currently tested examples. I assume the font loading the Kadir saw must have been MDN itself.

we could pre-fetch the non javascript version with kumascript

Which version are you referring to here? Is this something that already exist or, are yo thinking of a change to the editor?

I think the pre-fetch/preconnect is a good idea.

Yes, I agree that this is well worth implementing to see the effect it has.

@atopal Is there a way I can get access to the Analytics for MDN?

[atopal]

Hey Schalk, I can give you the data if you have any specific requests. To get access to the MDN account on GA, you need to file a service now ticket.

And yeah, I was referring to web fonts loaded for the article page. If you go to the waterfall images on the pages I linked to in the first post, you can see that fonts are loaded before the assets of the iframe are loaded. Not sure if it's blocking, but it seems consistent.

[schalkneethling]

@atopal At this time, I am mostly interested in this metric:
#283 (comment)

[stephaniehobson]

we could pre-fetch the non javascript version with kumascript

Which version are you referring to here? Is this something that already exist or, are yo thinking of a change to the editor?

I was thinking of what loads when the user has JS disabled. That already exists :)

[schalkneethling]

I was thinking of what loads when the user has JS disabled. That already exists :)

Oh yeah, this is still in the iframe though, and inside the same HTML file that is loaded for the editor. All that happens is, if JS is enabled, it swaps out the static code block with the editor.

[schalkneethling]

Pull request: mdn/kuma#4455

[atopal]

Would it be possible to use a Kumascript macro to pull in that content at render time?

[stephaniehobson]

Kumascript has the ability to scrape a page. I'm suggesting it pull in the non-js version from the CDN and display that while the iframe loads.

[schalkneethling]

Kumascript has the ability to scrape a page. I'm suggesting it pull in the non-js version from the CDN and display that while the iframe loads.

I have no idea how this works but, it sounds super promising. With that said, I am curious now, how would that work?

[wbamberg]

My worry about this would be a "flash of unstyled content" effect.

Another even more radical option would be: don't use an iframe, but build support for the editor into Kuma's front-end. The only reason the prototypes used an iframe was that it's much easier to experiment like that. It's not obvious to me why the production version should use an iframe (the old live samples use one for security, because they are Wiki-editable).

But this is a much bigger change :(.

[stephaniehobson]

We should talk about how hard this would be in the sync up tomorrow.

[schalkneethling]

PR: #309

[schalkneethling]

I reckon we have reached an acceptable level with the editors. While there is always room for improvement, I feel like we can close this one for now.

• Yup
• Nope

@wbamberg @stephaniehobson @atopal