In diesem Artikel möchte ich auf verschiedene Wege eingehen, die man bis zur eigenen Website gehen kann. Der Artikel erhebt keinen Anspruch auf Vollständigkeit, soll aber doch eine Übersicht über dieses komplexe Thema bieten. Er konzentriert sich auf technische Aspekte, denn in erster Linie ist eine Website die technische Implementierung eines abstrakten Konzepts. Damit das Konzept aufgeht, muss die Technik stets unter Kontrolle sein. Eine gute Übersicht über die zahlreichen technischen Finessen ist Pflicht, ansonsten überraschen auf lange Sicht diverse Probleme — wahrscheinlich auch den Nutzer. Allgemein gilt: bei der Implementierung einer Website ist ein besonders großes Spektrum verschiedener technischer Aspekte zu berücksichtigen. Ist die eigene Website von Bedeutung (privat oder für das Geschäft), sollte man auf professionellen Rat nicht verzichten.

Hintergrund: wie funktioniert eine Website, welche Technologien sind involviert?

Das Back-End (was die Nutzer nicht sehen!): statisch oder dynamisch?

Aus technischer Perspektive kann man Internetpräsenzen am Besten anhand ihres sogenannten “Back-Ends” klassifizieren. Dort gibt es die technisch größten Unterschiede zwischen Websites — je nach Komplexität des Back-Ends entscheidet sich, ob die Implementierung ein kleines Projekt für eine Person ist oder ein großes Team über Jahre beschäftigt. Das ist natürlich nicht für Jedermann ersichtlich, schließlich kommt der Nutzer nur mit dem “Front-End” (dem “Interface” bzw. dem visuellen Teil) der Internetpräsenz in Kontakt. Doch was ist das Back-End überhaupt? Im einfachsten Fall, einer statischen Website, ist das eine Webserver-Infrastruktur, die anhand einer vorgegebenen URL (universeller Ressourcen-Lokator, “Link” bzw. “Internetadresse”, z. B. http://juergen.info/uebermich) für jeden Besucher den selben Inhalt ausliefert. Der Inhalt ist einmalig definiert worden und wird, wenn überhaupt, nur selten und per manueller Änderung im Dateisystem modifiziert. Im Gegensatz dazu wird bei einer dynamischen Internetseite der Seiteninhalt (der Teil, der beim Nutzer ankommt und im Browser visualisiert wird) bei jedem Seitenaufruf neu bestimmt. Das übernimmt eine Software, die auf einem Rechner in irgendeinem Rechenzentrum der Welt läuft. Sie generiert aus Nutzerperspektive möglichst in Echtzeit den aktuell anzuzeigenden Inhalt, indem sie einen oder mehrere Datenquellen auswertet. Die Daten, die hier vermengt werden, sind in der Regel teilweise durch den Nutzer in seiner Anfrage vorgegeben und werden anderen Teils aus externen Quellen bzw. einem Datenbanksystem entnommen. Ein simples Beispiel ist eine fiktive Telefonbuch-Website: Der Nutzer gibt Name und Ort vor, die “Website” gibt eine Telefonnummer zurück. Transparent für den Nutzer hat ein Computerprogramm im Back-End der Website auf Basis der vom Nutzer übergebenen Daten eine Datenbankanfrage gestartet und das Ergebnis für den Nutzer aufbereitet ausgeliefert.

Aus informationstheoretischer Perspektive ist offensichtlich, dass eine Internetpräsenz wie Facebook massive Datenverarbeitungssysteme im Back-End einsetzt. Die Komplexität eines solchen Gesamtsystems ist in vielerlei Hinsicht einmalig groß und fordert eine Vielzahl von Expertenteams heraus. Doch auch andere stark frequentierte Websites wie z. B. Wikipedia, tagesschau.de oder spiegel.de haben eine Infrastruktur von enormer Größe im Hintergrund, die viel Kosten für Personal, Hardware und Netzwerkanbindung verursacht. Über die Details dieser Strukturen soll es in diesem Artikel nicht gehen — ich möchte nur gerne dafür sensibilisieren, dass Websites und insbesondere interaktive Webanwendungen oftmals durch komplexe Computersysteme betrieben werden, deren Existenz und Topologie für den Nutzer normalerweise völlig transparent sind. Die wichtigsten Websites, die wir im Alltag benutzen, sind hochgradig dynamische Systeme.

Ob für die eigene Website eine statische oder dynamische Variante in Frage kommt, hängt davon ab, in welcher Weise man Inhalte ändern möchte. Wenn man heutzutage sein kleines Unternehmen im Internet präsentieren möchte, dann reicht oft eine statische Website. In diesem Fall kann man sich überwiegend auf die Entwicklung und das “Deployment” des Front-Ends konzentrieren. Zu diesen Themen komme ich weiter unten.

Doch was ist, wenn man die Besucher komfortabel und mit hoher Frequenz über Neuigkeiten informieren möchte? So etwas kann man heute “Blog” nennen. Der Sinn des Ganzen ist, dass man Neuigkeiten, kurze Nachrichten oder Artikel auf seiner Website veröffentlichen kann, obwohl man eigentlich nur Nutzer derjenigen ist — ein Nutzer mit besonderen Rechten, die man per Login erlangt. Wenn man selbst per gesondertem Administrationsbereich auf einer Website Inhalte einpflegen bzw. ändern möchte, dann befindet man sich im Regime der automatisierten Inhaltsverwaltung, Neudeutsch “content management”.

Content Mangement

Die meisten der heutigen Websites sind basiert auf einem Content Management System, kurz CMS. Das ist eine Software, die eine Internetseite zum Verwalten der eigentlichen Internetseite zur Verfügung stellt. Ich schreibe meinen Blog hier in einem Administrationsbereich, den Ihr nicht seht. Diesen Verwaltungsbereich habe ich nicht selbst gebaut, sondern der ist Teil eines CMS, WordPress in diesem Fall. Jedes CMS ist relativ komplexe Software, in der die Datenbankanbindung große Rolle spielt. Hinter jedem CMS steht das Konzept der klaren Trennung von dynamischen Inhalten und konstanten Elementen. Inhalte und Einstellungen sind in einer Datenbank gespeichert, bei jedem Aufruf einer Ressource (Webseite) holt sich das CMS die Inhalte und Einstellungen aus der Datenbank, vermischt sie mit einem Front-End-Template und generiert die Internetseite, die der Browser des Nutzers auf seine Anfrage hin als Antwort zugesendet bekommt.

Für den Hausgebrauch und für komplexere CMS-basierte Websites hatte sich in den vergangenen 10 bis 15 Jahren die Programmiersprache PHP etabliert. Als Datenbanksystem kommt oft MySQL zum Einsatz. Als Webserver-Software wird zumeist Apache eingesetzt. Alles ist quelloffene Software. Bei Webhosting-Anbietern gibt es seit vielen Jahren sehr günstige Webhosting-Pakete, die auf Apache basieren und PHP und MySQL unterstützen. Diverse quelloffene CMS-Programme sind über die Jahre entstanden. Apache, PHP und MySQL — das ist eigentlich das Minimum an Technologien, mit denen man konfrontiert wird, wenn man eine eigene dynamische Website im Rahmen eines klassischen Webhosting-Pakets aufsetzt (und im begrenzen Maße auch POSIX/Linux, wenn man z. B. mit Dateisystem-Rechten konfrontiert ist). Damit meine ich nicht, dass man all diese Technologien verstehen muss — es gibt Helferlein, die viel Arbeit abnehmen — aber die Einstiegshürde ist in jedem Fall höher als bei einer rein statisch betriebenen Website. Außerdem, und das ist ein außerordentlich wichtiger Punkt, ergibt sich beim Einsatz eines CMS ein deutlich größeres Potential technische Fehler zu begehen als bei einer statischen Website.

Im professionellen Bereich haben sich neben PHP und MySQL seit jeher viele weitere Technologien etabliert. Als Pythonista möchte ich an dieser Stelle insbesondere Python mit Django oder Flask hervorheben, aber auch andere Programmiersprachen bieten professionelle Umgebungen für Websites, sogenannte Web-Frameworks. Ein großes Thema, aber auch das ist nicht im Einzugsgebiet dieses Artikels.

Allen CMS ist gemein, dass die optische Erscheinung in einer für das Framework verständlichen Template-Sprache geliefert werden muss. Da das nicht ganz einfach ist, gibt es für die meisten Systeme eine Reihe von fertigen Templates. Schonmal nach Typo3 Templates gesucht? Typo3 ist ein bekanntes CMS, daher gibt es eine Menge Templates. Aber wenn man den individuellen Charakter seiner Website wahren will, dann muss ein eigenes Layout bzw. grafisches Konzept her. In diesem Punkt ergibt sich eine signifikante Komplikation von dynamischen Websites im Vergleich zu statischen: während man sich bei der Entwicklung des Front-Ends einer statischen Website ganz auf HTML/CSS/JavaScript konzentrieren kann, muss man bei der Entwicklung eines Front-Ends für ein CMS die Eigenheiten seiner Templating-Engine berücksichtigen. Desweiteren sind Website-Templates in der Regel nicht einfach zwischen den Frameworks transferierbar. Das Template für meine WordPress-Website hier ist eine von mir manuell angepasste Version eines quelloffenen WordPress-Templates. Ich bin damit an WordPress gebunden (kann nicht ohne größeren Aufwand auf ein anderes CMS umsteigen) und kann auch nicht “mal eben so” grundlegend etwas an der Optik ändern.

Die wichtigste Botschaft aus dieser Sektion: wenn man komfortabel Inhalte verwalten will, braucht man ein CMS. Ein CMS jedoch bringt unumgänglich eine größere technische Komplexität mit sich. Mit folgenden Konsequenzen muss man rechnen:

• Im Problemfall muss man besondere technische Kompetenzen haben, im Zweifel muss man z. B. die technischen Feinheiten von PHP oder einer MySQL-Datenbank verstehen.
• Will man ein individuelles Front-End entwickeln, muss die Implementierung speziell für die Templating-Engine des CMS erfolgen. Ansonsten ist man auf (modifizierten) Einheitsbrei angewiesen.
• Im besonderen Maße erfordert ein CMS regelmäßige technische Wartung. Hier geht es mindestens um die ordnungsgemäße Datensicherung und Sicherheitsthemen (die Vermeidung von Datenlecks und anderen Sicherheitslücken).

Das Front-End (was der Browser anzeigt — was die Nutzer sehen)

Grundsätzliches: das Front-End einer Website besteht heutzutage im Idealfall nur aus HTML, CSS und manchmal JavaScript (Flash und Silverlight sind nur begrenzt zukunftsfähig). Ich persönlich bewerte die Fähigkeit, eine technisch solide und moderne Website mittels HTML/CSS/JavaScript von Grund auf bauen zu können, als sehr wertvoll. Das einhergehende Verständnis ist von großem Nutzen. Wir interagieren schon jetzt sehr häufig per Browser mit Systemen bzw. Software jeglichen Typs. Der Trend ist klar, der Browser und browser-ähnliche Systeme sind oder werden bald Schnittstelle zu fast Allem in der IT-Welt sein. Wir kommen zu der Einsicht: Browser-Front-End-Technologie ist allgegenwärtig. Wenn Du also technisch versiert bist und motiviert bist, Dein eigenes Front-End zu bauen, dann kann ich Dich nur ermutigen, Du lernst was “für’s Leben”.

Welchen Weg man hier genau wählt, hängt ganz von den eigenen Fähigkeiten ab und ist auch entscheidend von der Frage abhängig, ob man ein CMS einsetzten möchte oder nicht.

Beim Front-End-Eigenbau gilt es immer den richtigen Kompromiss aus Individualität und Wiederverwendbarkeit zu finden. An vielen Ecken sollte man auf keinen Fall das Rad neu erfinden. Diese Ecken muss man kennen und man sollte durch geeignete Recherche die richtige Komponente finden. Das erfordert Erfahrung. In jedem Fall ist man heutzutage auf die Hilfe der Web-Community angewiesen ist, da es durch die große Bandbreite von Endgeräten und Browserversionen eine schiere Menge von Details bei der technischen Implementierung des Front-Ends zu berücksichtigen gilt. Hier darf man sich selbst im Allgemeinen nicht vertrauen, hier muss man auf Standard-Komponenten zurückgreifen. Eine der besten Quellen, die mir in den letzten Jahren an dieser Stelle untergekommen ist, ist initializr.com. Damit ist das technische Grundgerüst für eine moderne HTML5-basierte Website schnell implementiert, ohne zu viele Freiheiten bezüglich des optischen Konzepts zu verlieren.

Was heutzutage wichtiger ist denn je ist eine korrekte Darstellung einer Website auf den etablierten Endgeräten sowie der schonende Umgang mit dem Datenvolumen der Nutzer. Hier sollte man auf etablierte “Best Practices” vertrauen, wie sie durch z. B. initializr zusammengeführt werden. An dieser Stelle sei auch insbesondere Twitter Bootstrap erwähnt, eine solide Basis für so ziemlich jede moderne Website. Baut man ein Front-End mit den Komponenten von Bootstrap oder einer vergleichbaren Sammlung, profitiert man von der wunderbaren Arbeit und dem Kenntnisstand der Open-Source-Community. Gleichzeitig hat man viel Verantwortung und Last abgegeben, denn was ‘die’ schon erprobt haben, muss man nicht selbst noch einmal testen und was ‘die’ implementiert haben, ist vermutlich nahe am Optimum. Wenn man es sich zutraut, ist Kontrolle natürlich angebracht.

Will man einigermaßen effizient von Grund auf ein Front-End für eine statische Website gestalten, empfiehlt sich der Einsatz einer Templating-Engine. Eben habe ich noch behauptet, dass dies ein Nachteil im Zusammenhang mit der Entwicklung eines Front-Ends für CMS sei. Der Nachteil entsteht vor allen Dingen durch die Einarbeitungshürde in eine weitere Programmierumgebung. Für viele ist das Überwinden dieser Hürde den Gewinn nicht wert. Beherrscht man aber bereits eine Programmiersprache wie z. B. Python, dann kann man schnell den Nutzen von Templates erkennen: eine statische Internetpräsenz besteht zumeist aus mehreren Unterkategorien bzw. Unterseiten. Diese Unterseiten sind meist in verschiedenen Dateien definiert, aber besitzen viele Gemeinsamkeiten. Üblich ist, dass sich der Großteil der GUI-Beschreibung (des HTML-Quelltextes) wiederholt. Mit einer Templating-Engine kann man erreichen, dass diese Gemeinsamkeiten nur einmalig (zentralisiert) definiert sind. Das ist ein entscheidender Gewinn für die Entwicklung und Wartbarkeit des Front-Ends. Ich persönlich setze hier ganz auf Python und kreiere statische Websites auf Basis von Jinja2-Templates. Zum finalen Output (eine statische Verzeichnisstruktur mit der vollständigen Menge Quelldateien, die für die Darstellung der Website benötigt werden) gelangt man mittels eines kleinen Kompiliervorgangs.

Die Qual der Wahl: welche Technologie an welcher Stelle?

Front-End und Back-End

Möchte man eine statische Website mit eigenem Front-End bauen und hat man nur wenig Erfahrung mit HTML/CSS/JavaScript, sollte man erstmal ein fertiges Grundgerüst suchen und mittels eines Datei-Editors damit spielen um in Richtung des gewünschten Ergebnisses zu kommen. Ein einfaches Webhosting-Paket inklusive Domain für nicht mehr als 2 Euro im Monat reicht dann aus, um die statische Website der Öffentlichkeit zu präsentieren. Dafür ist in der Regel ein FTP-Upload die einzige Konfrontation mit der Servertechnik.

Weiter oben habe ich beschrieben, dass der Einsatz eines CMS grundsätzlich zu einer größeren technischen Komplexität führt. Dennoch gibt es einsteigerfreundliche Systeme, wie z. B. WordPress. Setzt man WordPress oder ein anderes CMS ein, wird man das eigene Front-End grundsätzlich auf Basis eines existierendes Templates erstellen. Je nach Grad der Modifizierung kann das schnell erledigt sein. Vielleicht bist Du ja sogar schon mit einem Standard-Template zufrieden, nachdem Du ein paar Farben und Bilder ausgetauscht hast? Es gibt für alle CMS viele technisch hochwertige Standardtemplates. Manche funktionieren auch auf dem Handy. Es gibt aber auch viel Schrott. Man muss recherchieren. Wenn Individualität nicht oberste Priorität hat, kann’s direkt mit dem Bloggen losgehen, sobald man ein gutes Fertigtemplate gefunden hat.

Wenn Du bloggen willst, Dir aber die Einrichtung eines CMS auf Basis Deines eigenen Webhosting-Pakets zu aufwendig ist, dann gibt es den eigenen Blog natürlich auch bei Blogging-Diensten wie blogspot oder wordpress.com. Manchmal ist sowas kostenlos und mit hässlicher Werbung finanziert, manchmal verlangen die Dienste aber auch überdimensional viel Geld (es gibt natürlich auch alles dazwischen). Ein Nachteil dieser Dienste ist, dass man bei der Gestaltung der Seite absolut eingeschränkt ist. Du nutzt also das Front-End, was die Dir geben.

Vielleicht magst Du auch in Versuchung kommen, einen der vielen Homepage-Baukästen verschiedener Hosting-Anbieter zu benutzen. Vorteil ist: schnell ist der Hosting-Vertrag abgeschlossen und man kann die eigene Website zusammenklicken. Per Administrations-Website. Alles aus einer Hand. Grundsätzlich ist dagegen wenig einzuwenden, weil es ja “so praktisch” ist. Man muss nur sehr genau aufpassen, welche Nachteile man sich damit einholen kann. Und die können drastisch sein. Derzeit wirbt zum Beispiel 1und1 stark für sein Do-It-Yourself system. Eine klassische ‘statische’ Webseite kann man damit schnell zusammenbauen. Aber Vorsicht, als Blogging-Engine eignet sich dieses Angebot zum Beispiel nicht, dafür fehlen die klassischen Funktionen, die man als Autor von Blogposts benötigt. In der Standardvariante sind die enstehenden Websites nicht für mobile Endgeräte optimiert. Aufgrund der Layout-Vorlagen und des vorgegebenen Bildmaterials ist auch die Individualität der eigenen Seite nicht besonders einfach herzustellen. Das Angebot ist relativ teuer — das Geld wäre vielleicht besser in eine einmalige persönliche Beratung durch einen Experten investiert, der für relativ wenig Geld eine statische Website auf Basis einer quelloffenen Vorlage auf klassischem Wege aufsetzen kann.

Es bleibt anzumerken, dass es Systeme gibt, mit denen man relativ komfortabel statische Webseiten auf Basis einer einfachen Markup-Sprache sowie eines vorgegebenen (oder selbst erstellten) HTML-Templates erstellen kann. Das heißt: Ihr schreibt den Inhalt Eurer Webseite in einer Sprache, die sehr nahe am eigentlichen Text ist und fast nichts mit “Programmieren” zu tun hat. Front-End-Entwicklung könnt Ihr komplett vermeiden. Ein Computerprogramm produziert aus Eurem Geschreibsel die statische Webseite. Die ladet Ihr auf Euren Server hoch. Möchtet Ihr Inhalt hinzufügen, dann macht Ihr das erstmal offline auf Eurem Computer. Es wird dann eine neue Version der Website hochgeladen (in Form statischer Dateien) und schon ist die Website aktualisiert. Weil es auch hier eine Vielzahl von Front-End-Vorlagen gibt, reduziert sich das Ganze zu sehr wenig Aufwand; zu einem überschaubaren und schnellen Vorgehen, das Vielen reichen könnte. Schaut Euch mal jekyllrb an.

Muss man ein CMS wählen, ist individuell abzuwägen. Empfehlungen sind in diesem Bereich auch oft Glaubensfragen. Für den Hausgebrauch landet man am Ende fast immer bei einer PHP/MySQL-basierten Lösung, weil es in diesem Gebiet besonders etablierte Anwendungen gibt. Und etablierte Anwendungen gehen zumeist mit gutem Community-Support sowie kleiner Fehlerrate einher. Mit anderen Worten: die Anwendungen funktionieren und wenn man mal Hilfe braucht, findet man die schnell. Obwohl WordPress bzgl. des technischen Kerns verrufen ist, muss man doch anerkennen, dass es gut funktioniert und inbesondere aus Autorperspektive viele gute Features bietet und einfach(!) zu benutzen ist. Für den eigenen Blog also gut geeignet. Für den etwas professionelleren oder komplexeren Einsatz sind CMS wie Drupal oder Typo3 seit Jahren etabliert.

Kurz anreißen möchte ich den Platform-as-a-Service (PaaS) Bereich. Beherrschst Du eine Programmiersprache wie z. B. Python und hast eine Webanwendung im Sinn, die optisch nicht viel hermachen, aber einfach funktionieren soll? Du kannst programmieren, möchtest Dir aber den ganzen Stress rund um das Aufsetzen einer Datenbank, Webhosting und Skalierbarkeit ersparen? Es gibt Plattformen, auf denen man eigenen Anwendungscode ablegen kann, wie zum Beispiel Google App Engine. Die “Plattform” wird mit Garantie geliefert, Du kannst sie einfach für deinen eigenen Code benutzen. Abgerechnet wird nach gewöhnlichen Verbrauchsmetriken, wie z. B. übertragenes Datenvolumen.

Technologien beim Deployment

Nehmen wir an, Ihr habt eine eigentlich funktionierende Website, egal ob statisch oder dynamisch. Immer, wenn Ihr Eure eigene Seite besucht (einmal am Tag oder zweimal im Monat) funktioniert alles. Aber funktioniert die Website wirklich immer und für Alle gleich gut? Bei normalen Webhosting-Paketen gibt es eine garantierte Uptime von vielleicht 97.5 %. Klingt ja gar nicht so schlecht. Aber das heißt, dass Eure Website für 9 Tage im Jahr nicht erreichbar sein kann, ohne, dass Ihr Euch vertraglich wehren könnt. Normale Webhosting-Pakete bringen auch nicht sonderlich viel Rechenreserven. Die Auslieferung statischer Dateien ist fix — aber die Berechnung einer dynamischen Ressource bei jeder Anfrage kann im Falle von WordPress eine lange halbe Sekunde dauern, wenn das Hosting-Paket zu klein gewählt wurde. Wenn Ihr über diese Punkte nachdenkt, wollt Ihr vielleicht doch größere Ausfallsicherheit. Und eine Seite, die immer schnell ist, unabhängig vom Standort des Besuchers und unter besonderen Umständen — z. B. wenn ein großer Besucheransturm “droht”. Zusätzlich wollt Ihr vielleicht noch praktische Besucherstatistiken mit individueller Auswertung.

All diese Aspekte erfordern Erfahrung und technisches Knowhow. Gut zu wissen: man kann auch mit wenig Geld oder sogar kostenlos viele dieser Dinge erreichen. Ein wunderbarer Dienst in diesem Zusammenhang ist Cloudflare. Es fungiert wie ein Zwischenspeicher vor der eigenen Infrastruktur. Besucher landen primär bei diesem Zwischenspeicher, ausfallsicher verteilt über alle Regionen der Erde. Ist der eigene Webserver mal nicht erreichbar oder einfach nur langsam, weil man ein billiges Hosting-Paket gewählt hat, bekommen die Nutzer das nicht so schnell mit. Das funktioniert natürlich nur bei begrenzt dynamischen Websites. Mein Blog ist ein gutes Beispiel dafür. Im Mittel kommt alle paar Wochen ein neuer Artikel hinzu — der Nutzer merkt also nicht, wenn der Inhalt von einem Zwischenspeicher ausgeliefert wurde. In diesem Fall ist ein billiges Hostingpaket plus ausfallsicherem Zwischenspeicher eine sehr effiziente Lösung.

Optimieren kann man an jeder Stelle im sogenannten “Webstack” (bezeichnet die hintereinander geschalteten Komponenten der Back-End-Infrastruktur). Braucht die Website gute Performance und hat man viele Besucher, wird am ehesten von Apache als direkter Anschlussstelle an “das Internet” Abstand genommen. Ein richtig schneller Webserver oder sogar eine Lastverteilung muss her, nginx oder HAProxy kommen zum Einsatz. Insbesondere im kommerziellen Bereich muss man gewisse Sicherheitsanforderungen erfüllen. Es kommt die Frage auf, welcher Teil der Website verschlüsselt werden muss. Man muss entscheiden, welche Komponente der Infrastruktur die TLS-Verschlüsselung terminiert und wie viel Vertrauen in das Rechenzentrum gerechtfertigt ist.

Neben Optimierung ist Überwachung bzw. “Monitoring” ein entscheidendes Merkmal einer professionell eingesetzten Internetseite. Richtige Entscheidungen können nur getroffen werden, wenn die Qualität/Erreichbarkeit/Performance eines Internetauftritts quantifizierbar ist. Das setzt ein Messsystem voraus. Je nach Internetpräsenz muss das ein individuell zugeschnittenes Messsystem sein. Es gibt aber auch viele praktische kostenlose Dienste, die die Standardaufgaben — wie z. B. den regelmäßigen Erreichbarkeitstest einer Ressource aus verschiedenen Teilen des Globus — kostenlos durchführen. An dieser Stelle möchte ich gerne Pingdom empfehlen. Da gibt’s sofort eine E-Mail, wenn mal was nicht stimmt. Statistiken über z. B. Latenzzeiten werden grafisch ansprechend aufbereitet.

Allgemein gesagt kann und sollte man dem Webstack viel technische Liebe zukommen lassen, sobald die Webseite mehr Bedeutung hat als nur die Belustigung der Freunde. Nur wer sich in diesem Bereich gut auskennt, erkennt potentielle Flaschenhälse und gemeine Fallen, die zumeist erst zu Tage treten, wenn es schon zu spät ist. Die klassischen Probleme sind hier entweder durch Besucherandrang verursacht oder sicherheitstechnischer Natur. Natürlich gilt: Besser eine Website, die “nur” 98 % der Zeit erreichbar ist als gar keine Website. Aber auch bei einer kleinen, rein informativ gehaltenen Website sollte man sich in diesem Punkt Gedanken machen und vielleicht mal einen Experten zum Grundgerüst befragen.

Fazit

Angeschnitten wurden nur wenige Bereiche und doch erkennt man, dass die Bandbreite der Technologien, die rund um eine Internetpräsenz zum Einsatz kommen, sehr groß ist. Nicht diskutiert wurden die Feinheiten von Hosting-Verträgen und Domains, die Wahl der richtigen Hardware, Suchmaschinenoptimierung, Sinnhaftigkeit von Besucherstatistiken, die Details und Notwendigkeit von Wartungsarbeiten und vieles mehr. Es gibt also Einiges, was mit einem Experten besprochen werden sollte.

Aber auch Eigenbau ist mit simplen Methoden möglich, hier habe ich hoffentlich ein paar Anreize geben können. Gerne beantworte ich Fragen in den Kommentaren.