Currently I’m working on a site that is expected to work fine on iPhone devices. Obviously I knew that I had to dig up meta tags for iPhone site for Safari on the iPhone devices.

Found this and here are the list of it:

• <meta name=”apple-mobile-web-app-capable” content=”yes”> : sets whether a web application runs in full-screen mode. (refer to the documentation for the potential values)
• <meta name=”apple-mobile-web-app-status-bar-style” content=”black”> : Sets the style of the status bar for a web application. (refer to the documentation for the potential values)
• <meta name=”format-detection” content=”telephone=no”> : Enables or disables automatic detection of possible phone numbers in a webpage in Safari on iOS.
• <meta name = “viewport” content = “width = 320,
  initial-scale = 2.3, user-scalable = no”> : Changes the logical window size used when displaying a page on iOS.

Mostly I was using viewport.

This is old blog post by Peter Van Dijck, which he posted presentation materials regarding site performance and scalability, but it is still very good resource.

Check it out.

It’s a very good read.

As he pointed out in his blog post, I think for some reasons many people seem to believe in HTML5 video without knowing the fact that there is *no standard in the video codec* yet.

We all know that Apple is pursuing H.264 for video codec as a standard, but there is still possibility not all browser vendors agree to use one video codec in the next several years for whatever reasons. Also there will be always newer codec that replaces H.264 and what will happen to the unofficial video codec standard?

As for the video player itself, video tag provides limited feature set whileas Flash player can have rich feature sets. In order to add new features to the video player (video tag), browser has to be upgraded whileas Flash author can upgrade the feature sets more freely.

I just feel that web is still messy and will be as it was as developers worked to fix compatibility issues between IE and Netscape. Now it’s another form of incompatibility issue.

i searched about html5 mobile support and found this great post.

Things that I thought about were while reading the post:

1. HTML5 features for the mobile site may accelerate adaption of better mobile browser to mobile devices. For those who do not have the latest phone, sorry, but you might have more choices soon?
2. it’s not directly related to this html5 mobile support post, but voice lines may be dead soon. Instead, it will be all about data plan as voice call can be made through app. Which may trigger mobile device companies such as motorola or samsung to adapt full browsing experience for all their devices *faster*. More html5 enabled borwser penetration rate follows? who knows.
3. mobile web application doesn’t necessarily have to be complex application. Even with a simple site, using html5 new APIs, site can fully utilize all the awesome features (geolocation, etc)
4. HTML5 applications are mainly for iPhone, Android, and Palm Web OS devices. Nothing else.

I checked html 5 form spec at w3.org website and found quite interesting form types. Those are:

• search
• tel
• url
• datetime
• date
• month
• week
• time
• datetime-local
• number
• range
• color

As you can see there are so many types in HTML 5 specs. And validation for the specific data type MUST be done on the browser side according to the w3.org doc. So FE engineers do not have to implement own validation for the form fields any more.

However, even if client side validation is done by the browser, server-side data validation MUST be accompanied. Using javascript, hackers can change the type attribute anyway they want and bypass client validation by setting them to “TEXT”.

There are also some new attributes introduced in the HTML 5 spec. Those are:

• autocomplete
• pattern
• placeholder
• valueAsDate
• valueAsNumber
• list

I often use String.replace in JavaScript whenever I have to use JavaScript. Today was the day that I ended up with using it for my work. I know that String.replace supports regular expression to match your string, but I was not clear if I could use “capturing groups” and “quantifiers”. As I guessed, I was able to use quantifiers in the replace string like the sample below:

    var link_template = '<ol>\
        <li><label>Link 1 Title:</label><input class="text" id="relLink1title" name="relLink{1}title" value="" /></li>\
        <li><label>Link 1 URL:</label><input class="text" id="relLink1url" name="relLink{1}url" value="" /></li>\
        <li><label>Link 1 Img URL:</label><input class="text" id="rellink1imgurl" name="rellink{1}imgurl" value="" /></li>\
        <li class="btn"><span><a href="#" class="new-related-link">Add a New Link</a> | <a href="#" class="remove-related-link">Remove</a></span></li>\
        </ol>';
 
    link_template = link_template.replace(/(<label>.*?)(\d)(.*?<\/label>)/im, '$1 2 $2');

1. Introduction

Why is the site performance so important? The poor site performance impacts company’s revenue and user’s engagement.

• Shopzila: 5 seconds speed up resulted in a 25% increase in page views, 10% increase in revenue, a 50% reduction in hardware, and a 120% increase traffic from Google.
• Amazon: every 100ms of latency cost them 1% in sales
• google: extra .5 seconds in search page generation time dropped traffic by 20%
• a broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition.
• facebook: regardless of site speed, users spend around the same amount of time on facebook, which means if the site is running slowly users are going to be seeing fewer pages in the same amount of time.

So the conclusion is that fast site is better.

2. Site performance is Latency experienced by users

It’s measured from a guest request to the presentation of the page at the browser. There are many factors that contribute to the site performance. Facebook has defined 3 factors and those are:

• network transfer time – time from the user’s browser to the server.
• server generation time – time spent on the server
• client render time – time the browser spends on parsing the HTML, loading JavaScript/css/images and rendering contents.

80-90% of the end-user response time is spent on the frontend according to Todd hoff. Therefore, it is a logical decision that it is better to focus on the frontend before jumping into other areas for the site performance.

(Site benchmark is also important, When the site cannot serve as many guests as it should, FE optimization won’t matter.)

3. Page Speed & YSlow Tips

We have heard about them so many times already and are well aware of those tips. However, few tips from Page speed are worthy to look at.

3.1 Optimize the order of styles and scripts

Many browsers block the downloading of resources referenced in the document after scripts until those scripts are downloaded and executed. On the other hand, if other files are already in the process of being downloaded when a JS file is referenced, the JS file is downloaded in parallel with them

The recommendations from google Page Speed are :

1. Put external scripts after external stylesheets if possible
2. Put inline scripts after other resources if possible.

For more details, go to the source link specified in the section.

Source: http://code.google.com/speed/page-speed/docs/rtt.html#PutStylesBeforeScripts

3.2 Defer Loading of JavaScript

Deferring loading of JavaScript functions that are not called at startup reduces the initial download size, allowing other resources to be downloaded in parallel, and speeding up execution and rendering time.

Source: http://code.google.com/speed/page-speed/docs/payload.html#DeferLoadingJS

Defer loading of JavaScript has been one of my focuses for the site performance in fact.

4. Focus on the viewable area

[diagram here]

It’s recommended to focus on the portion of the page that guests see first as they come to the site. This concept is very similar to the news feed on the facebook home page. 15 stories are loaded at first as the initial load. After that, additional 15 stories appear as user scrolls down.

What Yang found, however, is that when people do scroll beyond the initial 15 stories they’re shown, they’re happy to wait the extra second or two for 30 new stories to load, which results in a significant boost in engagement.

5. Deferload everything if possible

According to the research done by clicktale blog :

• between 64% to 68% of the page views are likely to reach the 1k pixel line and 15% to 20% will reach the bottom of the page.
• Below 540 pixels, both visitor attention and page exposure decline exponentially.
• The most valuable web page real-estate is located near the page top, between 0 and 800 pixels. Visitor attention and page exposure peak at about the 540 pixel-line.

That could translate into this: the page components below the viewport are not likely to be downloaded for 32% to 36% of users if the defer loading technique were implemented. If the entire page’s file size were 200KB and then file size of the page components (mainly images and flash media file) out of viewport were 50KB, our target size for the initial load would be 150KB (potentially 33% less download for users). Although there might be guests that scroll down to all the way bottom, there are guests that click away from the first screen.

Source: http://blog.clicktale.com/2007/10/05/clicktale-scrolling-research-report-v20-part-1-visibility-and-scroll-reach/ & http://blog.clicktale.com/2007/12/04/clicktale-scrolling-research-report-v20-part-2-visitor-attention-and-web-page-exposure/

References

• http://www.slideshare.net/gemstonesystems/true-cost-of-latency
• http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it
• http://www.techcrunch.com/2009/08/30/a-look-behind-the-curtain-at-facebooks-optimization-efforts/
• http://code.google.com/speed/page-speed/docs/rtt.html
• http://en.oreilly.com/velocity2009/public/schedule/detail/7611

- More To Come -

This is to bookmark to an article on how to debug JS in Internet Explorer.

Check out how

I came crossed geolocation feature that was introduced in Firefox 3.5. That is very neat functionality that marketings will love for targeted ads. And also for web developer/engineers, it’s something that we can customize the web content based on the users’ location.

It used to require somewhat complex process to get (not technology side tho) the information.

Anyways, in this link you get to see how to access the core API for.

And then here’s the properties of position object:

• QueryInterface
• coords : xpconnect wrapped
• timestamp
• getInterfaces
• getHelperForLanguage
• contractID
• classDescription : wifi geo location position object
• classID
• implementationLanguage
• flags : 8
• SINGLETON : 1
• THREADSAFE : 2
• MAIN_THREAD_ONLY : 4
• DOM_OBJECT : 8
• PLUGIN_OBJECT : 16
• EAGER_CLASSINFO : 32
• CONTENT_NODE : 64
• RESERVED

And interestingly position.coords has some unique properties:

• QueryInterface
• latitude
• longitude
• altitude
• accuracy
• altitudeAccuracy
• heading
• speed

As you can see it has speed property. So in theory, with the available properties you can make GPS system on the web.

As the number of users grow, is it necessary to increase the number of servers? Well. The answer to the question really depends. Some might say to buy more hardware to support increasing visits. Some might say before buying more hardware, tune up your software by optimizing the code and squeeze any power out of the box. But in this post, I’m not going to discuss software tune ups.

I’m going to talk about cache technologies.

cache layer
I’d like to start with the concept of proxy layer. What proxy layer provides is a memory storage between frontend(FE) layer and API layer. So that the actual requests made from users do not overload API server; thus, the site performs much better. Proxy server would store returned XML data from API and when the same API request was made from FE, proxy would return the same data stored in the memory to FE removing extra calls to API. Frontend layer is a typical HTTP server while API layer is a data layer. Usually this technique is used in multi tier architecture. This is usual 3 tier architecture.

DB -> API -> FE

When we introduce proxy layer to it, 3 tier architecture becomes this:

DB -> API -> Proxy -> FE

As you can see, the major advantages of Proxy layer are:

1. It is very fast since it accesses memory instead of hard disc
2. It reduces overhead to one layer dramatically
3. It delivers content really quickly
4. It improves response time(better roundtrip numbers)
5. It provides better usability to users as content is delivered a lot faster
6. It can hold old data for specified time in case database blows

It just has all good things.

Commonly used cache technology for the cache layer is squid cache. If your organization’s web site is getting popular and needs performance tune up, it may be a good idea to invest some time and money to implement cache layer.

As I covered cache layer, let’s move to view level cache.

View Level Cache
View Level Cache is a cache technique to store your HTML markup output into memory or harddisc. This could be a whole markup for the page, markup for a partial page, or markup for several parts of the page. As the term implies the view level cache occurs on the frontend layer. Also there is another term, Module Level Cache referring to View Level Cache. For example, in my blog there are several sections in the page. Those are links, archives, and so on. Each section is a module and the final markup of those modules can be cached for 5 mins to how many minutes you like.

What’s so good about View Level Cache(Module Level Cache)
As I explained in the previous paragraph, it stores the final markup of a module. Which means you can reduce cpu load, which would have used to generate that module for the time you specified. That means also it does not have to make several requests to database like MySQL. So when your site got hit by dig users or reditt users, View Level Cache would’ve helped to ease heavy traffic much.

View Level Cache technologies
If you are using php, the common technology for the view level cache is APC. The usage of APC is relatively easy. In php, another technique you can use is a file cache. And heavy traffic’ed sites also use memcached, which is a distributed memory object caching system. I am not going to show how to use each technology in this post as each topic deserves its own post.

Do not cache all by accident
When you apply cache layer to your Frontend, be warned that caching all content is bad usually, specially if your site is dynamic. You do not want to cache user A’s name and display it when user B, C, and D visits your site. Also if one of your pages needs user specific data in a form tag with hidden input field and somewhat you caches it, the next visitor to your site will use the same data from the previous visitor, which is bad. See where I am going with this? So it will be nice if you can communicate with visual designer so that she can visually distinguish what can be cached and what not.

Results out of cache
The site that has implemented cache technique well could support 200 to 300 hits per second. That translates to 12000 to 18000 hits per second. I know this from my experience. You do not need a lot of servers to support 200 hits/sec site. All you need is one FE box if your site has 200 hits/sec.