HTML and CSS Reference
In-Depth Information
In PHP, the code would be:
<?
php
//Load the Mobile Detection library
include
(
"code/mdetect.php"
);
//In this simple example, we'll store the alternate home page
// file names.
$iphoneTierHomePage
=
'index-tier-iphone.htm'
;
//Instantiate the object to do our testing with.
$uagent_obj
=
new
uagent_info
();
//In this simple example, we simply re-route depending on
// which type of device it is.
//Before we can call the function, we have to define it.
function
AutoRedirectToProperHomePage
()
{
global
$uagent_obj
,
$iphoneTierHomePage
,
$genericMobileDeviceHomePage
,
$desktopHomePage
;
if
(
$uagent_obj
->
isTierIphone
==
$uagent_obj
->
true
)
//Perform redirect
}
So there you have it,
userAgent
detection is unreliable and should be used with caution
or for specific cases only. Even in the scenario descripted by the Android/Firefox bug
report, for example, you could still implement
userAgent
detection and then use feature
detection to find the maximum screen size for Android-based mobile phones using CSS
Media Queries. There's always a workaround, and problems such as these should not
deter you from using the
userAgent
string.
Compression
Compression of resources is mandatory in today's mobile-first priority. If you aren't
concerned with the size of your HTML, JavaScript, and CSS files, you should be. HTTP
compression is used to achieve a minimal transfer of bytes over a given web-based
connection. This reduces response times by reducing the size of the HTTP response.
The two commonly used HTTP compression schemes on the Web today are DEFLATE
and GZIP (more on these coming up).
When you gain performance on the client side, however, it's easy to forget about in‐
creased overhead on your server resources. If you have complex SQL queries that in‐
crease the CPU load to present certain pages, you should analyze the effects of using
HTTP compression when these scenarios occur. Compressing a huge page that sur‐
