Was handgeschriebener Code besser macht
Die Sicherheit
Die Architektur
Offene Türen, offene Fenster
Ein CMS ist wie ein Haus mit Fenstern und Türen, den Schnittstellen, über die das System aufgebaut und gesteuert wird. Um überhaupt etwas tun zu können, muss man in den Steuerbereich. Der Weg dorthin führt durch die Admin-Schnittstelle – die Haustür.
Weitere Schnittstellen bauen zusätzliche Fenster und Türen ein: Datenbanken, Designvorlagen, Programmvorgaben. Jede von ihnen bekommt Zugang zu deinem Haus. Und alle haben eigene Schlösser mit eigenen Schlüsseln. Als Hausherr kann man das nicht kontrollieren. So entstehen immer mehr Angriffsflächen.
Das ist bei Baukästen strukturell eingebaut. Denn ohne Schnittstellen kann es nicht funktionieren. Ein Dilemma, denn die vermeintliche Flexibilität der Systeme beruht auf ihnen: den Schnittstellen.
So ist die vorgebliche Stärke des CMS bei Licht betrachtet seine größte Schwäche – das Ökosystem erweiterbarer Schnittstellen. Ein einziges vernachlässigtes Plugin reicht aus, um das gesamte System zu kompromittieren. Qualität und Lebensdauer jedes installierten Plugins zu beurteilen ist praktisch unmöglich. Selbst beliebte Plugins mit Millionen Installationen können jederzeit übernommen oder vom Entwickler einfach aufgegeben werden.
Neue Schlösser, neue Schlüssel
Ständige Updates sind dringend geboten: Instandhaltung der Räume, aber auch das Aufrüsten der Schlösser oder Schlüssel. Wird das nicht gemacht, bleiben bekannte Sicherheitslücken weiter offen. Werden sie jedoch gemacht, kann es immer passieren, dass irgendein Plugin keinen passenden Schlüssel mehr hat. Es kommt nicht mehr rein und die Website funktioniert nicht mehr.
Das kann im Vorfeld nicht verhindert werden, da nicht bekannt ist, was welches Update wie bewirkt. Das erfährt man – wenn überhaupt – erst, wenn nichts mehr geht.
Öffentlicher Wegweiser zu deinem Hauseingang
Der genaue Zugang zum Admin Bereich beliebter CMS – die Adresse zur Haustür – ist öffentlich bekannt (Domainname gefolgt von /wp-admin, /administrator, /contao usw.). Das ist bei jedem System vorgegeben. Kennt der Angreifer das System, kennt er den Zugang. Der wird automatisiert von Botnets angegriffen, rund um die Uhr mit Passwortkombinationen.
Der Unterschied: Handgeschrieben
Ein CMS ist ein System, entwickelt für den täglichen Neubau von Räumen. Dafür ist es da, dafür ist es gut. Doch jede Tür bleibt immer auch ein potenzieller Einbruchspunkt. Jedes Fenster braucht ein eigenes Schloss, das regelmäßig gewartet werden muss.
Unsere handgeschriebenen Seiten sind anders: ein massiv gebautes Haus ohne unnötige Türen. Es gibt keine Admin-Oberfläche, die gehackt werden kann, keine unsicheren Plugins, keine angreifbare Datenbank. Ein solider Bau ohne großen Wartungsaufwand. Flexibel ist er trotzdem – nur ohne die Sicherheitsrisiken eines Baukastensystems.
Bei einem Baukasten werden Inhalte über eine Schnittstelle geändert, die selbst angreifbar ist. Bei unserem Ansatz werden Inhalte direkt im Code geändert – Schnittstellen, die angegriffen werden könnten, sind schlicht nicht vorhanden.
Datenschutz & DSGVO
Die Blackbox
Nicht nur Angreifer sind ein Risiko. Auch das, was unbemerkt hinausfließt, kann teuer werden.
Ein CMS bleibt eine Blackbox. Du kannst nie genau wissen, welche Daten es wohin weiter gibt. Viele Plugins, besonders "kostenlose", tauschen Daten mit externen Servern über alles Mögliche aus: Updates, Statistiken, Fonts, Maps, Bilderdienste.
Verarbeitet ein Plugin Daten über Server außerhalb der EU, hast du bereits gegen die DSGVO verstoßen. Auch wenn das ohne dein Wissen geschieht. Verantwortlich ist der Betreiber der Website. Der steht im Impressum.
Merke: Kostenlos heißt in Wahrheit oft: Kostet kein Geld, kostet Daten.
Die Cookie-Falle
CMS setzen standardmäßig Cookies – oft ohne dass du es merkst. Manche sind technisch notwendig, viele dienen nur der Analyse oder dem Tracking. In der Regel lassen sie sich gar nicht vollständig abschalten. Selbst wenn du versuchst, sie zu deaktivieren: das nächste Update oder Plugin setzt sie gerne einfach wieder.
Das Problem: Jedes Cookie, das ohne ausdrückliche Einwilligung gesetzt wird, ist ein DSGVO-Verstoß. Und du als Betreiber haftest dafür – nicht der Plugin-Entwickler.
Unsere handgeschriebenen Seiten arbeiten komplett ohne Cookies. Es gibt sie nicht. Es sind keine nervigen Cookie-Banner nötig, keine Einwilligungspflicht, kein Risiko.
Die Transparenz
Bei einer von uns geschriebenen, statischen Seite besteht der Code aus reinem HTML, CSS und – wenn nötig – eigenem JavaScript. Das ist alles.
Jede Zeile Code kannst du einsehen und verstehen. Keine versteckten Bibliotheken, keine fremden Skripte und keine serverseitigen Prozesse, die im Hintergrund Daten verarbeiten oder senden.
Im Gegensatz zu einem CMS, dessen Quelltext oft durch tausende Zeilen generierten Framework-Code und Plugin-Logik unlesbar wird, ist bei uns jedes Zeichen bewusst mit Sorgfalt gesetzt.
Bei einem CMS trägst du als Betreiber die Verantwortung, dass die gesamte Software – also das eigentliche CMS, mit jedem einzelnen genutzten Plugin, jedem integrierten Theme – DSGVO-konform ist. Das ist faktisch unmöglich. Auch weil Quellen oft sogar verschleiert sind. Bei statischen Seiten gibt es solche Software mit ihren Schnittstellen nicht.
Die Performance
Die Schnelligkeit statischer Seiten ist kein Zufall
Der Buchdruck 2.0
Stell dir vor, du bestellst ein Buch – möchtest also eine Website anschauen. Bei einem CMS bittet der Verkäufer um etwas Geduld und ruft erst mal den Autor an. Der stellt das Buch zusammen, lässt es frisch drucken. Die Druckerei bindet es wieder neu, packt es ein und stellt es dann dem Verkäufer ins Regal. Der gibt es dir und du kannst endlich lesen.
Bei einer statischen Seite steht das Buch fix und fertig im Regal – du nimmst es und liest. Genau das ist ein entscheidender Unterschied: kein lästiges Warten.
Weniger Arbeit ist weniger Wartezeit
Eine Website aus dem CMS wird bei jedem Aufruf komplett neu zusammengebaut: Datenbankabfrage, Template-Rendering, Abarbeiten der Plugins. Irgendwann ist das HTML-Dokument fertig. Der Webserver hat es mühsam zusammengesetzt, bevor er es losschicken konnte. Das kostet Zeit. Jedes Mal.
Eine statische HTML-Datei wartet bereits vor einer Anfrage auf dem Server. Kommt die Anfrage, wird die Seite sofort ausgeliefert – Byte für Byte, genau so, wie sie geschrieben wurde.
Der technische Hintergrund
CMS versuchen, über komplexe Cache-Systeme den systemischen Temponachteil zu kompensieren. Dafür werden Datenzustände zwischengespeichert, gecached. So stapeln sich diverse Speicher: z.B. Server-Cache, Datenbank-Cache, Reverse-Proxy, Object-Cache. Und die müssen alle synchron gehalten werden. Das erfordert ständige Abfragen und neue Berechnungen auf dem Server.
Statische Seiten haben gar keinen Server-Cache. Sie nutzen allenfalls den Browser-Cache. Der Unterschied? Es ist eine Schicht, nicht viele. Und die kontrollierst du. Fertig.
Warum das wichtig ist
Die Nutzererfahrung
Geschwindigkeit ist kein Selbstzweck. Besucher warten nicht ewig. Studien zeigen: Schon nach drei Sekunden Wartezeit geben über die Hälfte der Nutzer auf. Eine statische Seite startet sofort – auch auf dem Handy, auch bei schwachem Internet. Das hält die Leute dran.
Die Suchmaschinen und SEO
Suchmaschinen-Crawler arbeiten mit einem begrenzten Crawl-Budget. Sie haben nur eine bestimmte Zeit und Datenmenge für das Einlesen einer Webseite. Muss der Crawler diese Zeit mit unnötigen Skripten oder Daten vergeuden, bleibt weniger Zeit für den eigentlichen Inhalt. Wichtige Seiten und Inhalte können nicht vollständig indexiert werden.
Für Suchmaschinen wie Google & Co. ist Geschwindigkeit also ein elementarer Faktor. Sie messen, wie schnell Inhalte sichtbar werden und wie reaktionsschnell die Seite ist. Statische Seiten erfüllen diese Kriterien von Haus aus, ganz ohne komplexe Optimierungsläufe. Die Suchmaschinen können schneller lesen. Ein wichtiges Plus beim Ranking, bei ansonsten gleichwertigem Inhalt.
Performance ist mehr als nur Geschwindigkeit
Bei statischen Seiten können wir darüber hinaus die Struktur aktiv steuern. Wir entscheiden genau, welche HTML-Tags wo stehen: Ist das eine Hauptüberschrift oder nur ein fettgedruckter Text? Ist das eine Liste oder ein langer Absatz? Bei vielen CMS-Systemen wird der Code oft automatisch generiert und mit unnützen Container-Elementen überfrachtet, die für die Suchmaschine wertlos sind.
Schauen wir noch einmal auf das Buch: Das CMS-Buch ist gerne ein langer, unstrukturierter Textblock ohne klare Kapitel.
Ein statisches Buch hat ein klares Inhaltsverzeichnis, markante Überschriften und logische Abschnitte. Die Suchmaschine kann jetzt auch sofort erkennen, worum es geht und den Inhalt besser einordnen. Neben der Geschwindigkeit ein weiterer Pluspunkt beim Ranking.
Weniger Arbeit auf dem Server bedeutet weniger Wartezeit – für Besucher, die sofort lesen wollen, und für Suchmaschinen, die den Inhalt schnell erfassen müssen.
Der Mythos
Das leichte selber Ändern
Der Wunsch
Fast jeder wünscht es sich: die eigene Website später selber ändern können. Und landet prompt bei einem CMS. Denn das verspricht, genau das zu ermöglichen. Die Annahme dahinter: HTML-Code ändern ist kompliziert – ein CMS bedienen nicht.
Schauen wir genauer hin. Ein CMS-Backend ist für Ungeübte schnell erschlagend. Hier ein Menü, dort ein Plugin, drüben ein Widget. Irgendwo die Seitenvorlage, irgendwo die Medienbibliothek. Und irgendwann schnell ein Update machen. Backup vergessen – und schon sieht die Seite ganz anders aus als vorher. Oder funktioniert gar nicht mehr.
Die Praxis
Die Praxis zeigt: Die meisten Kunden ändern ihre Seite nach dem Launch kaum noch. Und wenn doch? Dann war man lange nicht im CMS, hat womöglich die Zugangsdaten vergessen, findet sich nicht mehr zurecht und muss ohnehin jemanden fragen.
Was bleibt, ist ein System, das permanent Updates braucht, Sicherheitslücken bietet und für den gelegentlichen Einsatz viel zu komplex ist – während die wenigen Änderungen, die tatsächlich anfallen, in einer HTML-Datei genauso schnell erledigt wären.
Baukästen brauchen Einarbeitung, wie HTML auch
Niemand öffnet ein CMS zum ersten Mal und weiß sofort, wo was ist. Du musst dich einarbeiten – in Menüs, in Plugins, in Seitenstrukturen. Das dauert. Und weil du es selten nutzt, verlernst du es wieder. Nach Updates ist häufig ohnehin eine erneute Einarbeitung nötig.
HTML ist nicht anders: Du musst dich einarbeiten. Aber der Unterschied ist, was du lernst. Bei einer statischen Seite lernst du genau das, was deine Seite ausmacht – deinen Text, deine Struktur, deine Datei. Nicht eine abstrakte Oberfläche mit hundert Optionen, von denen du am Ende nur drei brauchst.
Und wenn wir das übernehmen, bleiben die technischen Vorteile einer statischen Website.