It’s nice that at least you’re moving your site to mobile device. It’s really important. Now if you’re using PHP the question is how to detect the mobile browser.

HTTP_USER_AGENT

Every PHP developer knows that $_SERVER[‘HTTP_USER_AGENT’] string optionally contain the browser that access your site, but what are the possible values of this string?

The Answer is …

in that really really full list of user agent strings: http://www.zytrax.com/tech/web/mobile_ids.html

media=print

this, lovely, browser stops the rendering until the sheet is loaded. This is pretty strange when it comes to such media, just because it is not used to render the page in a browser. In fact as Steve Souders says the normal behavior of the browser should be don’t block or even delay the sheets for media that is not the current one.

However for further reading see this post with many thanks to Steve Souders again.

As I wrote recently there is a way to do this in IE with the use of VML, but yet again this is not working on Opera, and puts another chunk of markup in your document, that leads to more difficult maintain.

The solution can be done with another approach that can be considered as one level beyond the VML usage. Thus you have scripts only in IE and clean CSS.

Everybody now’s using both:

-moz-border-radius
-webkit-border-radius

and now’s coming the new wave with:

border-radius

property in CSS3, but as we know it will be maybe present in IE9 and any older MSIE will be discarded.

What the .htc means?

It stands for HTML components file, which is completely JavaScript code that’s included via CSS as:

behavior: url(border-radus.htc);

Of course you can find such .htc predefined files everywhere on the web and it’s completely working.

The problem

is that sometimes after using many HTML tags with border radius IE appears to crash, which is nothing new, but however not desirable.

Yes that’s the reality and when they become more and more bigger the web pages becomes to be irresponsible. The bitter reality is that you load any functionality that slows down the first user impression, but is needed only when you click on a button and so on. That’s a problem because you can load only that chunks you need in the beginning and than after a few seconds to load everything else. Some web applications have more than 100K of javascript which become really bad.

Separate logic

What you can do is to separate the logic into one or more files. Even when the user thinks everything is on the page and he can interact with the application and than to start to load the rest of the functionality.

That’s a pretty good technique. Nobody can start interacting on the 5th second of the load process. Usually the user looks at the interface starts to explore the app and after approximately the 10th second he start interacting with the page.

Lazy loading

There are various techniques of loading JavaScript on demand. So I wont cover it, but that pattern of loading it latter when needed is really powerful.

Why?

Maybe because nobody things that the HTML source of a page can be optimized or the optimization of it cannot bring some benefit to the page load experience. I don’t thing so. If something can be optimized, even if this does not give you so much, why you shouldn’t do it?

How to optimize such thing as HTML?

Well there are few things you should do and other that can speed up a little bit but you should not.

1. Enable gzip

What is gzip? Well in breve everything the server generates is sent back to the client in text format. You’ve to possibilities to send it. Either compressed or uncompressed. As you may guess the compressed format is a lot faster than uncompressed. In fact to make it work that way you’d need to enable gzip which is supported by the web server. In the case of Apache web server this can be done by enabling mod_deflate. Take a look of mod_deflated and mod_inflate. This two modules gives you the possibility to make your site a lot faster and the good news is that this is done without a single line change. The bad news, as always there’s a bad news, is that sometimes this cannot help a visitor, simply because his browser doesn’t support such corresponding with the server. According to a research I’ve read recently almost 15% of the web browsers doesn’t support gzip. Sometimes the reason is old browser versions, sometimes because the state policy doesn’t allow it. However this is the first thing you should do to speed up your HTML even it is not related directly to HTML scripts. By the way this will speed up everything which is sent back to the client, especially CSS and JavaScript files and in the case of JavaScript this can improve dramatically the user experience.

2. Use div elements instead of tables when possible.

This is the second thing you can do to speed up your site. The simple reason to do that is because the DIV element doesn’t need so much markup as a TABLE element. When widely used in a page – imaging thousands of tables this can be a disaster. Remember the first thing is to make the text you send to the server as small as possible. In that point I should say that not only the tables to div switch is enough. Always prefer smaller tags and constructions. This is a bit difficult. Some experienced web developers can construct the same page with less HTML markup than newbies, but that depends of your level of experience.

3. Make it ugly – just to spend some space.

Your code is beautifully organized and when viewing the source everyone is excited! That was a mistake I used to make in my early projects. Why we thing somebody will take a look of the source code? Why we thing somebody’s using view-source option? Because we’re sick minded web developers. Nobody cares about your well organized source code. Normal users don’t look at it! Forget about beauty! As you may remember – you should spend all the extra spaces you send to the browser. Well if well organized the source code is full of tabulations, new lines and spaces. This is not good! Well if gzip is enabled they may be spent to the client, but if not? Stop writing beautiful HTML. The first task is to make it readable and maintainable.

4. Don’t use inline styling

This cannot be cached by the browser, is difficult to maintain and is – ugly! Yeah don’t use inline styles it makes your markup larger, which yet again is bad and is difficult to maintain. Write everything in CSS files, include them from the outside and setup only the classes you need.

5. Make it maintainable

Although its important to make the HTML as small as possible, sometimes that means to make it as ugly as possible and that brings the enemy number one – unmaintainable code. After a while the change of that code is technically impossible. So use all these techniques with something in mind – make it maintainable even if that will sacrifice some optimization benefits.