Page MenuHomePhabricator

Schema.org metadata is in the <body> rather than the <head>
Open, LowPublic

Description

Problem
The schema.org metadata is in the <body> but metadata belongs in the <head> as described by the w3c's documentation and Google's examples.

Proposed Solution
Move the schema.org metadata to the <head>.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 602874 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/extensions/Wikibase@master] Move the schema.org metadata to the HTML metadata colleciton

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

My recollection is that we added this script to the bottom because it would be guaranteed to arrive and be parsed last, as well as be non-render-blocking. I think the hook lifecycle also executed at a favorable time. I'm not sure if the same is true for this change. That's not to suggest any opinion, only that you may wish to verify if you haven't already. As you noted, the new placement appears well within guidelines. I'll add that we A/B tested the original implementation for months and this may have positive, negative, or no effect.

There are related schema changes you may wish to weigh in on in T250317.

My recollection is that we added this script to the bottom because it would be guaranteed to arrive and be parsed last, as well as be non-render-blocking.

According to the documentation:

The embedded content is treated as a data block which won't be processed by the browser. Developers must use a valid MIME type that is not a JavaScript MIME type to denote data blocks. The src attribute will be ignored.

Since the script tag has a type that is not application/javascript the browser wont process (or parse) the contents. Therefore, this shouldn't change to the performance of the page and does not block rendering.

Since the script tag has a type that is not application/javascript the browser wont process (or parse) the contents. Therefore, this shouldn't change to the performance of the page and does not block rendering.

The contents still have to be loaded (transferred), though (since they’re inlined/embedded, not linked with src=).

@Lydia_Pintscher not sure how to interpret the project removal – are we not supposed to review this now?

The contents still have to be loaded (transferred), though (since they’re inlined/embedded, not linked with src=).

Indeed. Although for a comparison when I load an article on English without JS I get two render-blocking, uncached <script> tags in the head, the first is 4,441 bytes the second is 1,783 bytes. There are 4 render-blocking stylesheets (thought I assume they are cached for a long time). This change moves 745 bytes (which are ignored) from non-render blocking to blocking. Although it should be noted that 1 KB gets downloaded in less than a second on a dail-up connection.

In looking at this, I learned something interesting.

We are loading a render-blocking stylesheet that is a whopping 18 KB (!) (only ~5 KB transferred) and is only cached for 300 seconds (5 minutes):
https://en.wikipedia.org/w/load.php?lang=en&modules=site.styles&only=styles&skin=vector
Meaning: The user will need to download this 18 KB 5 KB file every 5 minutes or it will block rendering until they do.

Requesting a code review from Platform Engineering, please feel free to tag a more appropriate team. :)