Eine kleine Website ist kein kleines Projekt: Performance, Barrierefreiheit, Datenschutz und Security in der Praxis
Der Umfang einer Website sagt wenig darüber aus, wie anspruchsvoll ihre technische Umsetzung sein sollte. Gerade kompakte Informationsseiten profitieren davon, Performance, Zugänglichkeit, Datenschutz, Sicherheit und Suchmaschinenfreundlichkeit nicht nachträglich zu ergänzen, sondern bereits bei Architektur und Frontend mitzudenken.
In einem aktuellen, bewusst anonymisierten Projekt haben wir genau diesen Ansatz umgesetzt: eine schlanke öffentliche Informationswebsite, ohne unnötige technische Abhängigkeiten, mit lokaler Ressourcenbereitstellung, zugänglicher Bedienung, restriktiven Security-Headern und einem konsequenten Blick auf die Details bis zum HTTP-Statuscode. ( Weiterlesen: Warum eine kleine Website technisch trotzdem ein vollständiges Qualitätskonzept braucht )
➨ Unsere Einordnung: Qualität entsteht nicht durch die Größe einer Website
Eine Website mit wenigen Seiten kann technisch anspruchsvoller sein als ein deutlich umfangreicherer Auftritt. Entscheidend ist nicht die Zahl der Menüpunkte, sondern welche Anforderungen gleichzeitig erfüllt werden sollen.
Soll eine Website schnell laden, auf Smartphones zuverlässig funktionieren, mit Tastatur bedienbar sein, möglichst wenige Daten an Dritte übertragen, technisch gehärtet und sauber für Suchmaschinen aufbereitet sein, greifen viele Disziplinen ineinander.
Genau deshalb betrachten wir Webdesign und UX nicht isoliert von Entwicklung, Performance, Barrierefreiheit, Datenschutz oder dem späteren Betrieb.
Eine kleine Website braucht nicht weniger Qualität. Sie bietet lediglich weniger Raum, technische Schwächen hinter Komplexität zu verstecken.
Warum wir bewusst kein CMS eingesetzt haben
Ein Content-Management-System ist für viele Projekte die richtige technische Grundlage. Es ist aber kein Selbstzweck.
In diesem Projekt bestand die Aufgabe im Wesentlichen aus strukturierten Informationsinhalten, mehreren Dokumenten, wenigen interaktiven Komponenten und einer klar begrenzten redaktionellen Laufzeit. Eine umfangreiche CMS-Installation hätte dafür zusätzliche Komplexität geschaffen, ohne einen entsprechenden funktionalen Mehrwert zu liefern.
Die technische Basis blieb deshalb bewusst schlank:
➨ Semantisches HTML5 und PHP
PHP übernimmt nur dort serverseitige Aufgaben, wo sie tatsächlich benötigt werden. Die Inhaltsstruktur bleibt unmittelbar nachvollziehbar.
➨ Bootstrap als technische Basis
Das Framework liefert Grid, responsive Breakpoints und etablierte Interaktionskomponenten, ohne die visuelle Gestaltung vorzugeben.
➨ Eigenes CSS
Typografie, Farben, Abstände, Komponenten und responsive Details wurden projektspezifisch aufgebaut.
➨ Minimales JavaScript
JavaScript wird nur für konkrete Interaktionen benötigt. Es gibt keinen schwergewichtigen Frontend-Layer, der für statische Inhalte erst eine Anwendung starten muss.
➨ Lokale Assets
Fonts, Stylesheets, JavaScript und wesentliche grafische Ressourcen werden kontrolliert aus der eigenen Umgebung ausgeliefert.
Genau diesen CMS-unabhängigen Ansatz verfolgen wir auch im Bereich Webdesign & UX: Das System wird nach dem Projekt ausgewählt – nicht das Projekt nach dem bevorzugten System.
Accessibility by Design statt nachträglicher Reparatur
Barrierefreiheit wird teuer, wenn sie erst kurz vor dem Go-live als zusätzlicher Prüfschritt verstanden wird.
Viele wesentliche Anforderungen lassen sich dagegen mit sehr geringem Zusatzaufwand berücksichtigen, wenn sie bereits beim Aufbau von HTML, Navigation und Komponenten einfließen.
Deshalb wurde die Zugänglichkeit bei diesem Projekt von Beginn an als Teil der technischen Architektur behandelt.
➨ Semantische Dokumentstruktur
Hauptinhalt, Navigation, Abschnitte, Überschriften und ergänzende Informationen werden über passende HTML-Elemente strukturiert.
➨ Skip-Link
Tastaturnutzer können die wiederkehrende Navigation überspringen und direkt zum Hauptinhalt wechseln. Der Link wird sichtbar, sobald er den Tastaturfokus erhält.
➨ Sichtbare Fokusführung
Links, Schaltflächen und interaktive Elemente besitzen einen klar erkennbaren Fokuszustand.
➨ Native Bedienelemente
Wo eine Schaltfläche gemeint ist,
wird auch ein echtes
<button>
verwendet.
Dadurch funktionieren Tastaturbedienung
und grundlegende Accessibility-Eigenschaften
bereits auf Basis des Browsers.
➨ Reduzierte Bewegung
Die Gestaltung berücksichtigt
prefers-reduced-motion,
sodass Nutzer mit entsprechender Systemeinstellung
nicht zu unnötigen Animationen gezwungen werden.
➨ Responsive Typografie und Bedienung
Inhalte, Navigation und Interaktion wurden nicht nur für unterschiedliche Bildschirmbreiten, sondern auch für Zoom, Lesbarkeit und Touch-Bedienung betrachtet.
Mehr zu unserem Vorgehen bei zugänglichen Webangeboten finden Sie unter Barrierefreiheit & Compliance.
Lokale Ressourcen: Performance und Datenschutz gemeinsam denken
Performance, Datenschutz und technische Kontrolle werden häufig als getrennte Themen betrachtet. In der Webentwicklung beeinflussen sie sich jedoch unmittelbar.
Jede externe Ressource kann zusätzliche DNS-Auflösung, Netzwerkverbindungen, Abhängigkeiten und gegebenenfalls datenschutzrechtlich relevante Datenübertragungen verursachen.
Deshalb wurden wesentliche Ressourcen lokal bereitgestellt:
➨ Webfonts
Die eingesetzten Schriftarten werden vom eigenen Server ausgeliefert. Ein externer Font-Dienst ist nicht erforderlich.
➨ CSS und Bootstrap
Auch das CSS-Framework wird lokal betrieben. Das Frontend ist damit nicht von einem externen CDN abhängig.
➨ JavaScript
Benötigte Skripte liegen ebenfalls lokal und wurden auf den tatsächlichen Funktionsumfang begrenzt.
➨ Optimierte Bilder
Geeignete Bildformate, definierte Abmessungen und Lazy Loading reduzieren übertragene Daten und vermeiden unnötige Layoutverschiebungen.
Weniger externe Abhängigkeiten können gleichzeitig Ladezeit, Datenschutz, Ausfallsicherheit und technische Nachvollziehbarkeit verbessern.
Wie PageSpeed 100 technisch erreichbar wurde
Während der technischen Abnahme erreichte die Website in Google PageSpeed Insights in der geprüften Konfiguration 100 Punkte in allen vier ausgewiesenen Kategorien: Performance, Barrierefreiheit, Best Practices und SEO.
Ein solcher Messwert ist kein Selbstzweck und keine Garantie dafür, dass jeder spätere Test unter allen Bedingungen exakt dasselbe Ergebnis liefert. Messumgebung, Serverantwortzeiten, Netzbedingungen und spätere Änderungen können Ergebnisse beeinflussen.
Interessant ist deshalb weniger die Zahl selbst als die technische Grundlage, die sie ermöglicht hat.
➨ Schlanke Dokumentstruktur
Keine unnötig verschachtelte Komponentenarchitektur und kein überdimensionierter DOM-Baum.
➨ Wenig JavaScript
Der Browser muss keine umfangreiche Anwendung ausführen, bevor der eigentliche Inhalt nutzbar wird.
➨ Keine unnötigen Drittanbieter
Zusätzliche Skripte, Tracker oder externe UI-Abhängigkeiten wurden vermieden.
➨ Definierte Bildabmessungen
Breite und Höhe wichtiger Bilder sind bekannt, sodass der Browser Platz reservieren und Layoutverschiebungen reduzieren kann.
➨ Responsive Assets
Bilder, Fonts und Layout werden so eingesetzt, dass mobile Geräte nicht unnötig dieselbe Last wie große Desktopdarstellungen tragen müssen.
Vertiefend dazu: Core Web Vitals & PageSpeed – Website-Performance verbessern .
Security-Header und Content Security Policy
Eine öffentlich erreichbare Website sollte nicht erst dann über technische Sicherheitsmaßnahmen verfügen, wenn Formulare, Benutzerkonten oder komplexe Anwendungen hinzukommen.
Auch eine kompakte Informationsseite profitiert von einer klar definierten Browser-Sicherheitsrichtlinie.
Im Projekt wurden unter anderem folgende HTTP-Header eingesetzt:
➨ Content-Security-Policy
Die CSP legt fest, aus welchen Quellen Skripte, Stylesheets, Fonts, Bilder und andere Ressourcen geladen werden dürfen. Da die Website fast ausschließlich mit eigenen Ressourcen arbeitet, konnte die Policy entsprechend restriktiv aufgebaut werden.
➨ Strict-Transport-Security
HSTS unterstützt dabei, nach einem erfolgreichen HTTPS-Aufruf weitere Verbindungen ausschließlich verschlüsselt aufzubauen.
➨ X-Content-Type-Options
Der Browser wird angewiesen, deklarierte MIME-Typen nicht eigenständig umzudeuten.
➨ Referrer-Policy
Sie begrenzt, welche Referrer-Informationen bei Navigationen an andere Ziele übertragen werden.
➨ Permissions-Policy
Nicht benötigte Browser-Funktionen wie Kamera, Mikrofon, Geolocation oder Payment können für die Website ausdrücklich deaktiviert werden.
➨ Schutz gegen fremde Frames
Die Website darf nicht beliebig in fremde Seiten eingebettet werden. Das reduziert unter anderem Angriffsflächen für Clickjacking.
Besonders wichtig war uns dabei,
die Content Security Policy
nicht unmittelbar scharfzuschalten.
Zunächst wurde sie im
Report-Only-Modus getestet.
Navigation, mobile Menüführung, interaktive Komponenten, Fonts, Bilder und weitere Ressourcen konnten dadurch unter realen Bedingungen geprüft werden, bevor die Policy tatsächlich erzwungen wurde.
Technische Sicherheit endet für uns nicht beim Frontend. Im Bereich Betrieb, Wartung & Support gehören Security, Monitoring, Updates und Recovery zum laufenden Lebenszyklus einer Website.
Datenschutz nach Verarbeitungsvorgängen trennen
Eine Datenschutzerklärung sollte nicht einfach eine möglichst lange Sammlung unterschiedlichster Standardtexte sein.
Entscheidend ist zunächst, welche personenbezogenen Daten bei welchem Vorgang tatsächlich verarbeitet werden.
Im anonymisierten Projekt gab es neben dem normalen Websitebetrieb einen davon fachlich getrennten Prozess, bei dem personenbezogene Daten außerhalb der eigentlichen Websitenutzung verarbeitet werden konnten.
Deshalb wurden auch die Informationen zu diesen Verarbeitungsvorgängen bewusst voneinander getrennt.
➨ Websitebetrieb
Welche technischen Daten entstehen beim Abruf der Website? Welche Server- und Protokolldaten werden benötigt? Welche externen Dienste werden tatsächlich eingebunden?
➨ Separater fachlicher Verarbeitungsvorgang
Welche Daten werden für den jeweiligen Zweck benötigt? Wer ist verantwortlich? Wer erhält sie? Wie lange werden sie benötigt? Welche Rechte bestehen für die betroffenen Personen?
Datenschutz wird verständlicher, wenn nicht alles in einen Text gepackt wird, sondern Verarbeitungsvorgänge aus Sicht der betroffenen Person nachvollziehbar beschrieben werden.
Mehr dazu: Datenschutz & Compliance .
JSON-LD, robots.txt, Sitemap und llms.txt: unterschiedliche Aufgaben
Rund um Suchmaschinen und KI-Systeme werden technische Dateien häufig miteinander vermischt. Tatsächlich erfüllen sie unterschiedliche Aufgaben.
➨ JSON-LD mit Schema.org
Strukturierte Daten beschreiben nicht nur, wie eine Seite aussieht, sondern welche Bedeutung ihre Inhalte besitzen. Über JSON-LD können beispielsweise Website, einzelne Webseiten, Artikel, Autoren oder Organisationen maschinenlesbar miteinander verknüpft werden.
Dabei geht es nicht darum, zusätzliche Keywords für Suchmaschinen zu verstecken. Die strukturierten Daten sollen vielmehr die tatsächlich sichtbaren Inhalte in einer standardisierten Form beschreiben.
➨ robots.txt
Sie gibt Crawlern technische Hinweise, welche Bereiche einer Website gecrawlt werden dürfen oder nicht. Sie ist keine Inhaltsübersicht und kein Ersatz für eine Sitemap.
➨ sitemap.xml
Die XML-Sitemap stellt relevante URLs in einem maschinenlesbaren Format bereit und unterstützt Suchmaschinen dabei, Inhalte strukturiert zu entdecken.
➨ llms.txt
Eine llms.txt
kann ergänzend als kompakter,
menschenlesbarer und maschinenlesbarer Wegweiser
für ausgewählte Inhalte angeboten werden.
Sie ersetzt weder robots.txt
noch Sitemap
noch eine saubere Informationsarchitektur.
Wichtig ist dabei eine nüchterne Einordnung: Neue Formate werden von uns dort berücksichtigt, wo sie technisch sinnvoll und mit überschaubarem Aufwand umsetzbar sind. Daraus leiten wir jedoch keine unbelegten Rankingversprechen ab.
Maschinenlesbarkeit beginnt mit sauberem HTML und einer nachvollziehbaren Informationsstruktur. JSON-LD kann diese Bedeutung explizit beschreiben; Sitemap, robots.txt und optionale Formate wie llms.txt erfüllen ergänzende, jeweils unterschiedliche Aufgaben.
Für technische Suchmaschinenoptimierung, Indexierung und Performance betrachten wir diese Signale deshalb immer im Zusammenhang. Mehr dazu unter SEO & Performance .
security.txt und echte 404-Seiten: kleine Details mit großer Wirkung
Manche Qualitätsmerkmale sieht ein normaler Besucher kaum. Trotzdem sagen sie viel darüber aus, wie konsequent eine Website technisch umgesetzt wurde.
➨ /.well-known/security.txt
Für Sicherheitsmeldungen wurde eine standardisierte
security.txt
bereitgestellt.
Sie nennt einen definierten Kontaktweg,
eine Gültigkeitsdauer
und die kanonische Adresse der Datei.
➨ Eigene 404-Seite
Nicht vorhandene Inhalte führen auf eine zum Design passende Fehlerseite, die einen verständlichen Rückweg zur Website anbietet.
➨ Tatsächlicher HTTP-Status 404
Die Fehlerseite sieht nicht nur wie eine 404-Seite aus.
Der Webserver liefert auch tatsächlich
404 Not Found.
Was wir vor dem Livegang systematisch geprüft haben
Der Go-live ist für uns nicht der Moment, in dem Dateien auf einen Server kopiert werden. Er ist der Abschluss einer Reihe technischer Prüfungen.
Für dieses Projekt gehörten dazu unter anderem:
➨ Responsive Darstellung
Navigation, Typografie, Bilder und Inhaltsbereiche wurden auf unterschiedlichen Viewport-Größen geprüft.
➨ Tastaturbedienung
Navigation, Skip-Link, Schaltflächen und interaktive Elemente wurden ohne Maus durchlaufen.
➨ Fokus und Zoom
Fokuszustände, Vergrößerung und Umbruchverhalten wurden als eigenständige Prüfpunkte behandelt.
➨ Interaktive Funktionen
Mobile Navigation, Umschalter und aufklappbare Inhalte wurden nach Änderungen erneut getestet.
➨ Browser-Konsole und CSP
Sicherheitsregeln wurden kontrolliert eingeführt und auf blockierte Ressourcen oder unerwartete Fehler geprüft.
➨ HTTP-Statuscodes
Normale Seiten, Weiterleitungen und Fehlerseiten müssen nicht nur optisch, sondern auch auf Protokollebene korrekt reagieren.
➨ Indexierbarkeit
Entwicklungsbedingte Zugriffsbeschränkungen und Noindex-Anweisungen müssen vor der Veröffentlichung bewusst entfernt werden.
➨ robots.txt und Sitemap
Die für Suchmaschinen vorgesehenen Dateien wurden auf Erreichbarkeit und korrekte URLs geprüft.
➨ Social-Media-Vorschau
Metadaten und Vorschaubild wurden als eigener Veröffentlichungskanal behandelt.
➨ Performance-Messung
PageSpeed Insights und die technischen Kennzahlen dienten als abschließender Kontrollpunkt, nicht als Ersatz für funktionale Tests.
Auch nach der Veröffentlichung endet die technische Verantwortung nicht. Genau deshalb gehören Betrieb, Wartung und Support für uns zum Lebenszyklus einer professionellen Website.
Fazit: Kleine Website, vollständiger Qualitätsanspruch
Die vielleicht wichtigste Erkenntnis aus diesem Projekt lautet: Technische Qualität lässt sich nicht an der Zahl der Unterseiten messen.
Auch eine kompakte Informationswebsite braucht eine bewusste Systemwahl, verständliche Informationsarchitektur, sauberes HTML, mobile Nutzerführung, Accessibility, Datenschutz, Performance und eine angemessene Sicherheitskonfiguration.
Werden diese Anforderungen von Beginn an gemeinsam betrachtet, entstehen nicht nur bessere Messwerte. Die Website wird einfacher, nachvollziehbarer, robuster und langfristig leichter zu betreiben.
Genau darin liegt für uns der Unterschied zwischen einer Website, die lediglich veröffentlicht wurde, und einer Website, die technisch bewusst entwickelt wurde.
Weiterführende Leistungen & Praxiswissen
Internetagentur Scherer: Webdesign & UX – Websites strukturiert und technisch sauber entwickeln
Internetagentur Scherer: Core Web Vitals & PageSpeed – Website-Performance verbessern
Internetagentur Scherer: Barrierefreiheit & Compliance für Websites
Internetagentur Scherer: Datenschutz & Compliance
Internetagentur Scherer: Betrieb, Wartung & Support für Websites
Hinweis: Dieser Beitrag basiert auf einem real umgesetzten, aus Gründen der Vertraulichkeit vollständig anonymisierten Webprojekt. Auftraggeber, Projektgegenstand, Inhalte, Standort und weitere identifizierende Merkmale werden bewusst nicht genannt. Die beschriebenen technischen Maßnahmen und Prüfschritte entsprechen der im Projekt eingesetzten Vorgehensweise. Messwerte wie PageSpeed-Ergebnisse stellen eine Momentaufnahme der jeweiligen Testkonfiguration dar und können sich durch technische oder externe Veränderungen unterscheiden.
FAQ: Performance, Barrierefreiheit und Security bei Websites
Braucht eine kleine Website ein CMS wie WordPress oder Joomla?
Nicht zwingend. Ein CMS ist sinnvoll, wenn Inhalte regelmäßig gepflegt werden, mehrere Redakteure arbeiten oder umfangreiche Funktionen benötigt werden. Bei einer klar begrenzten Informationswebsite kann eine schlanke individuelle Umsetzung weniger Komplexität, geringeren Wartungsaufwand und sehr gute Performance ermöglichen. Entscheidend ist der konkrete Anwendungsfall.
Was bedeutet Accessibility by Design?
Accessibility by Design bedeutet, Zugänglichkeit bereits bei Konzeption, HTML-Struktur, Navigation, Komponenten und Gestaltung zu berücksichtigen. Dazu gehören beispielsweise semantisches HTML, Tastaturbedienbarkeit, sichtbare Fokuszustände, verständliche Bedienelemente, responsive Typografie und geeignete Alternativtexte.
Wie erreicht eine Website PageSpeed 100?
Es gibt dafür keinen einzelnen Schalter. Sehr gute Werte entstehen meist aus einer Kombination aus schlanker Architektur, optimierten Bildern, wenig JavaScript, kontrollierten Webfonts, stabilen Layouts und möglichst wenigen externen Abhängigkeiten. Ein Wert von 100 ist zudem eine Momentaufnahme und sollte nicht wichtiger genommen werden als die tatsächliche Nutzererfahrung.
Verbessern lokal gehostete Webfonts den Datenschutz?
Lokale Webfonts vermeiden den notwendigen Abruf bei einem externen Font-Anbieter. Dadurch entfällt diese zusätzliche Drittverbindung. Gleichzeitig kann die Agentur Caching, Dateiformate und die tatsächlich benötigten Schriftschnitte selbst kontrollieren.
Was ist eine Content Security Policy?
Eine Content Security Policy, kurz CSP, ist eine vom Webserver übermittelte Sicherheitsrichtlinie. Sie kann festlegen, aus welchen Quellen eine Website beispielsweise Skripte, Stylesheets, Bilder oder Fonts laden darf. Damit lassen sich bestimmte Angriffsszenarien und unerwünschte Ressourceneinbindungen begrenzen.
Sollte eine Content Security Policy sofort aktiviert werden?
Bei bestehenden oder komplexeren Websites ist ein schrittweises Vorgehen sinnvoll. Eine CSP kann zunächst im Report-Only-Modus getestet werden. Dadurch werden Verstöße sichtbar, ohne benötigte Ressourcen sofort zu blockieren. Erst nach erfolgreicher Prüfung wird die Richtlinie tatsächlich erzwungen.
Welche Security-Header sind für eine Website sinnvoll?
Welche Header sinnvoll sind, hängt vom jeweiligen Projekt ab. Typische Bausteine sind Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy und Permissions-Policy. Wichtig ist nicht eine möglichst lange Header-Liste, sondern eine zur Anwendung passende, getestete Konfiguration.
Was ist eine security.txt?
Eine security.txt ist eine standardisierte Textdatei,
die üblicherweise unter
/.well-known/security.txt
bereitgestellt wird.
Sie kann Sicherheitsforschern
und anderen Hinweisgebern
einen definierten Kontaktweg
für Sicherheitsmeldungen nennen.
Was bringt JSON-LD einer Website?
JSON-LD ermöglicht es, Inhalte mit dem Schema.org-Vokabular strukturiert zu beschreiben. Suchmaschinen und andere maschinelle Systeme können dadurch beispielsweise erkennen, welche Seite zu einer Website gehört, wer einen Fachartikel verfasst hat oder welche Organisation ihn veröffentlicht. Die strukturierten Daten sollten dabei immer die tatsächlich sichtbaren Inhalte widerspiegeln.
Braucht jede Website robots.txt, Sitemap und llms.txt?
Diese Dateien erfüllen unterschiedliche Aufgaben. Eine robots.txt steuert Crawler-Hinweise, eine XML-Sitemap listet relevante URLs für Suchmaschinen strukturiert auf. Eine llms.txt ist dagegen ein optionales Format zur kompakten Beschreibung ausgewählter Inhalte für maschinelle Nutzung. Sie ersetzt weder robots.txt noch Sitemap noch saubere technische SEO.
Warum muss eine eigene 404-Seite wirklich HTTP 404 zurückgeben?
Eine Fehlerseite sollte nicht nur anzeigen, dass eine Ressource nicht gefunden wurde. Der Webserver muss diesen Zustand auch mit dem HTTP-Statuscode 404 melden. Wird stattdessen 200 OK ausgegeben, sehen Nutzer zwar eine Fehlerseite, Suchmaschinen und andere technische Systeme erhalten aber ein widersprüchliches Signal.
Social Sharing gehört zur User Experience
Eine Website wird nicht nur direkt über ihre URL aufgerufen. Gerade bei öffentlichen Informationsangeboten können Links über Messenger, soziale Netzwerke, E-Mail oder andere Plattformen weitergegeben werden.
Die dort erzeugte Linkvorschau ist deshalb Teil des ersten Eindrucks.
Entsprechend wurden Titel, Beschreibung, Canonical URL und ein eigenes Vorschaubild für externe Plattformen definiert.
➨ Open Graph
Titel, Beschreibung, URL und Bild werden explizit ausgezeichnet, damit Plattformen nicht selbst irgendeinen Seitenausschnitt auswählen müssen.
➨ Vorschaubild im Format 1200 × 630 Pixel
Ein bewusst gestaltetes Social-Media-Bild sorgt für eine kontrolliertere Darstellung beim Teilen des Links.
➨ Aussagekräftige Alternativbeschreibung
Auch das Social-Media-Bild erhält eine inhaltlich passende Beschreibung.
➨ Canonical URL
Die bevorzugte Adresse des Dokuments wird eindeutig angegeben.