Multi pass rendering

Web application performance is an extremely important metric to take into account when picking tooling and techniques. Certain decisions should be made during the planning phase of an application to ensure that decisions are conscious of the problems they are trying to solve, keeping in mind the simplicity and maintainability of the source code.

Multi-pass rendering is a technique that provides developers three main benefits:

1. Develop web applications with the ease and familiarity of writing PHP, using a typical request-response lifecycle.
2. Introduction of techniques in a layered approach built on top of a tried and tested web model, as to not introduce multiple points of failure.
3. Obtain the fastest possible time to first byte - a dynamic PHP application can serve pages just as fast as a static site can when using multi-pass rendering.

"What are we trying to achieve, and why?" Asking these two questions at the start of a project provides us with all of the solutions that are required in any technical system. However, failing to ask them will lead to the implementation of many irreversible choices.

Without introducing any special techniques, PHP applications produce web pages by performing all calculations to produce the page's content before rendering any response to the browser. This introduces a slight delay on the rendering of the web page. In fact, as soon as any server-side language such as PHP is used to output a page, we slightly delay the output of the page, even when the page's content doesn't often change.

Introducing multi-pass rendering to our application, along with a few webserver tricks, can produce applications with unparalleled response times. In this section, we'll discuss the considerations we need to make at the start of an application's technical design, and follow through to show a fully working, non-trivial example application that can be used as a reference point for producing your own applications, or directly comparing other performance techniques.

---

Breaking down the request-response lifecycle

// Important to respect the web stack we are building on. Extra important to get working code before introducing new concepts. Must be able to build applications using standard PHP, adding the techniques after a fully-tested application is delivered.

// Determine data's state. URLs are used as the entry point to each state of an application. From one URL, it should be clear what elements of the response require dynamic content.

// Static templates. WebEngine promotes this static-first approach.

// Break out dynamic logic into separate functions from "go" entrypoint.

// Test!

// In PHP, do not render dynamic logic without multi-pass rendering (X-MPR) header present. This leaves static pages untouched.

// Configure web server to serve pages statically. Use JavaScript to call page dynamically with MPR header.

// Add loading indicators only after threshold of time is hit. Perception to user is instant loading. Perception to browser is close-to-zero time-to-first-byte.

// Introduce CDN, ignore MPR header.

// Introduce SPA, ignore MPR header.

Live example

// TODO.