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>.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Move the schema.org metadata to the HTML metadata colleciton | mediawiki/extensions/Wikibase | master | +70 -63 |
Related Objects
Related Objects
- Mentioned In
- T240489: [Epic] Determine the optimum Vector DOM structure for a11y and performance
- Mentioned Here
- T209306: [Epic] [SEO] Enable Schema.org Article linked data for all main namespace pages
T250317: Add schema.org structured data to images on Commons and Wikipedia to meet Google's requirements
Event Timeline
Comment Actions
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
Comment Actions
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.
Comment Actions
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.
Comment Actions
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?
Comment Actions
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.
Comment Actions
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.
Comment Actions
Requesting a code review from Platform Engineering, please feel free to tag a more appropriate team. :)
Comment Actions
As I understand it, the JSON-LD scripg block was added in 2020 as part T209306. Testing with Google's own tools (example) shows that this appears to be working correctly.
For performance reasons I would advise against moving this to the <head> unless we can quantify and validate with concrete evidence that this is a problem. And even then I would propose we first reach out to releant standards bodies to see if it can be loosened to follow best practices such that we prioritise human experience over that of automated indexing.