Faster Form Submission and Processing with fsockopen
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.
« Removing Category Base from WordPress URLsSpeed Tips: Add Cache-Control Headers »
Comments