In dieser Folge sprechen wir mit Frederik Braun [https://frederik-braun.com/] (Mastodon [https://social.security.plumbing/@freddy]) aus dem Firefox-Security-Team bei Mozilla [https://www.mozilla.org/] über den langen Weg der Sanitizer API: Von ersten Prototypen vor über fünf Jahren bis zum geplanten Shipping in Firefox und Chrome im Februar 2026 [https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_API#browser_compatibility].

Schaunotizen

[00:01:08] Die Sanitizer API [https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_API] Einleitend klären wir, warum Cross-Site-Scripting [https://en.wikipedia.org/wiki/Cross-site_scripting] (XSS) auch 2026 noch eines der größten Web-Security-Probleme ist, weshalb bestehende Lösungen wie DOMPurify [https://github.com/cure53/DOMPurify], Content Security Policy [https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP] oder Trusted Types [https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API] zwar helfen, aber kaum breit eingesetzt werden – und dass die Sanitizer API einen neuen, deutlich praxisnäheren Ansatz verfolgt.Die Sanitizer API [https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_API] ist ein neuer Web-Standard, mit dem sich unsicheres HTML direkt beim Einfügen in den DOM bereinigen lässt – ohne String-Roundtrips und ohne zusätzliche Bibliotheken. Statt Element.innerHTML = html wird künftig Element.setHTML(html) [https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML] verwendet. Der Browser übernimmt Parsing, Bereinigung und Einfügen in einem Schritt und verhindert zuverlässig Cross-Site-Scripting, DOM-Clobbering und viele Varianten von Mutated-XSS.

Links

Revision 447: XSS und die HTML Sanitizer API [https://www.workingdraft.de/447/] Die eingangs erwähnte, mittlerweile fünfeinhalb Jahre alte Folge mit Frederik, in der XSS und die ursprüngliche Idee der Sanitizer API bereits ausführlich besprochen wurden. Revision 452: CORS, CORP, (C)ORB, COOP und COEP [https://www.workingdraft.de/447/] Eine weitere Folge mit Security-Fokus, nämlich zu diversen sicherheitsrelevanten HTTP-Headern, ebenfalls mit Frederik. Revision 514: ASTs, Linter und Security mit Frederik Braun [https://workingdraft.de/514/] In dieser Revision reden sprechen wir mit Frederik über Abstract Syntax Trees, Lexer und Parser. Und natürlich Security! DOM Clobbering [https://portswigger.net/web-security/dom-based/dom-clobbering] Angriffstechnik, bei der HTML-IDs oder Names bestehende JavaScript-Objekte überschreiben und so Logikfehler oder Sicherheitslücken auslösen. Höre dazu auch Revision 202: Sicherheitslücken – DOM Clobbering, XSS via CSS, ES6 Fallen [https://workingdraft.de/202/]. Interop-Projekt [https://web.dev/interop/] Browser-übergreifende Initiative zur Angleichung von Web-Plattform-Features, potenziell relevant für Trusted Types in zukünftigen Iterationen.

Revision 697: Die Sanitizer API, mit Frederik Braun

Dieses Interview ist Teil der Serie On Tour @ #t3con. T3CON [https://t3con.typo3.com/] ist die jährliche Konferenz, bei der es um alle Themen rund um TYPO3 geht. Wir waren am 25. November 2025 in Düsseldorf beim Community Day vor Ort und haben die Stimmung und einige Interviews mitgenommen.

Incluthon: Inklusion testen statt abhaken

Auf dem Community Day der T3CON in Düsseldorf sprechen wir mit Stefan Barac (LinkedIn) [https://www.linkedin.com/in/stefanbarac/] über Incluthon [https://sites.google.com/view/incluthon/start]: eine Initiative, die Menschen mit Behinderungen mit Unternehmen zusammenbringt, um digitale Produkte wirklich inklusiver zu machen. Statt reiner Checklisten geht’s um echte Usability-Tests mit Accessibility-Fokus, bei denen Barrieren aus realer Nutzungsperspektive sichtbar werden.

Außerdem geht’s um Mentoring und Sensibilisierung für ganze Produktteams: von verständlicher Sprache über passende Ikonografie und Informationsarchitektur bis hin zu der Erkenntnis, dass Accessibility ein fortlaufendes Programm ist (kein einmaliges Projekt). Wir streifen dabei auch regulatorischen Druck (BFSG, European Accessibility Act) und die WebAIM-Million-Studie [https://webaim.org/projects/million/] als Reality-Check – und empfehlen ausdrücklich, sich die Demos/Webinare von Claudio Zeni [https://www.linkedin.com/in/claudio-zeni-a6a05a347/recent-activity/events/] anzuschauen, um ein besseres Gefühl für assistive Technologien in der Praxis zu bekommen.

Auf YouTube findest du das Video zu unserem Gespräch.

On Tour @ #t3con – Incluthon: Inklusion testen statt abhaken, mit Stefan Barac

So lang ist es her (5 Jahre), dass Anselm Hannemann [https://anselm-hannemann.de/] hier im Working Draft Teil des Podcast-Teams war. Jetzt habe ich (Hans) ihn mal gefragt, ob er mal wieder bei uns zu Gast sein möchte — und er hat ja gesagt.

Heute geht’s mal um Anselm, was ihn zu dem gemacht hat, der er heute ist, und was er in den letzten Jahren so getrieben hat.

Schaunotizen

[00:03:30] Zum Programmieren gekommen Wir sprechen darüber, wie wir uns kennengelernt haben. Da war der Weg nicht weit, um über Anselms Werdegang zu sprechen: Ausbildung, Studium und erste Projekte. Spannend auch, wie damals Print-Design ins Web gebracht wurde. [00:20:30] Engineering Management als Freelancer [00:31:00] Burn-out, Prävention und Gartenprojekt Ein tolles Projekt, das Anselm vor einigen Jahren ins Leben gerufen hat, ist eine eigene Gärtnerei. Nach Burn-out und Überlegungen, wie man im Software-Engineering eigentlich gesund bleibt, kam es zu dieser kostspieligen Idee. Unser Gespräch geht über die Finanzierung und Personal-Coaching, das aus dem Burn-out hilft. [00:53:22] Anselms aktuelles technisches Interesse Schnelle AI-Modelle, LLMs lokal laufen lassen, Accessibility AI und wann funktioniert AI für Coding.

Revision 696: Was macht eigentlich… Anselm Hannemann?

Dieses Interview ist Teil der Serie On Tour @ #t3con. T3CON [https://t3con.typo3.com/] ist die jährliche Konferenz, bei der es um alle Themen rund um TYPO3 geht. Wir waren am 25. November 2025 in Düsseldorf beim Community Day vor Ort und haben die Stimmung und einige Interviews mitgenommen.

Frontend State of TYPO3

Mit Thomas Maroschik [https://www.linkedin.com/in/thomas-maroschik-6aba0019b/] konnten wir ein TYPO3 Board Member für uns gewinnen. Er gibt uns Einblicke, wie Frontend Technologien in TYPO3 gerade ein neues Hoch erfahren, wie man TYPO3 als Headless CMS nutzen kann und wie KI TYPO3 beeinflusst.

Auf YouTube findest du das Video zu unserem Gespräch [https://www.youtube.com/watch?v=b5BcAAqpsY4].

On Tour @ #t3con – Frontend State of TYPO3 mit Thomas Maroschik

Zum Jahresende gibt’s noch ein kleines Extra für Euch: Unsere großartige Post-Producerin Sabine hat sich hingesetzt und aus dem Jahr wieder herrliche Outtakes zusammengeschnitten – Versprecher, Neustarts, Ratlosigkeit, Lachen und all die Momente, die es sonst nie in die Folge schaffen. Ein liebevoller Blick hinter die Kulissen von Working Draft und ein Geschenk, über das wir uns sehr gefreut haben. Viel Spaß beim Hören (und Mitlachen)!

Outtakes 2025

In dieser Revision schauen wir wieder gemeinsam auf frische Browser-Features aus Chrome, Firefox und den WebKit Nightlies. Wir sprechen über praktische Bugfixes, neue CSS-Möglichkeiten, bessere DOM-APIs und ein paar eher nischige, aber extrem mächtige JavaScript-Neuerungen.

Schaunotizen

[00:02:10] Overscroll-Behavior für Container ohne Scroll-Layer (Chrome) [https://www.bram.us/2025/11/25/use-overscroll-behavior-contain-to-prevent-a-page-from-scrolling-while-a-dialog-is-open/] Chrome respektiert overscroll-behavior jetzt auch dann, wenn ein Element faktisch keinen eigenen Scroll-Container hat. Das behebt einen langjährigen Pain Point bei Dialogen, Overlays und Off-Canvas-Navigationen, bei denen sonst plötzlich der Seitenhintergrund scrollt.

Wir erklären, warum das bisher ein Spec-Problem war, wieso Chrome hier nachgezogen hat und warum man sich damit endlich fiese Workarounds sparen kann. Als anschauliches Beispiel schauen wir uns eine Scroll-Situation auf code.movie [https://code.movie/play.html] an.

[00:11:50] WeakMap & WeakSet mit nicht-registrierten Symbols (Firefox) [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/146#javascript] Firefox erlaubt nun auch nicht-registrierte Symbols als Keys in WeakMap und WeakSet. Damit sind Weak-Collections endlich vollständig konsistent mit der Garbage-Collection-Semantik von Symbols.

Wir sprechen ausführlich darüber, warum das relevant ist, wann man Symbols überhaupt sinnvoll einsetzt und wie Peter sie unter anderem in seinem Web-Component-Framework Ornament [https://github.com/SirPepe/ornament] nutzt – inklusive Exkurs zu registrierten Symbols, Symbol.for() und instanceof-Fallstricken bei gebundelten Libraries.

[00:30:23] CSS stretch-Keyword für width/height [https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/width#stretch] Mit dem neuen Keyword stretch lassen sich Elemente sauber über die Content-Box ihres Elternteils aufspannen – ohne calc(), ohne absolute Positionierung und ohne Wissen über Padding.

Wir ordnen ein, warum das funktional dem alten -webkit-fill-available [https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Webkit_extensions#-webkit-fill-available] entspricht, wie die Browser-Unterstützung aussieht (Can I Use [https://caniuse.com/mdn-css_properties_width_stretch]) und warum das Feature trotz breiter Nutzbarkeit noch nicht als Baseline gilt.

[00:36:27] Atomics.waitAsync() [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics/waitAsync] Atomics.waitAsync() bringt endlich eine Promise-basierte Alternative zur blockierenden Atomics.wait()-API. Damit lassen sich Shared-Array-Buffer-Synchronisationen auch im Main-Thread sinnvoll nutzen.

Wir erklären, warum die alte API praktisch nur in Workern sinnvoll war, welche Workarounds man bisher brauchte und warum sich das Feature zwar nach Hardcore-Low-Level anhört, in der Praxis aber trotzdem nur selten lohnt.

[00:43:02] @scope [https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@scope] @scope ist jetzt Baseline und ermöglicht echtes CSS-Scoping ohne Namenskonventionen, Build-Tools oder CSS-Modules. Styles lassen sich direkt an Komponenten koppeln – inklusive Donut-Scoping für Slots und Durchreiche-Bereiche.

Wir diskutieren, warum das besonders für serverseitige Templates (PHP, Twig & Co.) hilfreich ist, wie man damit Toolchains drastisch vereinfachen kann und warum @scope ein echter Gamechanger für „CSS für Arme“ ist – im besten Sinne

[01:07:15]

Revision 695: Browser-News-Roundup

In dieser Revision drehen wir nochmal das Glücksrad – allerdings zum Themenbereich TypeScript und React. Gemeinsam mit unserem Gast Kiki (Hans-Christian Otto) [https://hans-christian-otto.de/], seines Zeichens Paramount Leader von Suora [https://www.suora.com/], picken wir zufällige React- und TypeScript-Themen und arbeiten uns von dort aus tief in Parallelwelten, Typsysteme, Debugging-Philosophie und die Grenzen statischer Analyse vor. Es geht um React DevTools, Web Components, any vs. unknown, TypeScript-Overloads, Decorators und die Frage, warum HTML kaputt sein darf – und vermutlich immer bleiben wird.

[00:03:37] React useDebugValue [https://react.dev/reference/react/useDebugValue] useDebugValue ist ein React-Hook, mit dem sich Zusatzinformationen in den React DevTools anzeigen lassen. Im Kern eine Art strukturierter Debug-Output, der besonders hilft, wenn dieselbe Komponente mehrfach im Tree auftaucht. [00:27:28] Debugging in React & DevTools [https://react.dev/learn/debugging-react] Wir vergleichen klassisches Browser-Debugging mit React-Debugging und diskutieren, warum React eigene DevTools braucht: synthetische Events, virtueller DOM und eine parallele Realität zur Web-Plattform. [00:39:00] Web Components & Custom Elements [https://developer.mozilla.org/en-US/docs/Web/API/Web_components] Exkurs in die Welt der Web Components: Warum Debugging dort oft einfacher ist, weil es keine virtuelle Abstraktion gibt – und was passiert, wenn ein Custom Element nie registriert wird. Spoiler: Der Browser bleibt erstaunlich gelassen. [00:00:00] Kaputtes HTML & Browser-Parsing [https://html.spec.whatwg.org/] Wir diskutieren, warum Browser kaputtes HTML akzeptieren müssen, weshalb XHTML sich nie durchgesetzt hat und warum ein strikt validierender Browser automatisch ein schlechter Browser wäre. [00:00:00] React isValidElement() [https://react.dev/reference/react/isValidElement] Ein eher unbekanntes React-API zur Laufzeitprüfung von React-Elementen. Wir schauen unter die Haube, stolpern über interne Marker wie $$typeof und landen bei Cross-Realm-Problemen. [00:46:26] TypeScript any vs. unknown [https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-unknown-type] Ein zentrales Thema der Folge: any als kompletter Opt-out aus dem Typsystem versus unknown als sichere Grenze. Wir erklären Typ-Hierarchien und warum unknown fast immer die bessere Wahl ist. [00:00:00] TypeScript: unknown als Sicherheitsgrenze [https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html#unknown-on-catch-variables] Wir sprechen über reale Einsatzszenarien, etwa bei fetch(), und warum ein sauberer Typ-Reset oft sinnvoller ist als das blinde Akzeptieren von any. [00:48:56] TS-Reset & Fetch-Typen [https://github.com/total-typescript/ts-reset] Ein Community-Projekt, das TypeScript-Defaults bewusst verschärft. Wir diskutieren Chancen, Risiken und warum solche Tools sowohl helfen als auch schaden können. [00:00:00] TypeScript Function Overloads [https://www.typescriptlang.org/docs/handbook/2/functions.html#function-overloads] Ein Pattern für robuste APIs: nach außen präzise Typen für gute Autocompletion, nach innen unknown für saubere Validierung. Besonders relevant für Library-Autor:innen. [01:23:42] TypeScript Decorators [https://www.typescriptlang.org/docs/handbook/decorators.html] Wir sprechen über Legacy-Decorators, Standard-Decorators und warum "experimentalDecorators" oft mehr Probl

Revision 694: React- & TypeScript-Glücksrad, mit Hans-Christian Otto

Wir drehen wieder am „Glücksrad [https://workingdraft.de/gluecksrad/]“ – diesmal strikt mit HTML-Vokabular. Schepp hat sich Jens Oliver Meiert [https://meiert.com/] eingeladen (Frontend Dogma [https://frontenddogma.com/], Web Glossary [https://webglossary.info/], Revision 687 [https://workingdraft.de/687/]). MDN-Daten liefern die Zufalls-Themen; wir sezieren Einsatzfälle, Historie, Stolpersteine und moderne Patterns – von id über contenteditable bis hin zu <option>, <datalist> und dem noch jungen Global-Attribut writingsuggestions. Außerdem streifen wir HTML-Geschichte (HTML 2, XHTML 2), IE-Altlasten (designMode, Drag and Drop), XSLT-Rückbau, AJAX-Begriffsgeschichte und aktuelle Bildformate.

Schaunotizen

[00:03:27] id (MDN) [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/id] & Spec: The id attribute [https://html.spec.whatwg.org/multipage/dom.html#the-id-attribute] Historischer Abriss von name-Sprungmarken zu id; warum id als CSS-Selektor teils verpönt wurde (Spezifität), und wann er weiterhin sinnvoll ist (einzigartige Ziele, Relation über for/aria-*). Praktische Kniffe: Attribute-Selektoren, Spezifitäts-Dämpfung via :where(); bei Komponenten Duplikate durch generierte Suffixe/UUIDs vermeiden. [00:15:39] contenteditable [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/contenteditable], designMode & Rich-Text Use-Cases von Inline-Eingaben bis Comboboxen. Placeholder-Pattern: [contenteditable]:empty::before für Pseudo-Placeholder. contenteditable="plaintext-only" verhindert Stil-Paste. Historische Wurzeln: IE-designMode, vieles später standardisiert. Schepps Blog-Nugget zur IE-Ära: Today the Trident Era ends [https://schepp.dev/posts/today-the-trident-era-ends/]. Und die Liste an historischen CSS Fehler [https://wiki.csswg.org/ideas/mistakes]n. [00:24:36] <b> [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/b] und <i> [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/i] (sowie <strong>/<em>) Warum <b> (Aufmerksamkeitsmarkierung) und <i> (idiomatische/andere Stimme) legitime Semantik haben und nicht bloß „Präsentation“ sind. Wir sprechen über historischen Kontext aus frühen HTML-Spezifikationen; Blick in die alten Spec-Dokumente: W3C HTML Spec (Archiv) [https://www.w3.org/MarkUp/html-spec/html-spec_toc.html]. [00:35:53] <option> [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/option], <optgroup> & <datalist> [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/datalist] Arbeitspferd im Formular: Gruppenbildung via <optgroup>, deaktivierbare Optionen, label-Attribut (ersetzt sichtbaren Inhalt). <datalist> als unterschätztes Type-Ahead für viele <input>-Typen (Range, Date etc.) – aber Achtung bei tausenden Einträgen (Performance, Match-Heuristiken variieren je nach Browser). Inspiration: „Retropolis“ bei unseren Freunden von Wo wir sind ist vorne [https://wowirsindistvorne.show/retropolis/]. [00:43:40] writingsuggestions [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/writingsuggestions] Noch jung und teils experimentell: steuert Sc

Revision 693: HTML Glücksrad, mit Jens Oliver Meiert

In dieser Revision sprechen wir mit unserem Gast Manuel Matuzović [https://www.matuzo.at/] über moderne HTML-Praktiken, alte Muster, die sich hartnäckig halten, und darüber, warum manche Links eigentlich Buttons sein sollten. Dabei tauchen wir tief in Semantik, Barrierefreiheit und die Frage ein, warum bestimmte Patterns – trotz aller Probleme – immer wieder im Web auftauchen.

Schaunotizen

[00:01:45] javascript:void(0) Aufhänger dieser Revision ist ein Muster, das uns seit Jahren immer wieder begegnet: Die verbreitete Nutzung von href="javascript:void(0)" und verwandten Dingen in Links. Wir beklagen, dass dieses Pattern nicht nur technisch fragwürdig ist, sondern auch aus Sicht von Barrierefreiheit, Nutzererwartungen und allgemeiner HTML-Semantik massive Probleme nach sich zieht.

Dafür arbeiten wir uns zunächst Schritt für Schritt daran entlang, was einen echten, barrierefreien Link überhaupt ausmacht. Dazu gehören ein <a>-Element, ein gültiges href-Attribut und ein klarer Accessible Name [https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/]. Erst dadurch entstehen Fokussierbarkeit, Tastaturaktivierung, sinnvolle Screenreader-Ausgaben, das korrekte Verhalten in Linklisten, die bekannten Linkzustände und das erwartete Interaktionsmodell. Alles, was davon abweicht, bricht die Erwartungen der Nutzenden – besonders sichtbar wird das bei Links, die eigentlich Buttons darstellen sollen.

javascript:void(0) sehen wir zudem als ein typisches Beispiel für Cargo-Kult: Ein historisches Muster, das weiterlebt, obwohl kaum jemand noch weiß, wozu es ursprünglich gedacht war. Technisch betrachtet evaluiert eine solche URL einfach JavaScript – im Fall von void wird allerdings bewusst undefined zurückgegeben, also „nichts“.

Wir benennen die vielen praktischen Probleme, die solcher Code hervorruft: Kontextmenüs bieten unsinnige Optionen an, Mittelklicks öffnen leere Tabs, Screenreader kündigen Elemente als Links an, die sich gar nicht wie Links verhalten, Tastaturnutzende stoßen auf widersprüchliche Aktivierungsmuster und in Listen assistiver Technologien erscheint „Navigierbares“, das kein Ziel hat. Wir diskutieren, wie solche Muster häufig entstehen – sei es aus historisch schwer zu stylenden Buttons, aus Einschränkungen in Component-Libraries, aus unglücklichen Framework-Abstraktionen oder schlicht aus fehlendem Basiswissen über HTML.

Aus dieser Perspektive wird klar: In den allermeisten Fällen wäre ein echtes <button>-Element die richtige Wahl. Moderne Browser machen das Styling per all: unset; und wenigen Ergänzungen längst unkompliziert. Wir sprechen darüber, wie hybride Komponenten sinnvoll funktionieren können, warum überflüssige Rollen, Tabindex-Werte oder ARIA-Attribute eher schaden als helfen, und wie man mit einfachen Debug-Strategien – etwa Selektoren wie a[href^="javascript:"] oder Werkzeugen wie a11y.css [https://ffoodd.github.io/a11y.css/] – problematische Stellen sichtbar machen kann.

Im weiteren Verlauf streifen wir verwandte Themen, etwa die alte Debatte um Cursor-Darstellungen bei Buttons, Überlegungen rund um target="_blank" und seine UX-Probleme (Warum target=“_blank“ nervt [https://www.peterkroener.de/warum-target_blank-nervt-und-verboten-gehoert/]), sowie die Frage, welche Rollen historische Mechanismen wie <area>-Elemente heute noch spielen können (MDN [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/area]). Wir stellen fest, dass viele Entwickler*innen HTML fast nur noch durch die Framework-Brille wahrnehmen– und dass genau diese Abstraktionsschichten es erschweren, zu verstehen, was die Basiselemente der Plattform eigentlich können.

Eine zentrale Erkenntnis des Gesprächs lautet: Gu

Revision 692: javascript:void(0), mit Manuel Matuzović

In dieser Revision sprechen wir mit Dr. Torsten Beyer [https://dr-beyer.de/], Chemiker und Experte für digitale Nachhaltigkeit, über seinen Weg vom Labor zum grünen Web, die oft übersehenen Umweltkosten des Internets und darüber, wie wir als Webentwickler:innen konkret zur CO₂-Reduktion beitragen können.

Wen das Thema weiter interessiert, sollte sich auch die Revision 675: Green Web [https://workingdraft.de/675/] geben.

Ein riesen Dank geht raus an Andreas Sander [https://andi1984.de/] für das Lied über den Working Draft. Könnt ihr am Ende der Sendung hören :)


Unser Sponsor



Maximale Performance für all deine Projekte? Bei mittwald brauchst du dir nie wieder Sorgen um Performance-Einbrüche machen. Der Traffic kann ruhig durch die Decke gehen, deine Seite bleibt immer rasend schnell.

mittwald hat Hosting neu gedacht und alles auf die besonderen Anforderungen und Workloads von Agenturen und Freelancern optimiert – inklusive Infrastruktur, benutzerfreundlicher Oberfläche und flexiblen Tarifen. Egal, ob du deinen Server selbst konfigurieren möchtest oder das mittwald-Team sich um die optimalen Specs kümmern soll. Der persönliche Kundenservice unterstützt dich 24/7 bei allen Fragen rundum WordPress, TYPO3, Shopware oder was auch immer dich gerade beschäftigt. Im firmeneigenen und TÜV-zertifizierten Rechenzentrum sind deine Daten in sicheren Händen. Und das Beste? Wer seine Projekte bei mittwald hostet bekommt nicht nur die besten Server, sondern ein Hosting mit Strom aus 100 % erneuerbaren Energien. Also, worauf wartest du?
Geh jetzt auf mittwald.de/workingdraft [https://mittwald.de/workingdraft?ref=workingdraft.de] und buch dein erstes Projekt!

Schaunotizen

[00:01:11] Vom Chemiker zum Experten für digitale Nachhaltigkeit Torsten kam als Chemiker zur digitalen Nachhaltigkeit. Geboren 1968 bei 363 ppm CO₂ [https://www.statista.com/statistics/1091926/atmospheric-concentration-of-co2-historic/] – circa als das Internet beim Militär erfunden wurde – beobachtet er seitdem beide Kurven steigen.

Wir sprechen darüber, wie Flatrates und „unbegrenzter“ Traffic seit 1969 ein falsches Bewusstsein für Daten schufen. Dazu das Jevons-Paradoxon [https://de.wikipedia.org/wiki/Jevons-Paradoxon]: Speicher wurde drastisch günstiger (vom Commodore 64 zur Mini-SD), aber statt zu sparen, führt das zu Mehrnutzung, die die Einsparungen auffrisst.

[00:42:18] Bewusstsein schaffen durch Analyse Torsten gibt einen Überblick über Methoden zur Analyse des CO₂ Fußabdrucks von Websites:
 * The Green Web Foundation [https://www.thegreenwebfoundation.org/] – Verzeichnis grüner Hoster, freiwillig. Wenn kein Eintrag: Hoster kontaktieren!
 * Website Carbon [https://www.websitecarbon.com/] – nicht empfehlenswert, fragwürdige Methodik.
 * Digital Beacon [https://digitalbeacon.co/] – besser, aber Tests nur bis Cookie-Banner. Guter Einstieg.
 * Log-Analyse – beste Methode für echten Traffic-Impact.

Unterschätzt: Laut Imperva Bot Report [https://www.imperva.com/blog/2025-imperva-bad-bot-report-how-ai-is-supercharging-the-bot-threat/] sind 51% des Traffics Bots – steigend durch KI. SEO Soon [https://seosoon.de/ki-bot-check/] zeigt, ob KI-Bots gesperrt si

Revision 691: Digitale Nachhaltigkeit – Warum das Web grüner werden muss, mit
Dr. Torsten Beyer

Der wöchentliche Podcast für Webdesigner:innen und -entwickler:innen. Supported
uns bei Patreon: https://patreon.com/workingdraft

Host

Shows