Man startet eine Webanwendung, indem man z. B. im Browser die URL des Webservers eingibt und damit eine Anfrage (HTTP-Request) sendet. Der Webserver nimmt die Anfrage entgegen und übergibt sie an die Webanwendung. Dieses erzeugt oder lädt den HTML-Quellcode einer Webseite, welche vom Webserver zurück zum Browser des Benutzers geschickt wird (HTTP-Response). Diese Webseite ist die grafische Benutzeroberfläche der Webanwendung. Betrachtet man die Schichtenarchitektur einer Webanwendung, wird die Präsentationsschicht im Webbrowser ausgeführt (Thin Client). Teile der Logikschicht und Datenhaltung werden serverseitig ausgeführt. Durch Anklicken eines Hyperlinks auf dieser Webseite oder Ausfüllen und Absenden eines Formulars startet man eine erneute Anfrage an den Webserver. Hierbei werden typischerweise weitere Informationen, wie z. B. die in dem Formular getätigten Eingaben (HTTP POST), die Parameter des Links (HTTP GET) und die Daten eines HTTP-Cookie an den Webserver übermittelt und als Eingabe durch die Webanwendung verarbeitet. Über Schnittstellen wie z. B. das Common Gateway Interface oder FastCGI wird die Webanwendung innerhalb des Webservers eingebunden. Auf diese Weise werden Anfragen an die Webanwendung weitergeleitet und die Ausgaben der Webanwendung als Antwort zurückgesendet. Die Abarbeitung eines solchen HTTP-Requests durch die Webanwendung nennt man auch Request Cycle. Bei der Benutzung von Web-Apps werden Sessiondaten (z. B. Bestelldaten eines Webshops) serverseitig in Datenbanken oder Dateien gespeichert. Benutzerbezogene Daten können auch clientseitig durch HTTP-Cookies gespeichert werden. Serverseitige Sitzungsinformationen verbrauchen – je aktive Benutzersitzung – Serverressourcen. Ebenfalls erschweren serverseitige Sitzungsinformationen eine horizontale Skalierung der Webanwendungen. Alternative Architekturansätze für Webanwendungen wie Single-page-Webanwendungen oder das REST-Paradigma kombinieren daher die serverseitige mit der clientseitigen Ausführung.