Wobei es programmiertechnisch gar keinen Unterschied gibt ob ein HTML Template oder ein GIF aus MySQL gelesen wird.
Klar. Bei einem HTML-Template ist das ja auch sinnvoll, weil es vermutlich vor der Ausgabe an den Client mit dynamischen Inhalten angereichert wird.
Warum sollte das ein Argument pro DB sein? Da muss das Template ja ersteinmal reinkommen, also brauchts ein Backend zum Erstellen+Bearbeiten. Da ist doch viel einfacher, HTML Templates als Dateien abzulegen.
Bei einem statischen(!) GIF ist das nicht der Fall. Ergo würde man dem Webserver im Vergleich zu einem statischen File das zigfache an Last aufbürden, um die Ressource an den Client auszuliefern.
Ein HTML Template durchläuft zum Rendern auch den Hauptspeicher und auch dann wenn es aus dem Dateisystem geladen wird.
Nicht gut. Klar, das kann man nun mittels Caching lösen, indem man das File bei Bedarf erzeugt und im Filesystem ablegt. Dann muss man sich aber drum kümmern, den Cache zu invalidieren, wenn sich der Inhalt des Bildes ändert. Um die Header muss man sich auch noch kümmern. Ganz schön viel Aufriss für eine statische Ressource, die der Webserver von Haus aus umfassend und schnell behandelt.
Ein Webserver erstellt den Last-Modified oder FileEtag Header anhand mtime einer Datei. Diesen Header selbst zu erzeugen, ist überhaupt kein Aufwand, vorausgesetzt man hat die mtime.
Also insgesamt überzeugen Deine Argumente nicht wirklich. MfG