Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2020 JavaScript edits #1737

Merged
merged 20 commits into from
Dec 15, 2020
Merged

2020 JavaScript edits #1737

merged 20 commits into from
Dec 15, 2020

Conversation

rviscomi
Copy link
Member

Progress on #897 #1432

@rviscomi rviscomi added the editing Content excellence label Dec 10, 2020
@rviscomi rviscomi added this to the 2020 Content Writing milestone Dec 10, 2020
@rviscomi rviscomi requested a review from tkadlec December 10, 2020 20:25
@rviscomi
Copy link
Member Author

Also adding @ibnesayeed and @denar90 as I'm not sure if they've gotten a chance to formally review the draft before publication. Please suggest any changes to this PR, or feel free to open a new PR.

@github-actions
Copy link
Contributor

Images automagically compressed by Calibre's image-actions

Compression reduced images by 46.2%, saving 54.24 KB.

Filename Before After Improvement Visual comparison
src/static/images/2020/javascript/correlations.png 117.52 KB 63.28 KB -46.2% View diff

692 images did not require optimisation.

Update required: Update image-actions configuration to the latest version before 1/1/21. See README for instructions.

@github-actions
Copy link
Contributor

Images automagically compressed by Calibre's image-actions

Compression reduced images by 46%, saving 61.38 KB.

Filename Before After Improvement Visual comparison
src/static/images/2020/javascript/prefetch-distribution.png 70.46 KB 38.47 KB -45.4% View diff
src/static/images/2020/javascript/preload-distribution.png 62.99 KB 33.60 KB -46.7% View diff

693 images did not require optimisation.

Update required: Update image-actions configuration to the latest version before 1/1/21. See README for instructions.

@github-actions
Copy link
Contributor

Images automagically compressed by Calibre's image-actions

Compression reduced images by 43.9%, saving 251.06 KB.

Filename Before After Improvement Visual comparison
src/static/images/2020/javascript/frameworks-bytes.png 206.27 KB 110.94 KB -46.2% View diff
src/static/images/2020/javascript/frameworks-main-thread-no-ember-diff.png 129.05 KB 73.46 KB -43.1% View diff
src/static/images/2020/javascript/frameworks-main-thread-no-ember.png 118.95 KB 67.83 KB -43.0% View diff
src/static/images/2020/javascript/frameworks-main-thread.png 117.19 KB 68.17 KB -41.8% View diff

695 images did not require optimisation.

Update required: Update image-actions configuration to the latest version before 1/1/21. See README for instructions.

@rviscomi rviscomi marked this pull request as ready for review December 10, 2020 22:26
@rviscomi rviscomi mentioned this pull request Dec 10, 2020
22 tasks
@@ -208,33 +216,53 @@ Of those external scripts, only 12.2% of them are loaded with the `async` attrib
sql_file="breakdown_of_scripts_using_async_defer_module_nomodule.sql"
) }}

{# TODO(authors): Why is it misleading? #}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@tkadlec tkadlec Dec 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Misleading was the wrong word choice. Over-inflated. I clarified in an edit, but basically, this means that not all of those 6% of requests get the full benefits of defer, because of that async/defer anti-pattern.

Considering that `defer` provides us with the best loading performance (by ensuring downloading the script happens in parallel to other work, and execution waits until after the page can be displayed), we would hope to see that percentage a bit higher. In fact, as it is that 6.0% is a bit misleading.

Back when supporting IE8 and IE9 was more common, it was relatively common to use _both_ the `async` and `defer` attributes. With both attributes in place, any browser supporting both will use `async`. IE8 and IE9, which don't support `async` will fall back to defer.

{# TODO(authors): In the Twitter thread that discussed this, it actually spurred the Jetpack folks to push a fix! Might be worth mentioning :) #}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tkadlec totally optional

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great little story! Added. :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Could you open a new PR with your changes?


The popular libraries in use are largely unchanged from last year, with jQuery continuing to dominate usage and only one of the top 21 libraries falling out (lazy.js, replaced by DataTables). In fact, even the percentages of the top libraries has barely changed from last year.

{# table? showing rank, library, percentage and last years rank #}
{# TODO(analysts): table? showing rank, library, percentage and last years rank #}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requires pulling 2019 data so a bit more involved. I wonder if the figure below gets the job done. @tkadlec LMK.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry...what figure is that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://almanac.httparchive.org/en/2020/javascript?#fig-21

(The changes in this PR were just deployed to production)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha. I think that's fine. A comparison is kinda boring anyway with the lack of change.


It's worth noting that the detection issue that was noted last year still applies, and still impacts th results here. It's possible that there _has_ been a significant change in popularity for a few more of these tools, but we just don't see it with the way the data is currently collected.
{# TODO(authors): Elaborate on what the detection issue was. #}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@ibnesayeed ibnesayeed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should add spaces before and after every occurrence of character.

@@ -12,19 +11,20 @@ tkadlec_bio: Tim is a web performance consultant and trainer focused on building
discuss: 2038
results: https://docs.google.com/spreadsheets/d/1cgXJrFH02SHPKDGD0AelaXAdB3UI7PIb5dlS0dxVtfY/
queries: 02_JavaScript
#featured_quote: TODO
featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. JavaScript is no longer confined to the client-side—it's an increasingly popular choice for build tools and server-side scripting, and is creeping its way into the CDN layer as well thanks to edge computing solutions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Adding space around in ... client-side — it's an .... Alternative, this can be split into two sentences.
  • Should the thanks to edge computing solutions phrase be put in brackets separated by a comma or something?
Suggested change
featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. JavaScript is no longer confined to the client-sideit's an increasingly popular choice for build tools and server-side scripting, and is creeping its way into the CDN layer as well thanks to edge computing solutions.
featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. JavaScript is no longer confined to the client-sideit's an increasingly popular choice for build tools and server-side scripting, and is creeping its way into the CDN layer as well thanks to edge computing solutions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We haven't been doing that in other chapters so would prefer to keep consistent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The style guide we are using says no spaces around em-dash.

However I do agree it looks weird here so close to a hyphenated word.

Also I think this sentence is rather long with a first part, the em-dash, and then the third part. And the two "ands" don't help (though I agree technically correct).

I think we should rephrase. What about something like this?

Suggested change
featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. JavaScript is no longer confined to the client-sideit's an increasingly popular choice for build tools and server-side scripting, and is creeping its way into the CDN layer as well thanks to edge computing solutions.
featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack–it is no longer confined to the client-side and it's an increasingly popular choice for build tools and server-side scripting. JavaScript is also creeping its way into the CDN layer as well thanks to edge computing solutions.

Though not made about three sentences basically all starting with the same word (JavaScript), but that's probably just getting picky.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look good to me, but I think we should even split it at stack–it. That is literally a hyphenated word now, which doesn't make sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me, and also means we have a 4th sentence that doesn't begin with JavaScript 🙂

Suggested change
featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. JavaScript is no longer confined to the client-sideit's an increasingly popular choice for build tools and server-side scripting, and is creeping its way into the CDN layer as well thanks to edge computing solutions.
featured_quote: featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. It is no longer confined to the client-side and it's an increasingly popular choice for build tools and server-side scripting. JavaScript is also creeping its way into the CDN layer as well thanks to edge computing solutions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts/suggestions @tkadlec?


Developers love us some JavaScript. The [`script` element is the 6th most popular HTML element in use](./markup) (ahead of elements like `p`'s and `i`'s, among countless others). We spend around 14x as many bytes on it as we do on HTML, the building block of the web, and 6x as many bytes as CSS.
JavaScript has come a long way from its humble origins as the last of the three web cornerstones, alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. JavaScript is no longer confined to the client-side—it's an increasingly popular choice for build tools and server-side scripting, and is creeping its way into the CDN layer as well thanks to edge computing solutions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same changes as above in the featured_quote.

JavaScript, by default, is parser blocking. In other words, when the browser discovers a script element, it must pause parsing of the HTML until the script has been downloaded, parsed and executed. It's a significant bottleneck and a common contributor to pages that are slow to render.
By default, JavaScript is _parser-blocking_. In other words, when the browser discovers a `script` element, it must pause parsing of the HTML until the script has been downloaded, parsed, and executed. It's a significant bottleneck and a common contributor to pages that are slow to render.

We can start to offset some of the cost of loading JavaScript by loading scripts either asynchronously, which only halts the HTML parser during the parse and execution phases and not during the download phase, or deferred, which doesn't halt the HTML parser at all. Both attributes are only available on external scripts—inline scripts cannot have them applied.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We can start to offset some of the cost of loading JavaScript by loading scripts either asynchronously, which only halts the HTML parser during the parse and execution phases and not during the download phase, or deferred, which doesn't halt the HTML parser at all. Both attributes are only available on external scriptsinline scripts cannot have them applied.
We can start to offset some of the cost of loading JavaScript by loading scripts either asynchronously (with the `async` attribute`), which only halts the HTML parser during the parse and execution phases and not during the download phase, or deferred (with the `defer` attribute`), which doesn't halt the HTML parser at all. Both attributes are only available on external scriptsinline scripts cannot have them applied.


On mobile, external scripts comprise 59.0% of all script elements found. _As an aside, when we talk about how much JavaScript is loaded on a page earlier, that total doesn't account for the size of these inline scripts—because they're part of the HTML document, they're counted against the markup size. This means we load even more script that the numbers show._
<p class="note">
As an aside, when we talk about how much JavaScript is loaded on a page earlier, that total doesn't account for the size of these inline scripts—because they're part of the HTML document, they're counted against the markup size. This means we load even more script that the numbers show.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
As an aside, when we talk about how much JavaScript is loaded on a page earlier, that total doesn't account for the size of these inline scriptsbecause they're part of the HTML document, they're counted against the markup size. This means we load even more script that the numbers show.
As an aside, when we talked about how much JavaScript is loaded on a page earlier, that total didn't account for the size of these inline scriptsbecause they're part of the HTML document, they're counted against the markup size. This means we load even more script that the numbers show.

@tunetheweb tunetheweb mentioned this pull request Dec 12, 2020
@tunetheweb
Copy link
Member

tunetheweb commented Dec 15, 2020

Anything comments @tkadlec ? Have a few things queue up so planning a release soon and can include this if you get a chance to review?

@rviscomi rviscomi mentioned this pull request Dec 15, 2020
@rviscomi
Copy link
Member Author

I'm going to merge this with the changes as-is so that we can deploy the editorial suggestions sooner than later. I've left the unedited flag set until we can resolve the remaining TODOs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editing Content excellence
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants