Bei der Analyse einer älteren WordPress-Installation fiel mir kürzlich etwas auf, das auf den ersten Blick harmlos wirkt: Dateien mit der Endung .php — die aber kein einziges Byte PHP enthalten. Stattdessen: XML-Strukturen, SVG-Markup, statische Inhalte. Alles prima, nur eben nicht PHP.
Klingt nach Kleinigkeit. Ist es nicht.
Was PHP mit diesen Dateien macht
PHP ist kein passiver Durchreicher. Jede Datei mit der Endung .php wird vom Server an den PHP-Interpreter übergeben — der öffnet sie, parst sie, sucht nach ausführbarem Code und findet: nichts. Dann liefert er den Inhalt aus. Unnötiger Aufwand, der sich über viele Requests summiert.
Ein reines HTML-File dagegen wird direkt vom Webserver ausgeliefert — ob Apache, Nginx oder ein anderer.
Der unsichtbare 500er
In diesem konkreten Fall enthielten die Dateien valides XML und SVG — technisch einwandfrei. Das Problem: PHP hat diese Dateien trotzdem als PHP-Code zu interpretieren versucht. Dabei ist es erwartungsgemäß gescheitert und hat einen 500er geworfen — so früh im Prozess, dass nicht mal ein Log-Eintrag entstehen konnte.
Auf einem Live-System mit deaktiviertem Debugging sieht man davon schlicht nichts. Kein Log-Eintrag, keine Fehlermeldung, kein Hinweis. Die Seite liefert einen 500er und niemand weiß warum.
Das ist die gefährlichste Art von technischer Schuld: still, unsichtbar, schwer zu debuggen — und rein technisch gesehen komplett unnötig.
Die saubere Alternative
Die Lösung ist so simpel wie konsequent: Dateien die kein PHP enthalten bekommen keine .php Endung.
HTML bleibt .html. SVG bleibt .svg. XML bleibt .xml. Der Webserver liefert diese Dateien direkt aus — kein Parsing, kein Overhead, kein 500er-Risiko.
Das gilt übrigens nicht nur für WordPress. Wenn eine Datei kein PHP enthält, hat sie nichts in der PHP-Pipeline verloren.
Fazit
Bei aktuellen Hardwarepreisen ist jeder unnötige CPU-Zyklus einer zu viel – zumal ja nicht nur die CPU genutzt wird sondern auch Arbeitsspeicher und vor allem Zeit. Aber der eigentliche Grund diese Praxis zu vermeiden ist Beherrschbarkeit. Eine .html Datei kann fast nie einen 500er werfen. Eine .php Datei die kein PHP enthält aber schon.
Technische Schuld entsteht selten durch große Entscheidungen. Meistens durch kleine Gewohnheiten die niemand hinterfragt.
FAQ
Gibt es Sicherheitsbedenken bei reinen HTML Dateien?
Nein, da HTML per se nur Text enthält kann das nichts auslösen. Oder anders gesagt: Auch eine durch PHP bediente HTML Datei ist nicht weniger sicher oder mehr sicher.
Was ist wenn meine Datei einen Anteil dynamischen Codes enthält?
Zwei Möglichkeiten: Entweder bleibt die Datei in der Fassung. Das ist aber meist unperformant weil 90% der Inhalte keine dynamische Erzeugung brauchen. Besser ist dort via AJAX und JS die dynamischen Anteile nachzuladen. Das hilft auch, dass die Inhalte schneller ausgegeben werden können.
Kann das mein WordPress/WordPress-Theme auch?
Es kommt drauf an. Einige Tools machen das genauso. „Out of the box“ macht das WordPress aber nicht. Es gibt aber immer Mittel und Wege das zu ermöglichen. Und gerade bei WordPress ist der Effekt besonders groß da wenn es durch die WordPress-Pipeline muss, nicht nur PHP getriggert wird, sondern erst mal der gesamte WordPress Stack mit geladen und verarbeitet wird. Das ist übrigens einer der größten Gründe, warum WordPress strukturell langsam wirkt vor allem wenn viele Plugins installiert sind.
Kommentar verfassen