Wenn die Wolke weiterzieht: WordPress optimieren ohne Cloudflare

Wenn Optimierung plötzlich nach Maschinenraum riecht

Sicher werden die Experten unter euch jetzt schon die Augen verdrehen. Die einen, weil sie sagen: „Das ist doch alles halb so wild.“ Die anderen, weil sie sich mit solchem Kram aus Prinzip nicht befassen und vermutlich spätestens beim Wort Nameserver innerlich den Tab schließen. Und wieder andere werden diese nervige Geschichte als Bestätigung dafür betrachten, dass man von einem laufenden System besser die Finger lässt.

Kann man so sehen.

Aber ich bin nun mal ein Bastler. Genauer gesagt: ein Rentner-Bastler mit außergewöhnlich viel Zeit. Und diese Zeit verplempere ich zu gern mit solchen Dingen, die für andere nach technischem Kleinkram aussehen, für mich aber immer noch kleine Abenteuer sind. Abenteuer im Maschinenraum. Mit DNS-Einträgen statt Dschungelpfad, SSL-Zertifikaten statt Kompass und Google PageSpeed als nervösem Reiseleiter, der alle fünf Minuten eine andere Bewertung in die Landschaft hält.

Es gibt diese Tage, an denen man am eigenen WordPress-System eigentlich nur ein bisschen aufräumen will. Ein paar Stellschrauben drehen, ein paar Ladezeiten glätten, vielleicht hier und da ein Plug-in bändigen. Man nimmt sich vor, sachlich zu bleiben. Ruhig. Erwachsen. Fast staatsmännisch. Ich habe den Blog aufgeräumt und eine ganze Reihe Plug-ins entfernt. Auch solche, auf die ich bisher nicht verzichten mochte. Es gibt nicht mehr die Möglichkeit, Kommentare nachträglich zu ändern oder sich bei neuen Kommentaren eine Benachrichtigung zu schicken. Die Bewertung von Artikeln und Kommentaren ist abgeschaltet. Eine Bildergalerie ist raus. Das waren zum Teil kostenpflichtige Plug-ins, auf die ich jetzt bewusst verzichte. Im Kommentarbereich z.B. ist derzeit so wenig los, dass solche Maßnahmen sich geradezu aufdrängen. Solche Services weiß ohnehin fast niemand zu schätzen.

Gestern Morgen war mein Blog nicht erreichbar. Ich konnte den Editor nicht öffnen, mich nicht mal mehr anmelden. Nach einigem Gehuddel klappte es dann doch und ich nutzte zum ersten Mal Updraft Plus. Das war erfolgreich, wäre allerdings wie sich erst später herausstellte, gar nicht erforderlich gewesen. Irgendwas musste in der Nacht zuvor passiert sein. War es das Gewitter? Lag es am Hoster? Ich glaube, die Ursache lag bei Cloudflare. Purge everything heißt die Lösung. Den Cloudflare-Cache leeren, damit Cloudflare frische Dateien vom Ursprungsserver holt. Danach war alles wieder wie es sein sollte. Nun war ich es leid. Mein Test von Cloudflare, der lediglich über ca. 2 Monate andauerte, sollte beendet werden.

Und dann sitzt man vor DNS-Einträgen, Nameservern, SSL-Zertifikaten, Cloudflare-Einstellungen und Google-Speed-Werten und fragt sich, ob man gerade den Blog optimiert oder versehentlich die Schaltzentrale eines mittleren Raumfahrtprogramms geöffnet hat.

Mein Ziel war klar: Ich wollte auf Cloudflare verzichten. Nicht, weil Cloudflare grundsätzlich Teufelszeug wäre. Für große Seiten, internationale Projekte, Shops oder stark angegriffene Systeme kann Cloudflare sehr sinnvoll sein. Aber für meinen Blog wollte ich wieder mehr Übersicht. Weniger Zwischeninstanzen. Weniger Magie im Hintergrund. Weniger dieser Momente, in denen man denkt: „Das kann doch nur am Cache liegen“ — und dann liegt es am Cache. Oder am DNS. Oder am SSL-Zertifikat. Oder an einer Regel, die man vor Monaten gesetzt und längst vergessen hat.

Der Cloudflare-Rückbau war also keine Heldentat. Eher ein kontrollierter Rückzug aus der Wolke. Aber einer, bei dem man besser nicht in falscher Reihenfolge an den Hebeln zieht.

Die Google-Speed-Achterbahn als letzter Anstoß

Ein wichtiger Grund für meine Entscheidung waren die sehr unterschiedlichen Messergebnisse bei Google PageSpeed Insights. Mal sah alles ordentlich aus, dann brachen einzelne Werte wieder ein, ohne dass ich im WordPress-System bewusst etwas verändert hatte. Solche Schwankungen machen mürbe. Man optimiert ein Bild, verändert eine Lazy-Load-Regel, schiebt ein Script aus der Verzögerung heraus, misst erneut — und plötzlich sieht das Ergebnis aus, als hätte nachts ein Kobold im Quellcode gebügelt.

Besonders nervig waren Effekte rund um verzögertes JavaScript. Einzelne sichtbare Elemente tauchten zu spät auf. Avatare oder kleine Oberflächenelemente wurden kurz falsch platziert. Manchmal sah die Seite beim ersten Laden so aus, als hätte sie sich beim Anziehen im Dunkeln vertan.

Das Problem war nicht ein einzelner großer Fehler. Es war dieses Zusammenspiel aus WordPress, Theme, GenerateBlocks, Perfmatters, Lazy Loading, JavaScript-Verzögerung, Cache und Cloudflare. Jeder dieser Bausteine kann hilfreich sein. Aber wenn zu viele Schichten übereinanderliegen, wird die Fehlersuche schnell zu einer Art digitalem Nebelwandern.

Nach dem Cloudflare-Rückbau und der sauberen Abstimmung mit Perfmatters sind diese Schwankungen nun endlich beseitigt. Die Werte liegen mobil stabil bei 98 bis 100 Prozent, Desktop bei 100 Prozent. Das lässt sich sehen. Nicht als Angeberei mit Fanfaren, eher als erleichtertes Ausatmen im Maschinenraum.

Warum Cloudflare für kleine Blogger nicht immer ein Segen ist

Cloudflare ist kein schlechtes Werkzeug. Im Gegenteil. Wer eine stark besuchte Website betreibt, internationale Zugriffe abfangen muss oder regelmäßig Sicherheitsprobleme erlebt, kann von Cloudflare deutlich profitieren. Das will ich gar nicht kleinreden.

Aber für kleine Blogger sieht die Sache anders aus. Ein persönlicher WordPress-Blog braucht in der Regel keine weltweite Lastverteilung, keine hochkomplexen Sicherheitsregeln und keine zusätzliche DNS-Zwischenschicht, nur damit am Ende ein paar Beiträge über Politik, Gesellschaft und das tägliche digitale Durcheinander ausgeliefert werden.

Der Nachteil liegt nicht darin, dass Cloudflare schlecht wäre. Der Nachteil liegt darin, dass Cloudflare die Struktur komplizierter macht. Plötzlich gibt es mehrere Caches: den WordPress-Cache, den Browser-Cache, den Server-Cache und zusätzlich den Cloudflare-Cache. Wenn dann etwas hakt, beginnt die bekannte Fehlersuche im Halbdunkel. Liegt es am Theme? An GenerateBlocks? An Perfmatters? Am Hoster? An Cloudflare? An DNS? An SSL? An einer Cache-Regel?

Genau das ist für kleine Blogger der Knackpunkt. Man gewinnt manchmal Geschwindigkeit, aber man verliert Übersicht. Man bekommt mehr technische Möglichkeiten, aber auch mehr Stellen, an denen etwas unsichtbar dazwischenfunken kann. Und wer seinen Blog selbst pflegt, kennt dieses Gefühl: Man will schreiben, nicht jeden zweiten Tag den Internet-Klempner geben.

Mein Cloudflare-Rückbau war deshalb keine Grundsatzrede gegen Cloudflare. Es war eine nüchterne Entscheidung für mein eigenes System: weniger Zwischeninstanzen, weniger Rätselraten, mehr direkte Kontrolle.

Erst prüfen, dann löschen

Der wichtigste Gedanke beim Cloudflare-Rückbau lautet: Cloudflare nicht sofort löschen. Nicht im Überschwang. Nicht aus Trotz. Nicht, weil man gerade mutig ist und der Kaffee noch wirkt.

Der saubere Weg beginnt damit, dass man die DNS-Einträge im KAS von all-inkl prüft. Dort müssen die entscheidenden Einträge bereits vorhanden sein, bevor man die Nameserver endgültig zurückstellt. Bei mir waren die wichtigsten Dinge bereits vorbereitet: Der A-Record zeigte auf die all-inkl-IP, der Wildcard-Eintrag ebenfalls, der MX-Eintrag lag auf dem passenden kasserver.com-Server, SPF, DKIM, DMARC und MailPoet-Einträge waren vorhanden.

Das klingt trocken. Ist es auch. Aber genau diese Trockenheit rettet einem den Tag. DNS ist kein Ort für Improvisation. DNS ist eher wie ein Sicherungskasten im Keller: Man kann daran arbeiten, aber man sollte vorher wissen, welcher Schalter wofür zuständig ist.

In meinem Fall war die gute Nachricht: Im KAS musste praktisch nichts mehr neu eingetragen werden. Die Basis war da. Der Blog stand nicht nackt im Regen. Er hatte schon Jacke, Schuhe und Hausschlüssel. Es fehlte nur noch der eigentliche Schritt zurück zu all-inkl.

Die richtige Reihenfolge beim Cloudflare-Rückbau

Beim Cloudflare-Rückbau zählt die Reihenfolge. Wer zu früh löscht, zu spät prüft oder ein SSL-Zertifikat übersieht, kann sich unnötige Ausfälle einhandeln. Der Rückbau sollte deshalb geordnet erfolgen.

Zuerst sollten alle bestehenden DNS-Einträge bei Cloudflare gesichert oder zumindest notiert werden. Dazu gehören A-Records, CNAME-Einträge, MX-Einträge und TXT-Einträge für SPF, DKIM, DMARC oder Dienste wie MailPoet. Diese Einträge müssen im KAS von all-inkl vorhanden sein oder dort sauber nachgetragen werden.

Danach prüft man im KAS die DNS-Einstellungen. Entscheidend sind vor allem der A-Record für die Hauptdomain, gegebenenfalls der Wildcard-Eintrag, der www-Eintrag, der MX-Eintrag für E-Mails und die TXT-Einträge für Mail-Sicherheit und Verifizierungen. Wer MailPoet nutzt, sollte auch die entsprechenden DKIM- und Verifizierungs-Einträge im Blick behalten.

Erst dann kommt das SSL-Zertifikat. Im KAS sollte unter dem Bereich für SSL-Schutz ein gültiges Let’s-Encrypt-Zertifikat für die Domain aktiv sein. Das ist wichtig, weil nach dem Wegfall von Cloudflare der eigene Server selbst sauber HTTPS ausliefern muss. Das kleine Schloss im Browser ist dann nicht mehr Cloudflares freundliche Fassade, sondern die eigene Haustür.

Wenn diese Basis stimmt, kann man in Cloudflare den Proxy-Status der DNS-Einträge deaktivieren. Die orange Wolke wird grau. Aus „Proxy“ wird „DNS only“. Damit läuft der Traffic schon direkter zum Server, ohne dass Cloudflare als Proxy dazwischensteht. Das ist ein sinnvoller Testlauf, bevor man die Nameserver endgültig zurückstellt.

Danach folgt der eigentliche Heimweg: In der all-inkl-Verwaltung werden die Nameserver von Cloudflare zurück auf die all-inkl-Nameserver geändert. In meinem Fall ging es um ns5.kasserver.com und ns6.kasserver.com. Sobald diese Änderung gespeichert ist, beginnt die DNS-Propagation. Das ist der Moment, in dem man technisch schon viel getan hat, aber noch nicht überall sofort das Ergebnis sieht.

Und erst ganz zum Schluss, wenn alles stabil läuft, kann die Domain bei Cloudflare entfernt werden.

Die Wolke grau machen, bevor sie verschwindet

Ein sinnvoller Zwischenschritt ist es, in Cloudflare den Proxy-Status der DNS-Einträge zu deaktivieren. Die orange Wolke wird grau. Aus „Proxy“ wird „DNS only“.

Das ist ein kleiner Klick mit großer psychologischer Wirkung. Denn damit läuft der Traffic nicht mehr durch Cloudflare, sondern direkt zum Server. Man kann prüfen, ob die Seite auch ohne die schützende, manchmal aber auch nervende Wolke erreichbar ist.

Dieser Schritt ist keine Pflicht in Stein gemeißelt, aber er ist sehr empfehlenswert. Er ist wie ein Probelauf vor der eigentlichen Premiere. Wenn hier schon etwas kracht, weiß man wenigstens, dass man noch nicht das ganze Theater abgebaut hat.

Und ja: Genau an solchen Stellen merkt man, wie abhängig man sich von Diensten gemacht hat, die im Alltag unsichtbar bleiben. Solange alles funktioniert, ist Cloudflare ein höflicher Butler. Sobald etwas hakt, steht derselbe Butler plötzlich mitten im Flur und hält einem fünf Türen gleichzeitig auf.

Das SSL-Zertifikat: Der kleine Schlossmoment

Ein besonders wichtiger Punkt beim Cloudflare-Rückbau ist das SSL-Zertifikat. Solange Cloudflare dazwischensteht, wirkt manches sicherer und glatter, als es auf dem Ursprungsserver tatsächlich eingerichtet ist. Fällt Cloudflare weg, muss der Server selbst sauber HTTPS ausliefern.

Bei all-inkl bedeutet das: Im KAS die betreffende Domain prüfen und sicherstellen, dass Let’s Encrypt aktiv ist. Das Zertifikat muss für die Domain gültig eingebunden sein. Erst dann ist der Rückweg von Cloudflare wirklich entspannt.

Das ist einer dieser Punkte, bei denen Panik schnell die Gardinen hochklettert. Man sieht eine Warnung, ein Schloss fehlt, der Browser schaut streng, und schon denkt man: Jetzt ist der Blog kaputt. Dabei ist meistens nur die Reihenfolge nicht sauber oder die DNS-Umstellung noch nicht überall angekommen.

Wichtig ist: HTTPS muss vor oder spätestens während der Nameserver-Rückstellung sauber vorbereitet sein. Denn ohne Cloudflare gibt es keinen freundlichen Vermittler mehr, der an der Tür sagt: „Alles gut, ich regle das mit dem Zertifikat.“

Nameserver zurück zu all-inkl: Der eigentliche Heimweg

Der zentrale Schritt war der Wechsel der Nameserver zurück auf all-inkl. In meinem Fall ging es um ns5.kasserver.com und ns6.kasserver.com. Genau hier entstand zunächst Unsicherheit, weil es im Netz und in manchen Hinweisen verschiedene Varianten gibt: ns5, ns6, manchmal auch längere ns5xxx- oder ns6xxx-Bezeichnungen.

Die Lösung war einfacher, als sie sich anfühlte: In der all-inkl-Verwaltung wird beim Ändern der Nameserver der zweite Nameserver in der Regel automatisch erkannt, sobald der erste korrekt eingetragen ist. Man trägt also den passenden ersten Nameserver ein, geht weiter, prüft, was all-inkl ergänzt, und speichert.

Vorher standen dort noch die Cloudflare-Nameserver. Das erklärte auch die Warnung, dass die Domain nicht sauber mit dem all-inkl-Webspace verbunden sei. Diese Meldung ist der Moment, in dem man kurz innerlich die Luft anhält. Man sieht ein Ausrufezeichen und denkt: „War schön mit euch. Der Blog war ein guter Kamerad.“

Aber nein. Es war nur die Technik, die sagte: „Noch bist du nicht wieder zu Hause.“

Nach dem Speichern der neuen Nameserver beginnt die Wartephase. Und diese Wartephase hat etwas Gemeines: Man hat alles getan, aber man sieht nicht sofort überall das Ergebnis. DNS-Propagation ist die Kunst, dem Internet beim Nachdenken zuzusehen.

Bitte nicht zu früh Cloudflare löschen

Der vielleicht wichtigste praktische Rat lautet: Cloudflare erst löschen, wenn die Umstellung stabil durch ist.

Solange weltweit noch Server die alten Cloudflare-Nameserver kennen, kann Cloudflare als eine Art Fallback dienen. Löscht man die Domain dort zu früh, kann es für einzelne Nutzer oder Prüfwerkzeuge zu Aussetzern kommen. Deshalb: erst prüfen, dann aufräumen.

Ich würde nach dem Nameserver-Wechsel diese Reihenfolge einhalten:

1. Website im Browser mit https://horstschulte.com prüfen
2. WordPress-Backend testen
3. mehrere Unterseiten aufrufen
4. SSL-Schloss im Browser kontrollieren
5. E-Mail-Empfang und Versand prüfen
6. DNS-Abfrage auf NS-Einträge kontrollieren
7. erst danach Cloudflare entfernen

Dazu kann man externe Prüfseiten wie https://www.whatsmydns.net/ oder https://dnschecker.org/ nutzen. Dort prüft man für die eigene Domain den Typ NS. Wenn dort weltweit allmählich ns5.kasserver.com und ns6.kasserver.com auftauchen, ist der Rückweg in vollem Gang.

Cloudflare selbst kann danach aufgeräumt werden. Vor dem endgültigen Entfernen sollte man prüfen, ob DNSSEC in Cloudflare aktiv war. Falls ja, zuerst deaktivieren. Sonst kann es passieren, dass die Domain formal korrekt zeigt, aber die Namensauflösung an einer alten Sicherheitskette hängen bleibt. Das wäre dann die Sorte Fehler, bei der man sich erst fragt, ob der Server kaputt ist, dann das Theme, dann WordPress, dann das Leben.

Perfmatters: nicht alles auf Anschlag drehen

Nach dem Cloudflare-Rückbau wurde Perfmatters für mich noch wichtiger. Nicht als Wunderwaffe, sondern als Werkzeugkasten. Genau darin liegt der Unterschied. Wer bei Optimierung einfach alles aktiviert, gewinnt nicht automatisch Geschwindigkeit. Man kann sich damit auch sichtbare Elemente verzögern, Layout-Verschiebungen einbauen oder aus einem schnellen Blog eine nervöse Baustelle machen.

Besonders wichtig waren bei mir die Bereiche JavaScript-Verzögerung, Lazy Loading, kritische Bilder und die gezielte Behandlung sichtbarer Elemente. Wenn ein Avatar, ein Kommentarbereich, ein kleines Symbol oder eine Bedienfläche direkt beim Laden sichtbar sein soll, darf es nicht durch verzögertes JavaScript erst später zurechtgerückt werden.

Perfmatters hilft genau dort, weil man nicht nur pauschal optimieren muss, sondern Ausnahmen setzen kann. Kritische Bilder können vom Lazy Loading ausgeschlossen werden. Führende Bilder können priorisiert werden. Skripte, die sofort gebraucht werden, können aus der Verzögerung herausgenommen werden. Andere Skripte, die erst weiter unten auf der Seite wichtig sind, dürfen warten.

Das klingt nach Kleinarbeit. Ist es auch. Aber es ist die gute Sorte Kleinarbeit. Die Sorte, bei der man am Ende nicht mehr im Nebel steht, sondern erkennt: Dieses Element braucht sofortige Aufmerksamkeit, jenes darf später kommen.

Für mein WordPress-System waren vor allem diese Punkte entscheidend:

1. JavaScript verzögern, aber sichtbare Effekte ausschließen
2. kritische Bilder vom Lazy Loading ausnehmen
3. LCP-relevante Bilder priorisieren
4. unnötige Skripte nur dort laden, wo sie gebraucht werden
5. CSS- und JavaScript-Optimierung Schritt für Schritt testen
6. sichtbare UI-Elemente nicht der Verzögerung opfern
7. Messergebnisse nicht nach einem einzigen Test bewerten

Der letzte Punkt ist wichtig. Google PageSpeed Insights ist hilfreich, aber ein einzelner Test ist kein Evangelium. Entscheidend ist, ob die Werte stabil bleiben. Genau das ist jetzt der Fall. Mobil 98 bis 100 Prozent, Desktop 100 Prozent. Und das nicht als zufälliger Sonntagswert, sondern als wiederholbar gutes Ergebnis.

Und dann diese 17 Prozent

Während man also mit Nameservern, SSL-Zertifikaten, DNS-Propagation und Performance-Werten ringt, taucht irgendwo auch noch ein Hinweis auf: „Spare jeden Monat 17 %, indem du deinen Tarif auf jährlich umstellst.“

Natürlich. Genau der richtige Moment.

Da sitzt man mit leicht erhöhtem Puls vor der technischen Infrastruktur des eigenen Blogs, sieht Warnhinweise, Zertifikatsfragen und DNS-Einträge, und dann kommt das Internet mit einem freundlichen Werbeschild um die Ecke: „Möchtest du nicht nebenbei noch deine Abrechnung optimieren?“

Das ist die digitale Gegenwart in einem Satz. Du willst nur dein WordPress-System stabilisieren, und irgendein Dienst reicht dir einen Rabattcoupon, während du prüfst, ob deine Domain noch lebt.

Aber vielleicht passt es sogar. Denn Optimierung ist nicht nur Geschwindigkeit. Optimierung ist auch Übersicht. Kosten. Abhängigkeiten. Wartbarkeit. Vertrauen. Wer seine Technik versteht, trifft bessere Entscheidungen. Auch beim Tarif. Nur bitte nicht mitten im Nameserver-Wechsel. Da sollte man keine Finanzentscheidungen treffen. Da sollte man atmen.

Was ich aus dem Rückbau gelernt habe

Der Cloudflare-Rückbau war am Ende weniger dramatisch, als er sich zwischendurch anfühlte. Aber genau das ist der Punkt: Technik erzeugt nicht nur Fehler. Sie erzeugt Gefühle. Kleine Schrecksekunden. Große Fragezeichen. Dieses dumpfe „Habe ich jetzt alles zerschossen?“

Die Antwort lautet meistens: nein. Aber man braucht eine gute Reihenfolge.

Erst DNS-Einträge sichern und prüfen. Dann SSL bei all-inkl kontrollieren. Dann Cloudflare-Proxy testweise auf „DNS only“ stellen. Dann Nameserver zurück auf all-inkl setzen. Dann warten. Dann prüfen. Dann noch einmal prüfen. Und erst wenn alles stabil läuft, Cloudflare entfernen.

So wird aus dem Cloudflare-Rückbau kein Sprung aus dem Flugzeug, sondern ein geordneter Abstieg über eine Treppe. Eine Treppe mit ein paar knarrenden Stufen, ja. Aber immerhin mit Geländer.

Und vielleicht ist genau das die eigentliche WordPress-Optimierung: nicht immer noch ein Dienst, noch ein Plugin, noch ein Cache, noch eine Schicht obendrauf. Sondern manchmal weniger. Klarer. Direkter.

Der Blog muss nicht durch jede Wolke fliegen. Für meinen Fall reicht es, wenn er sauber auf dem eigenen Server steht, sein Zertifikat trägt wie einen ordentlich geknöpften Mantel und mit Perfmatters dort optimiert wird, wo es wirklich etwas bringt.

Das Ergebnis ist sichtbar: stabile PageSpeed-Werte, weniger Rätselraten, weniger Zwischenschichten und ein System, das wieder nachvollziehbarer geworden ist.

Das ist nicht spektakulär. Aber es ist beruhigend.

Und Beruhigung ist im Maschinenraum des Internets eine stark unterschätzte Performance-Metrik.