通過CGI來實現，這個就好比之前perl的CGI，該種方式的缺點是性能差，因為每次服務器遇到這些腳本都需要重新啟動腳本解析器來執行腳本然後將結果返回給服務器，另壹方面就是不太安全，該方面幾乎很少使用了。
最新出現壹種叫做FastCGI。所謂FastCGI就是對CGI的改進。它壹般采用C/S結構，壹般腳本處理器會啟動壹個或者多個daemon進程，每次HTTP Server遇到腳本的時候，直接交付給FastCGI的進程來執行，然後將得到的結果(通常為html)返回給瀏覽器。
FastCGI這種方法的問題存在壹個小問題是當遇到大流量的頻繁請求的話，腳本處理器的daemon進程可能會超負荷從而變得很慢，甚至發生內存泄漏。但是比較起Apache的內置模塊的方式的優點是由於Server和腳本解析器完全分開各負其責，因此服務器不再臃腫，可以專心地進行靜態文件響應或者將動態腳本解析器的結果返回給用戶客戶端。所以比較起Apache的內置模塊方式，有時候性能要提高很多。有人測試可能會達到Apache+mod_php的5~10倍。
使用FastCGI方式現在常見的有兩種stack：
ligthttpd+spawn-fcgi
nginx+PHP-FPM(也可以用spawn-fcgi)?0?2
如上面所說該兩種結構都采用FastCGI對PHP支持，因此HTTP Server完全解放出來，可以更好地進行響應和並發處理。因此lighttpd和nginx都有small, but powerful和efficient的美譽。
該兩者還可以分出壹個好壞來，spawn-fcgi由於是lighttpd的壹部分，因此安裝了lighttpd壹般就會使用spawn-fcgi對php支持，但是目前有用戶說ligttpd的spwan-fcgi在高並發訪問的時候，會出現上面說的內存泄漏甚至自動重啟fastcgi。即：PHP腳本處理器當機，這個時候如果用戶訪問的話，可能就會出現白頁(即PHP不能被解析或者出錯)。
Nginx不像lighttpd本身含帶了fastcgi(spawn-fcgi)，因此它完全是輕量級的，必須借助第三方的FastCGI處理器才可以對PHP進行解析，因此其實這樣看來nginx是非常靈活的，它可以和任何第三方提供解析的處理器實現連接從而實現對PHP的解析(在nginx.conf中很容易設置)。
nginx可以使用spwan-fcgi（需要壹同安裝lighttpd，但是需要為nginx避開端口，壹些較早的blog有這方面安裝的教程），但是由於spawn-fcgi具有上面所述的用戶逐漸發現的缺陷，現在慢慢減少使用nginx+spawn-fcgi組合了。
由於spawn-fcgi的缺陷，現在出現了新的第三方（目前還是，聽說正在努力不久將來加入到PHP core中）的PHP的FastCGI處理器，叫做PHP-FPM（具體可以google）。它和spawn-fcgi比較起來有如下優點：
由於它是作為PHP的patch補丁來開發的，安裝的時候需要和php源碼壹起編譯，也就是說編譯到php core中了，因此在性能方面要優秀壹些。同時它在處理高並發方面也優於spawn-fcgi，至少不會自動重啟fastcgi處理器。具體采用的算法和設計可以google了解。
因此，如上所說由於nginx的輕量和靈活性，因此目前性能優越，越來越多人逐漸使用這個組合：nginx+PHP/PHP-FPM?0?2。