This is part II of Faster POST and GET Form Submissions, illustrating a few simple methods of speeding up POST and GET form submissions and form processing by utilizing background requests with fsockopen.

Background Requests with PHP

Instead of sending the form results to thanks.php and having thanks.php both process the form and display the post-processing response (like a thank you message), instead have thanks.php forward the form results to background.php while simultaneously displaying the thank you message.

Background Request example with fsockopen

So the form is on the page survey.php, and the action of the form is set to thanks.php, and the background request is made to background.php

survey.php - the survey form

This displays the survey form and sends the results via an HTTP POST to /thanks.php

thanks.php - the response / forwarder

This file receives the text1 value and displays a thank you message, at the same time it fires off an HTTP GET request to /background.php with text1 added as a GET variable.

Note: I am using HTTP/1.0 protocol which is faster than HTTP/1.1 for various reasons you can read about elsewhere on AskApache.

Thanks ! 

background.php - server-side form processing

This file is requested by the server, and run on the server, receiving/sending nothing to the client, which is just fantastic. Where the // processing on text1 is located is where you can run code that would normally slow down your client.

• Sending an email with the results using phpmailer, sendmail, swiftmailer, etc.
• Add or modify a mysql database record using the $text1 value
• Run any other server-side script, maybe anti-virus or anti-spam

Stay tuned for part III, where I will show some advanced methods like setting up a fsockopen-based POST variable forwarder, POST to SESSION conversion, implementing gzip compression and base64 encoding to obfuscate/speed up variable passing in HTTP requests, and using cURL / libcurl instead of fsockopen. I might also touch on pfsockopen for persistant socket-based connections. Probably will be published at the end of March, I'm going on vacation!

Use GET for AJAX Requests

The Yahoo! Mail team found that when using XMLHttpRequest, POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. So it's best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.

An interesting side affect is that POST without actually posting any data behaves like GET. Based on the HTTP specs, GET is meant for retrieving information, so it makes sense (semantically) to use GET when you're only requesting data, as opposed to sending data to be stored server-side.

Post-load Components

You can take a closer look at your page and ask yourself: "What's absolutely required in order to render the page initially?". The rest of the content and components can wait.

It's good when the performance goals are inline with other web development best practices. In this case, the idea of progressive enhancement tells us that JavaScript, when supported, can improve the user experience but you have to make sure the page works even without JavaScript. So after you've made sure the page works fine, you can enhance it with some post-loaded scripts that give you more bells and whistles such as drag and drop and animations.