Zufällige interessante Fakten zur HTML/SVG-Nutzung

Letztes Mal haben wir uns angesehen, wie die durchschnittliche Webseite aussieht, basierend auf Daten von etwa 8 Millionen Webseiten. Das ist eine Menge Daten, und wir haben sie weiter gesichtet. Dieses Mal sind wir wieder da, um einige zufällige und hoffentlich interessante Fakten zur Markup-Nutzung zu präsentieren.

Ausblenden von DOM-Elementen

Es gibt verschiedene Möglichkeiten, DOM-Elemente auszublenden: vollständig, semantisch oder visuell.

Unter Berücksichtigung der aktuellen Praktiken und Empfehlungen, hier die Ergebnisse zu den am häufigsten verwendeten Methoden zum Ausblenden von Elementen über HTML oder CSS

Selektor	Anzahl
[aria-hidden]	2,609,973
.hidden	1,556,017
.hide	1,389,540
.sr-only	583,126
.visually-hidden	136,635
.visuallyhidden	116,269
.invisible	113,473
[hidden]	31,290

no-js HTML-Klasse

Wenn JavaScript-Bibliotheken wie Modernizr ausgeführt werden, wird die Klasse no-js entfernt und durch js ersetzt. Auf diese Weise können Sie verschiedene CSS-Regeln anwenden, je nachdem, ob JavaScript in Ihrem Browser aktiviert ist oder nicht.

Wir haben insgesamt 844.242 Elemente gefunden, deren HTML-Klassenliste die Zeichenfolge no-js enthält. Mehr als 92 % davon sind html-Elemente.

Wenn Sie sich über die verbleibenden 8 % wundern, sehen Sie sich die Top 10 an

Element	Anzahl
html	782,613
Körper	31,256
a	17,833
div	7,364
meta	1,104
ul	905
li	789
nav	768
span	431
article	263

noscript

Das HTML-Element noscript definiert einen Markup-Abschnitt, der als alternativer Inhalt für Benutzer dient, die clientseitiges Scripting deaktiviert haben oder deren Browser dies nicht unterstützt. Die clientseitige Skriptsprache ist normalerweise JavaScript.

Wir haben 3.536.247 noscript-Elemente in den Top 20 Google-Ergebnissen der 8 Millionen Seiten gefunden.

AMP

Accelerated Mobile Pages (AMP) ist eine Google-Initiative, die darauf abzielt, das mobile Web zu beschleunigen. Die meisten Publisher stellen ihre Inhalte parallel im AMP-Format zur Verfügung.

Damit Google und andere Plattformen davon erfahren, müssen Sie die AMP- und Nicht-AMP-Seiten verknüpfen.

Innerhalb der 8 Millionen Seiten, die wir uns angesehen haben, fanden wir nur 1.944 Nicht-AMP-Seiten, die auf ihre AMP-Version mit rel=amphtml verweisen.

Links Attribute & Werte

href=”javascript:void(0)

Wir haben 2.002.716 a-Elemente mit href="javascript:void(0)" gefunden. Ob Sie einen Button oder einen Link codieren, Sie machen es falsch.

href=”javascript:void(0)”
(a) Sie codieren einen Button mit dem falschen Element
(b) Sie codieren einen Link mit der falschen Technologie
– Heydon Pickering

target=_blank mit oder ohne rel=noopener

43.924.869 der von uns analysierten Anker verwenden target="_blank" ohne eine Verknüpfung mit rel="noopener". Wenn rel="noopener" in diesem Fall fehlt, setzen Sie Ihre Benutzer einem Phishing-Angriff aus, und dies gilt als Sicherheitslücke.

Anker/Link	Anzahl
[target=_blank]	43,924,869
[rel=noopener]	40,756
[target=_blank][rel=noopener]	35,604

MDN:

Wenn Sie target verwenden, sollten Sie in Betracht ziehen, rel=”noopener noreferrer” hinzuzufügen, um die Ausnutzung der window.opener API zu vermeiden.

Ben Halpern und Mathias Bynens haben ebenfalls gute Artikel zu diesem Thema geschrieben, und der allgemeine Ratschlag lautet: Verwenden Sie target=_blank nicht, es sei denn, Sie haben gute Gründe dafür.

href=#top

Es scheint eine gängige Praxis zu sein, #top als href-Wert zu verwenden, um den Benutzer zum oberen Bereich der aktuellen Seite umzuleiten. Es wurden 377.486 a-Elemente mit href=#top-Werten gefunden.

lang

Léonie Watson:

Das HTML-Attribut lang wird verwendet, um die Sprache des Textinhalts im Web zu identifizieren. Diese Informationen helfen Suchmaschinen, sprachspezifische Ergebnisse zurückzugeben, und werden auch von Screenreadern verwendet, die Sprachprofile wechseln, um den korrekten Akzent und die korrekte Aussprache bereitzustellen.

Von den 8.021.323 Seiten, die wir uns ansehen konnten, verwenden 5.368.133 das lang-Attribut auf dem HTML-Element. Das sind etwa 70 %!

div

Die durchschnittliche Webseite hat etwa 71 divs. Diese Zahl wurde berechnet, nachdem alle div-Elemente (576.067.185) gezählt wurden, die auf 8.021.323 Millionen Seiten gefunden wurden.

header vs footer

2.358.071 Seiten verwenden das header-Element, während das footer-Element von 2.363.665 Seiten verwendet wird. Wir haben auch festgestellt, dass nur 2.117.448 Seiten sowohl header als auch footer verwenden.

Element	Anzahl
footer	2,363,665
header	2,358,071

Links sind keine Buttons

divs und spans auch nicht.

Element	Attribut & Wert	Anzahl
a	class=btn	3,251,114
a	class=button	2,776,660
span	class=button	292,168
div	class=button	278,996
span	class=btn	202,054
div	class=btn	131,950

Im Gegenzug hier die Statistiken zu nativen Buttons

Selektor	Anzahl
button	4,237,743
input[type=image]	1,030,802
input[type=button]	916,268

Buttons ohne angegebenen Typ

Apropos Buttons: Das button-Element hat einen Standardtyp von submit. Stellen Sie sicher, dass Sie immer den Button-Typ angeben, denn wir haben etwa 1.336.990 button-Elemente gefunden, bei denen das Attribut type fehlt. Das sind etwa 31,5 % aller in freier Wildbahn gefundenen button-Elemente.

BEM-Syntax

Wenn Sie CSS-süchtig sind, haben Sie vielleicht schon von BEM gehört, einer beliebten Benennungskonvention für HTML-Klassen.

Wenn wir den BEM-Benennungsstil kennen, der aus Zeichenfolgen mit doppelten Unterstrichen und/oder doppelten Bindestrichen besteht, konnten wir schätzen, dass nur 20.463 Elemente den BEM-Benennungsstil verwenden.

Bootstrap & Font Awesome

Anscheinend haben wir nur 1.711 Seiten gefunden, die auf CSS- oder JavaScript-Ressourcen verlinken, die bootstrap[.min.].js|.css enthalten. Außerdem sieht es so aus, als ob 379 Seiten auf CSS-Ressourcen verlinken, die font-awesome[.min.].css enthalten.

Ich hätte mehr erwartet.

WordPress

1.866.241 Seiten, von den von uns analysierten, enthalten <meta name="generator" content="*WordPress*">. Wir können nur annehmen, dass mehr WordPress verwenden, aber einige sich entschieden haben, diese Meta-Informationen aus ihren Quellen zu entfernen.

.clearfix VS .clear VS .cf

Es gibt viele Benennungsstile für dieses bekannte CSS-Dienstprogramm, das beim Löschen der Floats hilft. Hier ist die Aufschlüsselung

Selektor	Anzahl
.clearfix	19,573,521
.clear	10,925,887
.cf	1,102,698

Favicon

Moderne Browser rufen /favicon.ico automatisch und asynchron ab. Geben Sie den Stammspeicherort also nicht manuell an, sondern legen Sie es einfach dort ab. Es sei denn, Sie bevorzugen aus irgendeinem Grund einen anderen Speicherort dafür.

Es sieht so aus, als ob 354.024 Publisher das /favicon.ico immer noch im head verlinken.

Void-Elemente

Die Frage ist, ob man die Void-Elemente schließt oder nicht. Obwohl HTML beides zulässt, wird empfohlen, die Void-Elemente nicht zu schließen. Zumindest aus Gründen der Kürze.

Element	Anzahl
<img/>	121,463,561
<br/>	67,595,285
<link/>	61,746,984
<meta/>	46,688,572
<br>	34,492,680
<input/>	27,845,389
<img>	17,844,667
<meta>	15,133,457
<link>	11,740,839
<input>	7,231,827
<hr/>	2,610,890
<hr>	1,690,891
<param/>	1,390,339
<area/>	1,336,974
<area>	1,025,183
<param>	698,611
<source/>	435,877
<base/>	389,717
<embed/>	304,954
<source>	286,380
<wbr>	237,606
<col/>	151,757
<col>	145,434
<base>	105,688
<wbr/>	77,922
<embed>	56,610
<track/>	376
<track>	310
<keygen/>	1
<keygen>	–

tabindex

Beim Kapern der Tab-Reihenfolge, wenn tabindex verwendet wird, um einige getrennte UI-Elemente zu lösen, wird das Problem normalerweise nur auf Dokumentenebene verschoben.

Der allgemeine Ratschlag lautet, es mit Vorsicht zu verwenden. Wir haben festgestellt, dass 552.109 HTML-Elemente das Attribut tabindex verwenden, um die Standardwerte beim Navigieren mit einer Tastatur zu überschreiben.

Fehlendes alt für Bilder

Dieses ewige SEO- und Barrierefreiheitsproblem scheint nach der Analyse dieser Daten immer noch recht verbreitet zu sein. Von insgesamt 139.308.228 Bildern fehlt bei fast der Hälfte das alt-Attribut oder sie verwenden es mit einem leeren Wert.

Element	Anzahl
img	139,308,228
img alt="*"	73,430,818
img alt=""	32,603,650
img mit fehlendem alt	33,273,760

Benutzerdefinierte Elemente

Ohne Berücksichtigung der Web Component-Tags, hier ist eine Liste von erfundenen Tags oder benutzerdefinierten Elementen, die sich von der MDN HTML-Elementreferenz unterscheiden.

Element	Anzahl
<o:p>	808,253
<g:plusone>	273,166
<fb:like>	111,806
<asp:label>	76,501
<inline>	53,026
<noindex>	51,604
<icon>	42,703
<block>	34,167
<red>	33,424
<ss>	27,451

Wir haben auch 21.403 h7-Elemente gefunden.

A11Y

Erste Regel der ARIA-Verwendung:

Wenn Sie ein natives HTML-Element [HTML51] oder Attribut mit den von Ihnen benötigten Semantiken und Verhaltensweisen verwenden können, anstatt ein Element umzuwidmen und eine ARIA-Rolle, einen Status oder eine Eigenschaft hinzuzufügen, um es zugänglich zu machen, dann tun Sie dies.

Landmark-Rollen

ARIA Landmark Roles helfen Benutzern, die unterstützende Technologien verwenden, um auf Ihrer Website zu navigieren.

Möglicherweise haben Sie diese Warnmeldung gesehen, wenn Sie ein Dokument validieren: „Die Bannerrolle ist für das Element Header unnötig“. Dies geschieht, weil Browser wie iOS Safari die oben genannten impliziten Zuordnungen derzeit nicht unterstützen und es vorerst eine gute Praxis ist, diese Landmark-Rollen weiterhin hinzuzufügen und die HTML-Validierungswarnungen zu vermeiden.

Bezüglich der impliziten HTML5-Zuordnungen, hier die Statistiken

Element	Anzahl
<nav role=navigation>	1,144,750
<header role=banner>	675,970
<footer role=contentinfo>	613,454
<main role=main>	236,484
<article role=article>	129,845
<aside role=complementary>	105,627
<section role=region>	4,326

autoplay

Video- und Audio-autoplay gilt als schlechte Praxis, nicht nur für die Barrierefreiheit, sondern auch für die Benutzerfreundlichkeit.

Also, verwenden Sie kein Autoplay und es wird all Ihren Benutzern gefallen.

Sehen Sie sich unten die Ergebnisse von insgesamt 108.321 video- und 64.212 audio-Elementen an.

Element	Anzahl
<video autoplay>	31,653
<video autoplay=true>	5,601
<audio autoplay>	2,595
<audio autoplay=true>	339
<video autoplay=false>	79
<audio autoplay=false>	22

maximum-scale

Maximum-scale definiert den maximalen Zoom, und wenn es auf maximum-scale=1 gesetzt wird, können Benutzer Ihre Seite nicht zoomen. Das sollten Sie nicht tun, da Zoomen ein wichtiges Barrierefreiheitsmerkmal ist, das von vielen Menschen genutzt wird, weil es eine bessere Erfahrung bietet, indem es die Bedürfnisse der Benutzer erfüllt.

Warnung aus dem HTML 5.2 Editor’s Draft, 4. Oktober 2016:

Autoren sollten die Möglichkeit der Benutzer, die Größe eines Dokuments zu ändern, nicht unterdrücken oder einschränken, da dies Probleme mit der Barrierefreiheit und Benutzerfreundlichkeit verursacht.

Wir haben jedoch 1.047.294 Websites gefunden, die maximum-scale=1 verwenden, und 87.169 Websites mit dem Wert user-scalable=no. Gleichzeitig verwenden 326.658 Seiten sowohl maximum-scale=1 als auch user-scalable=no.

role=button

Das Setzen von role=button für einen button ist erlaubt, wird aber nicht empfohlen, da der button bereits role=button als implizite ARIA-Semantik hat. Dennoch haben wir 26.360 button-Elemente gefunden, bei denen role=button gesetzt war.

Hier ist eine Aufschlüsselung anderer bemerkenswerter Elemente, deren Verhalten durch role=button überschrieben wurde

Element	Anzahl
<a role=button>	577,905
<div role=button>	85,565
<span role=button>	21,466
<input role=button>	8,286

MDN fasst zusammen, wie man anklickbare Dinge korrekt erstellt: MDN sums it up

Seien Sie vorsichtig, wenn Sie Links mit der Button-Rolle kennzeichnen. Von Buttons wird erwartet, dass sie mit der Leertaste ausgelöst werden, während Links erwartet werden, dass sie mit der Eingabetaste ausgelöst werden. Mit anderen Worten, wenn Links verwendet werden, um sich wie Buttons zu verhalten, reicht das Hinzufügen von role=”button” allein nicht aus. Es ist auch notwendig, einen Tastenereignis-Handler hinzuzufügen, der auf die Leertaste lauscht, um mit nativen Buttons konsistent zu sein.

SVG

Es gibt verschiedene Möglichkeiten, SVG in HTML einzufügen. Wir haben sie zusammengefasst und insgesamt 5.610.764 SVG-Referenzen gefunden.

Wie man SVG verwendet	%
Inline-SVG-Code innerhalb von HTML	97.05%
Verwenden von SVG als <img>	2.88%
Verwenden von SVG als <object>	0.05%
Verwenden von SVG als <embed>	0.02%
Verwenden von SVG als <iframe>	–

Die Verwendung der Methoden object, iframe und embed liegt unter 1 %.

data-*=svg

Es gibt 17.920 Elemente, deren Attributwert data-* die Zeichenfolge svg enthält. Die meisten Elemente sind <svg> oder <img>.

Top 5 data-* Werte

1. http://www.w3.org/2000/svg – 471
2. hg-svg – 127
3. svg-siteline-facebook – 114
4. icon-facebook.svg – 95
5. twitter.svg – 95

id*=svg

Es gibt 141.813 Elemente, deren id-Attributwert die Zeichenfolge „svg“ enthält. Die meisten Elemente sind <svg> oder seine inneren Elemente.

Top 5 id Werte

1. emotion-header-title-svg – 16.281
2. cicLeftBtnSVG – 5.793
3. cicPauseBtnSVG – 5.793
4. cicPlayBtnSVG – 5.793
5. cicRightBtnSVG – 5.793

class*=svg

Es gibt 329.004 Elemente, deren class-Attributwert die Zeichenfolge „svg“ enthält. Die meisten Elemente sind <svg>, <i>, <img> oder innere Elemente.

Top 10 class Werte

1. sqs-svg-icon--social – 58.501
2. nav_svg – 29.826
3. svg – 28.604
4. mk-svg-icon – 24.193
5. svg-icon – 12.255
6. icon_svg – 7.956
7. ico ico-svg ico-40-svg – 3.980
8. svg temp_no_id temp_no_img_src – 3.794
9. svgIcon-use – 3.127
10. svg temp_no_img_src – 3.017

In Bezug auf die oben genannten Top-Ergebnisse ist es vielleicht erwähnenswert, dass sqs-svg-icon--social eine (BEM-ähnliche) Benennungskonvention ist, die von Squarespace-Websitenvorlagen verwendet wird.

currentColor

Es gibt 868.194 innere SVG-Elemente, die den Wert currentColor enthalten, hauptsächlich für die Attribute fill oder stroke.

Top 10 SVG-Elemente

1. <symbol> – 845.626
2. <path> – 12.834
3. <g> – 6.073
4. <path> – 3.207
5. <circle> – 1.885
6. <svg> – 1.061
7. <polygon> – 575
8. <rect> – 480
9. <line> – 412
10. <use> – 206

SVG als Hintergrundbild (Die Reise!)

Um herauszufinden, ob ein Element SVG als Hintergrundbild verwendet, war die Sache komplizierter. Die meisten unserer Daten verwendeten nur die HTML-Dokumente, aber wir haben eine Lösung erarbeitet, um die aktiven Stylesheets zu erhalten.

Von insgesamt 6.359.031 Domains, von denen wir Daten sammeln konnten, verwenden 84,5 % (5.371.806) HTML-Elemente mit CSS-Hintergrundbildern, während nur 1,2 % (82.008) Domains mindestens ein SVG-Hintergrundbild verwendeten.

Von insgesamt 92.388.615 HTML-Elementen mit CSS-Hintergrundbildern verwenden 0,5 % (439.447) ein SVG-Hintergrundbild.

Der Prozess

Wir haben alle HTML-Dateien durchgesehen und lokale/relative CSS-Dateireferenzen in absolute umgewandelt, z. B. wurde <link rel="stylesheet" href="style.css"> zu <link rel="stylesheet" href="http://www.domain.com/style.css">.

Dies hat einige Zeit in Anspruch genommen, da wir einige Ergebnisse unserer ersten Durchläufe stichprobenartig untersucht haben, Inkonsistenzen in den Ergebnissen festgestellt haben und den Prozess neu starten mussten. Bei einer gezippten Dateigröße von 65 GB (und entpackt 323 GB) war es keine Überraschung, dass die Verarbeitung einige Tage dauerte, um die obigen Ergebnisse zu erzielen.

PhantomJS ausprobiert und abgebrochen

Da Hintergrundbilder über CSS angewendet werden können, brauchten wir etwas, um das DOM zu rendern und Stile darauf anzuwenden. Wir dachten an ein Tool, mit dem wir sehr vertraut waren: PhantomJS. Wir haben ein paar Tests mit tatsächlichen Seiten durchgeführt und gesehen, dass alles ordnungsgemäß zu funktionieren schien. Wir haben dann unseren Java-Client gebaut, um mit dem PhantomJS-Webserver zu kommunizieren: starten, Seiten öffnen, Ausgabe extrahieren, Antworten verarbeiten, Ergebnisse speichern und dann aufräumen, stießen jedoch auf katastrophale Leistungsergebnisse, als wir versuchten, den Rendering-Prozess auf nur einer Maschine zu verwenden und zu skalieren.

Das Rendern einer HTML-Datei dauerte zwischen einigen Sekunden und einigen Minuten, und wir hatten keine Möglichkeit zu wissen, was PhantomJS tat. Dies, zusammen mit der Tatsache, dass die Ressourcennutzung exponentiell ansteigt, je größer das DOM ist, führte dazu, dass wir es aufgaben und nach Alternativen suchten.

Mehr Glück mit Selenium

Wie es der Zufall wollte, experimentierte ein Kollege mit Selenium auf Basis von headless Chrome. Da er in allen Bereichen, in denen PhantomJS Mängel aufwies, ermutigende Ergebnisse erzielte, dachten wir darüber nach, die Java-do-it-all-Komfortzone zu verlassen und Aufgaben bei Bedarf an andere Tools zu delegieren. Die Testergebnisse waren sehr vielversprechend – headless Chrome schien unseren Anforderungen wunderbar zu entsprechen: superschnelle Startzeit, großartige Rendering-Zeit und volle Kontrolle über das Beenden eines Prozesses.

Der Selenium-Webtreiber würde die Binärdatei tatsächlich schließen, im Gegensatz zu uns, die einen exit-Befehl an PhantomJS sendeten und hofften, dass es nicht zu 100 % ausgelastet war, damit es ihn tatsächlich verarbeiten würde. Dies ermöglichte es uns, jeden Prozess einzeln zu steuern, ohne alle paar Minuten killall verwenden zu müssen und alle Prozesse zu stoppen, falls nur einer von ihnen verrückt spielte und die CPU drosselte.

Das einzige Problem bei diesem Ansatz war, dass das JavaScript nicht mehr in einer einzigen, eigenständigen JS-Datei enthalten sein konnte, die wir an das PhantomJS-Executable übergeben würden, sondern inline in die tatsächlichen HTML-Dateien aufgenommen werden musste. Hier ist eine vereinfachte Version des Skripts, das wir verwendet haben und das auf der Methode Window.getComputedStyle() basiert

let backgroundImages = [],
    allElem = document.querySelectorAll("*"),
    allElemLength = allElem.length;

for (let i = 0; i < allElemLength; i++) {
  let style = window.getComputedStyle(allElem[i], false),
  backgroundImage = style.backgroundImage.slice(4, -1);
  backgroundImages.push(backgroundImage);
}

Das Speichern von Daten würde durch Aufrufen eines einfachen PHP-Skripts erfolgen. Wir haben ein paar größere Tests durchgeführt, um unsere Wahl zu validieren, und alles funktionierte einwandfrei, also haben wir mit der Einrichtung einer skalierbaren Umgebung fortgefahren.

Wir haben alle HTML-Dateien (erneut) verarbeitet und das obige JavaScript-Snippet eingefügt. Die nächste Herausforderung war das Hochladen von allem auf Amazon. S3Browser, den wir für „lockeres“ Auflisten und Herunterladen/Hochladen verwenden, schien für diesen Job nicht schnell genug zu sein (zumindest nicht die kostenlose Version). Also suchten wir nach einer Alternative und stießen auf s3-parallel-put.

Wir haben es auf einer lokalen Linux-Maschine eingerichtet, die SSD verschoben und 65 GB gezippte Textdaten in kürzester Zeit hochgeladen. Es hat unsere Maschine und den lokalen Jenkins-Server, der darauf lief, lahmgelegt – bis wir die alte Q9550 CPU aufgerüstet haben :).

Die Probleme traten auf, als wir anfingen zu skalieren. Wir sahen, dass unser einzelner Webserver überfordert wurde und aufhörte, Ergebnisse zu speichern, obwohl der Selenium-Treiber meldete, dass die Seite erfolgreich gerendert worden war. Dies bedeutete auch, dass viele unserer Warteschlangennachrichten verschwendet wurden (verbraucht und aus der Warteschlange gelöscht), ohne Ergebnisse zu erzielen.

Wir haben uns daher entschieden, ein genauer geprüftes System zur Verfolgung verarbeiteter/unverarbeiteter Dateien mithilfe von Redis zu verwenden: Jedes Mal, wenn wir mit der Verarbeitung einer Datei begannen, fügten wir den Domainnamen in ein Redis-Set ein. Jedes Mal, wenn wir eine Datei verarbeiteten (unser PHP-Skript wurde aufgerufen), fügten wir den Domainnamen in ein anderes Redis-Set ein. Der Sinn war, die Differenz zwischen den beiden auf ein Minimum zu beschränken (alles über einem bestimmten Wert würde bedeuten, dass etwas nicht richtig funktionierte) und das Wiederholen einfach zu gestalten, falls es jemals nötig sein sollte.

Hardware-Setup

Für unser Hardware-Setup haben wir mit 10 Threads * 1 Chrome-Instanz auf 10 Amazon c4.large Maschinen begonnen, die von einem Apache-Webserver auf einer m3.medium bedient wurden, was anfangs eine sehr schlechte Leistung erbrachte. Nachdem wir mit den Apache-Einstellungen herumgespielt hatten, haben wir alles schrittweise skaliert und sind zu 40 c4.large Maschinen gekommen, die von Apache-Webservern auf 4 m3.medium Maschinen hinter einem Load Balancer bedient wurden. Unsere Redis-Instanz bediente alle 10 Threads * 40 Maschinen * 3-4 Anfragen pro 5-20 Sekunden von einer r3.large Maschine aus. Das sind also etwa 60-320 Anfragen pro Sekunde.

Was die Kosten betrifft, ist es ziemlich schwierig, einen Gesamtbetrag der ausgegebenen Gelder oder der CPU-Zeit anzugeben, da wir auf viele Probleme stießen, bevor wir ein voll funktionsfähiges und stabiles Ökosystem hatten. Im Idealfall würde eine einzelne Maschine etwa 45 Sekunden für die Verarbeitung von 100 Dateien benötigen: Herunterladen, Entpacken, Rendern und Aufräumen.

F&A / Follow-up

Warum so viele tbody-Elemente?

Für die oben genannten neuen Daten haben wir einen weiteren vollständigen Scan für die 8 Millionen Dokumente durchgeführt und auch ein Problem bei der Bereinigung des Parsers behoben, bei dem der jsoup-Parser das tbody-Element automatisch für alle Tabellen hinzufügte. Dies ist die Antwort auf die Frage, die einige von Ihnen in den Kommentaren gestellt haben: „Warum so viele tbody-Elemente?“.

Als Folge davon ist die Anzahl der auf den meisten Seiten verwendeten Elemente jetzt 25, wobei die tbody-Statistiken jetzt reduziert sind.

body bei 99%?

Eine kleine Auffrischung: Gemäß den Spezifikationen ist das Weglassen von body in Ordnung: Start-Tag: optional, End-Tag: optional.

Eines der überraschendsten Ergebnisse, basierend auf Ihren Kommentaren, war die fehlende 1 % der body-Elemente. Ich schätze, ich schulde Ihnen eine Antwort, dafür bin ich etwas tiefer gegangen und habe den Parser erneut ausgeführt, um einige Einblicke zu erhalten

• Wie einige von Ihnen bereits vermutet haben, fehlt bei den meisten Seiten das body-Tag aufgrund der hohen frameset-Nutzung.
• Die clientseitige Weiterleitungsmethode mit meta http-equiv="refresh", gefolgt von keinem body-Inhalt, ist ein weiterer Grund.
• Es ist ziemlich enttäuschend zu sehen, dass unter den Seiten, die auf Google hoch ranken sollen, viele die grobe JavaScript-Lösung window.location verwenden, um Benutzer auf andere Domains umzuleiten. Auch diese Art von Seiten enthält überhaupt nicht den body-Abschnitt.
• Einige der Seiten, die als fehlendes body gekennzeichnet waren, waren aufgrund von beispielsweise PHP-Fehlern völlig fehlerhaft. Einige ließen das beginnende body-Tag weg, aber nicht das End-Tag.

Möchten Sie mehr?

Haben Sie ein Element/Attribut, für das Sie die Zahlen sehen möchten? Melden Sie sich bei mir auf Twitter oder hinterlassen Sie unten einen Kommentar, und wir werden uns etwas überlegen!

Schauen Sie sich auch unbedingt hier die vollständigen Statistiken an.