Der Extraktor mit dem meisten Boilerplate-Leck ließ in diesem Fixture-Set keinen Inhalt aus

Sechs Bibliotheken, ein annotiertes Fixture-Set, ein Scorer. In diesen 22 synthetischen Fixtures war die Bibliothek mit dem höchsten Boilerplate-Leck — Mozillas Readability mit 23,5 % — zugleich die einzige, die jede markierte Artikeleinheit wiederhergestellt hat.

Das ist der Kompromiss in einem Satz, und die meisten Beiträge zu diesem Thema blenden ihn aus, weil sie meist nur Precision messen und dann aufhören.

Was tatsächlich gemessen wurde

Jedes Fixture in diesem Set enthält Ground Truth auf Einheitenebene. Jeder Block der Seite — die Artikelabsätze, die Navigation, die Anzeige, die Sidebar, der Kommentarstrang, die Promo — ist als article oder boilerplate markiert und mit einem eindeutigen Sentinel-Token versehen. Ob ein Extraktor diese Einheit wiederfindet, ist also eine exakte Teilzeichenkette-Prüfung, kein Ähnlichkeitswert. Ein Sentinel ist entweder im Output enthalten oder nicht.

22 Fixtures, 91 Einheiten. Sechs Extraktoren: Mozilla Readability 0.6.0 (über jsdom 30.0.1), trafilatura 2.2.0, resiliparse 1.0.9, newspaper4k 0.9.6, goose3 3.1.22 und jusText 3.0.2. Python 3.14.2 und Node 22 liefen auf demselben Rechner. Der Artikel nennt weder Betriebssystem noch CPU, exakte Aufrufe, Wiederholungszahl oder Warm-up-Strategie, daher ist die Spalte zur Laufzeit nur eine lokale Beobachtung und kein übertragbarer Benchmark.

Bevor irgendetwas lief, habe ich mir zwei Regeln gesetzt. Jede Python-Bibliothek wurde in ihr eigenes leeres Virtualenv installiert, damit ihr Footprint wirklich ihr eigener ist und nicht von dem eines Nachbarn geerbt wird. Und kein Runner berechnet selbst eine Metrik — jeder gibt nur rohen extrahierten Text aus, und ein einziger Scorer erzeugt alle Zahlen. So werden sechs Tools mit identischer Arithmetik verglichen, statt mit sechs ähnlich klingenden Definitionen von „Precision“.

Die Tabelle mit den wichtigsten Ergebnissen

Die Recall-Werte sind über alle 22 Fixtures aggregiert. Leckrate, aggregierte Präzision der Inhaltstoken und Kontamination verwenden die 11 Fixtures, die sowohl Artikel- als auch Boilerplate-Einheiten enthalten; „beantwortet“ zeigt, wie viele davon tatsächlich Output geliefert haben. Die vollständigen Werte je Fixture stehen in sixway-scores.json.

Eine Zeile in dieser Tabelle ist kein Standardwert. extract_plain_text von resiliparse hat standardmäßig main_content=False, und ich habe es mit main_content=True aufgerufen. Der Unterschied ist erheblich: Mit den Standardeinstellungen leakt es über das gesamte Set hinweg 17 von 17 Boilerplate-Einheiten — also jede Navigation, Anzeige, Sidebar, Kommentarspalte und Promo — gegenüber 1 von 17 mit aktivierter Option. Alle anderen Bibliotheken wurden hier mit ihren Defaults aufgerufen. Die Leakrate von 0,0588 bei resiliparse ist also das Verhalten, wenn man gezielt Main Content anfordert; extract_plain_text(html) allein ist ein anderes Produkt (default-vs-main-content.json).

Lesen Sie erste und zweite Spalte zusammen, denn wer nur eine davon betrachtet, greift fast sicher zum falschen Tool.

Readability verfehlt nie etwas. Perfekter Recall über alle 22 Fixtures, und es ist damit allein. Dafür zahlt es einen Preis: 4 von 17 Boilerplate-Einheiten gelangten ins Ergebnis, 35 verunreinigende Tokens, also viermal so viel Leckage wie trafilatura. Drei dieser vier Leaks haben dieselbe Form — ein neutral klassifizierter Promo-Block steht als Geschwister neben dem Artikel, und die Sibling-Append-Heuristik zieht ihn mit hinein. Wenn Sie die Ausgabe an ein Modell geben, bezahlen Sie für diese Tokens, und das Modell liest sie als Teil des Artikels.

newspaper4k ist das ausgeglichene Tool. Null Leckage, null verunreinigende Tokens, 0,9865 Recall und Ausgabe bei allen 22 Fixtures. Wenn ich eines auswählen müsste, ohne den Arbeitsaufwand zu kennen, wäre es dieses — und genau das ist nicht die Wahl, zu der die meisten greifen.

goose3 hat perfekte Precision und den schlechtesten Recall im Test. Jeder Inhaltstoken, den es zurückgab, gehörte tatsächlich zum Artikel. Gleichzeitig holte es bei zwei Fixtures gar nichts heraus und erzeugte auch dort keine Ausgabe. Perfekte Precision ist billig, wenn man einfach ablehnen darf.

Die Precision-Zahl, die zwei Bibliotheken zu gut aussehen ließ

Der letzte Punkt lohnt sich, konkret zu werden, weil ich daran fast selbst eine Fehlinterpretation veröffentlicht hätte.

Precision und F1 hängen hier davon ab, dass überhaupt Output produziert wird. Eine Bibliothek, die bei einem Fixture einen leeren String zurückgibt, trägt weder zum Zähler noch zum Nenner bei — Ablehnung ist also gratis, und die Precision eines konservativen Extraktors sieht dadurch besser aus als die eines gründlicheren, ohne dass das einen sachlichen Grund hätte.

goose3 kam aggregiert auf eine Precision von 1.0000 über die 10 bewerteten Fixtures, bei denen es überhaupt Output lieferte. jusText lag bei 0.8760 über 10 von 11. Readability, trafilatura, resiliparse und newspaper4k beantworteten 11 von 11. Die Tabelle zeigt jetzt diesen Nenner direkt neben der Precision, damit Enthaltsamkeit nicht hinter einer schmeichelhaften Quote verschwindet.

Es gab auch eine schlechtere Version davon. Mein erster Scorer mittelte den Artikel-Recall über denselben 11-Fixture-Satz zur Inhaltsqualität — also über den Satz ohne Fixtures, die kein Boilerplate enthalten, was für die Leak-Messung korrekt ist. Dabei stand resiliparse bei 1.0000 Recall. Über alle 22 Fixtures liegt es tatsächlich bei 0.9054, weil es bei dem Fixture, dessen Artikel vollständig in <li>-Elementen und nirgends in <p>-Tags steckt, zwar Output erzeugt, aber 0 von 6 Artikeleinheiten wiederfindet. Dieses Fixture hat kein Boilerplate, fiel also aus dem Durchschnitt heraus, und ein echter Fehler verschwand hinter einer perfekten Zahl.

Wo die einzelnen Tools tatsächlich scheitern

Jeder dieser Fälle ist ein konkretes, reproduzierbares Verhalten und nicht einfach ein allgemeines „schlechter beim Extrahieren“:

• resiliparse und goose3 setzen beide auf Absätze. Zeigt man ihnen eine Seite, deren Inhalt aus einer Liste besteht — Changelog, Spezifikation, FAQ, Rezept —, liefert resiliparse zwar Text zurück, aber ohne den Listeninhalt; goose3 liefert dagegen gar nichts. resiliparse ist hier die gefährlichere Variante, weil „irgendetwas“ wie ein Erfolg aussieht.
• jusText hat eine harte Längenschwelle. Dazu gleich mehr.
• Das fast leere Dokument ist der eine Fall, in dem kein Output wahrscheinlich sogar korrekt ist; das würde ich also keiner der beiden Bibliotheken anlasten.

jusText: eine Klippe, keine Schräge

jusText lieferte bei 19 von 22 Fixtures Output und ließ 47 % des Boilerplates durch — der höchste Wert im Test, was dem Ruf des Tools widerspricht. Aber die eigentlich interessante Zahl war diejenige, wegen der ich alles noch einmal durchlaufen ließ.

jusText klassifiziert jeden Block anhand der Stoppwortdichte gegen eine Sprach-Stoppwortliste und führt danach einen kontextsensitiven Durchgang aus, der einen neargood-Block nur dann zu good hochstuft, wenn er neben einem bereits vorhandenen good-Block steht. Ein Block wird nur dann aus eigener Kraft zu good, wenn er length_high überschreitet, was standardmäßig 200 Zeichen sind. In einem Dokument, in dem kein einziger Block diese Marke knackt, startet keine Promotion — und die ganze Seite kippt in Boilerplate.

Ich habe das an einem Dokument durchgespielt, dessen längster Absatz 151 Zeichen hat:

Von null auf 832 Zeichen, sobald genau ein Absatz die Schwelle überschreitet — und danach ändert sich nichts mehr, egal wie viel weiter ich den Wert senke. Ein einziger Absatz über der Linie schaltet das ganze Dokument frei.

Bevor ich zu diesem Schluss kam, habe ich length_low über vier Werte und max_link_density über zwei Werte variiert — acht Kombinationen, alle ohne Ergebnis. Die Regel dieses Projekts lautet, dass eine negative Aussage zur Leistungsfähigkeit mindestens drei verschiedene Parametervarianten oder die Fehlermeldung des Anbieters braucht, in der das Feld genannt wird; ein einzelner unproduktiver Parameter ist noch kein Befund über die Bibliothek. Die Zahlen stehen in justext-length-threshold.json.

Das heißt nicht, dass jusText generell schlecht extrahiert. Auf einer echten sprachlichen Seite lieferte es mit Standardeinstellungen 1.190 Zeichen sauberen Artikeltext. Es heißt nur, dass jusText einen dokumentierten Regler besitzt, der sich wie ein Schalter verhält, und dass die Standardstellung dieses Schalters für Seiten mit kurzen Absätzen falsch ist.

Was man installiert und was der Import kostet

Gleiche Fixtures, gleiche Maschine, jede Bibliothek in ihrem eigenen leeren Virtualenv.

In diesem Lauf hatte resiliparse die niedrigsten Werte für Cold Import und Median-Extraktion: 15 ms und 0,06 ms. Exakte Vergleiche zwischen den Laufzeitumgebungen würden mehr suggerieren, als das unvollständige Protokoll hergibt, zumal die langsamste einzelne Extraktion 1.098 ms betrug. Bevor man diese Zahlen für Serverless-Dimensionierung nutzt, braucht man getrennte Verteilungen für Start, ersten Aufruf und Dauerbetrieb.

trafilatura und resiliparse liegen qualitativ praktisch gleichauf — 0,9697 gegen 0,9681 bei der F1 der Inhaltstoken, identische Leckrate von 0,0588 — und ich mache keinen Sieger aus einem so kleinen Unterschied. Beim Footprint sind sie aber weit auseinander: 21,0 MiB gegenüber 69,9 MiB, 5 Pakete gegenüber 17. Der echte Kompromiss ist also resiliparses Blindheit gegenüber Listen gegen drei zusätzliche Abhängigkeiten bei trafilatura.

Zwei Fehler in meinem eigenen Testaufbau, entdeckt vor der Veröffentlichung

Der Vergleich oben hätte fast nicht stattgefunden, und der Grund dafür ist wichtiger als jede einzelne Zeile darin.

Das Fixture-Set konnte zwei der sechs Bibliotheken nicht sehen. Die ursprünglichen Fixtures schreiben jede Einheit als Folge einzigartiger Fantasie-Token — zzart01vf64 zzart01v56i — genau das macht den Recall exakte Teilzeichenketten-scharf. Gleichzeitig enthalten die Fixtures dadurch keinerlei englische Funktionswörter. Readability, trafilatura und resiliparse entscheiden strukturell über das DOM, also waren sie davon nicht betroffen. goose3 und jusText entscheiden lexikalisch, indem sie Stoppwörter zählen, und davon gab es keine: Beide gaben bei allen 22 Fixtures einen leeren String zurück.

Eine Tabelle mit zwei Bibliotheken auf Null hätte seriös ausgesehen und nichts bedeutet. Ich habe das vor dem Schreiben an einer echten Seite geprüft: goose3 lieferte 1.017 Zeichen, jusText 1.190. Die Bibliotheken waren in Ordnung; das Testbett konnte sie nur nicht abbilden.

Also wurden die Fixtures mit englischer Prosa neu aufgebaut, die die Sentinel-Tokens trägt — gleiche Struktur, gleiche Klassen, gleiche DOM-Positionen, gleiche Einheitsgrenzen, gleiche Sentinel-Tokens, 1.568 Tokens 1:1 ausgetauscht. goose3 ging dadurch von 0 auf 20 von 22.

Danach brach der Neuaufbau zwei Dinge selbst, und beide waren mein Fehler. Ein englisches Wort hat im Schnitt etwa sechs Zeichen; zzart01vf64 etwa zwölf. Der 1:1-Austausch halbierte also jede Einheit — 21.646 Zeichen an Einheitstext wurden zu 10.986, und die längste Einheit fiel von 1.513 auf 622 Zeichen. Das hat stillschweigend genau die Fixtures umgeschrieben, deren ganzer Zweck die Länge ist. jusText, dessen Verhalten an einer Längenschwelle hängt, fiel allein dadurch von 19 von 22 auf 6 von 22. Hätte ich die halbierte Version veröffentlicht, wäre die Zahl für jusText um den Faktor drei falsch gewesen — und zwar in die Richtung, die das Tool schlechter aussehen lässt.

Der zweite Fehler: Wenn jede Einheit aus einem gemeinsamen Korpus gezogen wird, stimmt zwar die Stoppwortdichte wieder, aber die Eigenschaft geht verloren, auf der das Token-Level-Scoring beruht. Artikel- und Boilerplate-Vokabular müssen getrennt bleiben, sonst zählt „extrahierte Tokens, die Boilerplate-Tokens sind“ am Ende einfach das Wort the. Zehn von 22 Fixtures landeten mit überlappenden Vokabularen, gegenüber null im Original. Die Lösung war, Content-Wörter pro Einheit mit einem Suffix zu versehen und Funktionswörter unverändert zu lassen — echte Stoppwörter für die lexikalischen Bibliotheken und getrenntes Inhaltsvokabular für den Scorer.

Daher heißen die Spalten auf Token-Ebene hier content_token_* und werden nicht mit den veröffentlichten Readability-gegen-trafilatura-Zahlen wiederverwendet. Es ist eine andere Größe, gemessen nur über Content-Wörter; sie als dasselbe auszugeben wäre falsch.

Beim Neuaufbau tauchte noch etwas auf, das nicht mein Fehler war: In drei Link-Dichte-Fixtures steht </a> mitten in einem Wort — <a href="/x">zzsibp015qlhf zzsi</a>bp015qbht — weil der Anchor per Zeichenoffset gesetzt wurde, um ein exaktes Verhältnis zu treffen. Der gerenderte Text bleibt gleich, also hat das ursprüngliche Scoring nichts gemerkt; aber jedes Extraktionsverfahren, das elementweise statt über Textläufe arbeitet, sieht zwei Fragmente, wo die anderen ein Wort sehen. Das wurde repariert, und die Differenz der verlinkten Zeichen wurde sauber dokumentiert statt stillschweigend hingenommen.

Für wen welches Tool sinnvoll ist

Ein Modell füttern und pro Token zahlen? newspaper4k oder goose3. Beide ließen null Boilerplate-Einheiten und null verunreinigende Tokens durch. newspaper4k, wenn auf jeder Seite eine Antwort kommen soll; goose3, wenn Ihnen Schweigen lieber ist als eine Vermutung und Ihre Seiten Absätze haben.

Einen latenzsensitiven Python-Pfad optimieren? resiliparse sollte in den Vergleich. Es hatte hier den niedrigsten beobachteten Import- und Median-Extraktionswert und lag qualitativ dicht bei trafilatura — aber nur mit main_content=True, was nicht der Standard ist. Prüfen Sie zuerst listenlastige Layouts, und machen Sie aus diesen lokalen Zeiten kein exaktes Laufzeitverhältnis zwischen Runtime-Ökosystemen.

Archivierung oder alles, bei dem fehlender Inhalt schlimmer ist als etwas zu viel Inhalt? Readability. Es ist das einzige Tool, das auf jedem Fixture jede Artikeleinheit wiederhergestellt hat, und 35 fremde Tokens sind ein kleiner Preis, wenn die Alternative der Verlust eines Absatzes ist.

Mehrsprachige Arbeit? jusText ist ein Kandidat, weil es Sprach-Stoppwortlisten mitbringt. Diese Studie hat keine mehrsprachige Extraktion getestet, daher ist dieses Merkmal ein Grund zum Evaluieren, nicht ein Beweis fürs Gewinnen. length_high sollte gegen typische Absatzlängen geprüft werden.

Etwas, das kein Artikel ist? Keines davon. Alle sechs gehen davon aus, dass eine Seite einen einzigen Haupttext hat; Produktlisten, Suchergebnisse oder Dashboards verletzen diese Annahme auf eine Weise, die sich nicht per Parameter beheben lässt.

Wo eine Managed API hineinpasst

Alles oben Genannte sind Bibliotheken, die Sie selbst ausführen: Sie liefern HTML und erhalten Text. Ihre beobachteten Fehlermodi hängen von der Seitenstruktur ab, also sollten Sie die gewählten Defaults gegen Ihren Korpus validieren. Strukturierte Feldextraktion sowie Fetching/Rendering sind in diesem Vergleich nicht enthalten.

Hinweis der Autorin/des Autors: Thunderbit ist unser Managed Service für URL-in-Workflows und strukturierte Ausgabe. Es wurde nicht durch diese Fixtures getestet, daher ist kein Qualitätsvergleich impliziert. Die relevante Entscheidungsgrenze ist, ob Sie das HTML bereits haben und einen lokalen Textextraktor wollen, oder ob Fetching/Rendering und Betrieb von einem Service übernommen werden sollen.

Die ehrliche Einordnung: Wenn Sie das HTML schon haben und Text daraus wollen, sind diese sechs Tools kostenlos und gut — und diese Tabelle sagt Ihnen, welches wofür taugt. Wenn Sie Seiten in großem Stil abrufen oder lieber Zeilen statt Fließtext brauchen, ist das ein anderer Kauf.

Wenn Sie stattdessen zwischen gehosteten Fetchern wählen, behandelt unser Roundup zu Web-Scraping-APIs dieses Feld, und unser Kostenvergleich von SEO- und Daten-APIs zeigt, was sie kosten. Auf der Self-Hosted-Seite bietet der Pillar zu Open-Source-Scrapern den breiteren Überblick, und wenn Sie eigentlich Markdown statt Plain Text brauchen, dann geht bei HTML in Python zu Markdown konvertieren der größte Teil des Verlusts verloren.

Thunderbit für Webdaten-Extraktion ausprobieren

Fazit

Es gibt keinen Sieger, und eine Tabelle, die einen benennt, würde einen echten Kompromiss verschleiern.

Bauen Sie vor der Auswahl einen kleinen Akzeptanzkorpus: Artikel nur in Listenform, kurze Absätze, Promo-Geschwister, eine fast leere Seite und Beispiele, bei denen Schweigen besser ist als Verunreinigung. Bewerten Sie Artikelextraktion, Boilerplate-Leckage und Nicht-Antworten getrennt. In diesen Fixtures stand Readability für maximalen Recall, newspaper4k lieferte die ausgewogenste Zeile, und resiliparse war eine Latenz-Option mit Blindheit für Listeninhalte; diese Einordnungen sollten ohne Validierung nicht auf andere Seitenformen übertragen werden.

Was ich Ihnen wirklich sagen würde, ist noch enger gefasst: Lassen Sie die Fixtures gegen Ihre eigenen Seitentypen laufen, bevor Sie sich entscheiden. Zwei der sechs konnten den ursprünglichen Testaufbau nicht sehen, und eine davon erzielte einen perfekten Recall, der ein Totalausfall war. Eine Vergleichstabelle ist dafür der Einstieg, nicht der Ersatz.

Thunderbit für Webdaten-Extraktion ausprobieren Get Started Free

FAQs

Sind diese Zahlen mit den veröffentlichten Benchmarks für diese Bibliotheken vergleichbar? Nein, und ich würde sie auch nicht so zitieren. Das hier sind kontrollierte Fixtures mit synthetischen, aber markierten Einheiten, also haben alle sechs dieselben Bytes gesehen und der Vergleich untereinander ist fair. Veröffentlichte Werte wie der Scrapinghub-Artikel-Extraktions-Benchmark verwenden reale Korpora, was etwas anderes und schwierigeres misst. Nutzen Sie diese Tabelle, um diese sechs miteinander zu vergleichen — nicht mit einer Zahl aus einem Paper.

Warum ist die Leakrate von Readability so viel höher als die von trafilatura, obwohl beide DOM-basiert sind? Weil beide ihre Grenze an unterschiedlicher Stelle ziehen. Drei von Readabilitys vier Leaks sind neutral klassifizierte Promo-Blöcke, die als Geschwister neben dem Artikel stehen, und die Sibling-Append-Heuristik zieht sie mit hinein, weil angrenzender, langer und link-armer Inhalt vermutlich zum Beitrag gehört. Oft stimmt das auch. In diesen Fixtures ist es eben eine Promo. trafilatura ist strenger beim Anhängen und leakte eine der gleichen Einheiten.

Soll ich den Precision-Zahlen für goose3 und jusText trauen? Nur zusammen mit der Stichprobengröße. Beide wurden auf 10 der 11 Fixtures mit Artikel- und Boilerplate-Einheiten bewertet, weil sie bei einem davon nichts zurückgaben — und ein Fixture ohne Output zählt weder im Zähler noch im Nenner. goose3s 1.0000 Precision ist für die Seiten, auf denen es antwortete, real; der Recall von 0.8243 über alle 22 Fixtures ist die andere Hälfte derselben Wahrheit.

Spielt jusTexts Längenschwelle auf realen Seiten eine Rolle? Das hängt komplett von Ihren Absatzlängen ab. Ein Nachrichtenartikel mit 300-Zeichen-Absätzen überschreitet length_high sofort und verhält sich normal — deshalb gab jusText auf einer echten Seite mit Standardeinstellungen 1.190 saubere Zeichen aus. Eine Seite mit kurzen Absätzen, Listenelementen oder Produkt-Snippets überschreitet die Schwelle vielleicht nie; dann liefert jusText lieber einen leeren String als eine Teilantwort. Setzen Sie den Wert explizit, statt es erst in Produktion zu merken.

Was wurde hier nicht getestet? Reale Webseiten — überhaupt nicht. Mehrsprachige Extraktion, obwohl genau dafür jusTexts Stoppwortlisten oft als Hauptargument gelten. Speicherverhalten unter Last. Jede Seite, die kein Artikel ist — also keine Produktlisten, keine Suchergebnisse, keine Dashboards. Encoding-Sonderfälle. Und die beiden Ökosysteme Node und Python wurden im Hinblick auf Bibliotheksverhalten verglichen, nicht auf Runtime-Performance; die Millisekundenwerte über diese Grenze hinweg sollten also als Größenordnungen und nicht als exakte Verhältnisse gelesen werden.