Here are our top six tips for making sure that your mobile optimised website understands that a mobile is visiting any given page of your website.
These rules should apply whether you are using Responsive Web Design
(RWD) or other methods of optimisation:
- Create and maintain a list of a handful of (say 50 at most) desktop user
agents hardcoded into the web server software (e.g. IIS, Apache) or in the code of
the API; this ensures low latency for the majority of sessions.
- if the UAProf contains "iPhone" then you can set up a rule that re-directs the visitor to the m. version of your website without needing to call the API.
- if it is not one of these main desktop UAProfs then implement a call to your API.
If the response to IsMobile is
positive, then re-direct the visitor to the m. version of your website, otherwise serve the desktop site.
- ensure you set your time-out low - giving you the time to receive a response from the server when the mobile networks might be busy and/or slow. (As a default, ensure that you at least serve the desktop site
if no response from the API is received after the time limit you have set: better a pinch and zoom experience than a blank page?).
- only call the API at the beginning of a session (whichever page the site visitor starts on - the check should apply to visits initiated from a deep-link as much as to those who start with your Home page), not on
every page. i.e. if the UAProf does not change then you do not need to re-check as this is a
waste of resources and adds to delays in serving pages, and thus to possible site visitor frustration.
- do not call the API if we send the user back to you i.e.
they override the mobile site and click on the 'view desktop' link (we add 's=[xxxxxxx]' to the query string, which if encountered instructs the site not to call the API). DO make sure the user can return to the mobile site at any stage* (desktop site should have a "view mobile site" link as much as the m. site should have a "view desktop site" link).
It is worth re-iterating, that latency is a big issue for mobile website visitors. Mobile networks can be clogged and slow, even if in theory they have the latest network technology (4 or even 5G).
If you build your site assuming a good experience in the worst possible network conditions, you will always deliver a good customer experience.
Our view is to aim for no more than 30 seconds load time in GPRS conditions (which translates to approximately < 100kb page sizes).
A final point about cookies
In our view, there is no need to save the mobile site preference in a cookie on the
device. Cookies are now so highly regulated (you need to store and record the cookie and what it means on your website etc) and they are now so easy to switch off, that it is quicker, easier (and more accurate) to implement an API call at the beginning of every session.
* I know of a site that, because of a cookie, loaded up the desktop site on my mobile device every time I visited purely because the last time I had been on the mobile site, I overrode the re-direct in order to see one particular piece of information that was only available on the desktop site (don't do that
, by the way!). From then on, the site assumed I wanted to visit the desktop site each time. And without a simple mobile site override link, it was a difficult trick to get back to the optimised site.