Back in the day, when I first started building web sites, controlling file sizes and download times were a critical part of the process. This was in the days of dialup. For those of you who grew up in a broadband world you have no idea how unimaginably slow some sites would render. Back then, it was important that image tags specified height and width of images so they could act as placeholders. This allowed the text of the page to download on the visitor’s screen in the right place so they could at least read the text while the images downloaded. And those images had better be small, or else. I remember chiding many clients for trying to put 1MB PDFs or 100K images on their sites.

Today, we take broadband for granted. Download speeds are so fast, that the occasional multi-megabyte PDF doesn’t faze most people. Some of us (yes, including me) have gotten a little lazy when it comes to optimizing images and other files for size. Some of our code is bloated and filled with redundancies. Still, for many of our customers, these things don’t really matter. Or do they?

Ah, But It Does Matter
There are two main reasons why download time really does matter: Consider mobile and SEO.

Mobile Browsing
It’s a given that mobile browsing is becoming a larger and larger share of overall internet usage, and that share will continue to grow as time goes on. Think about your customers using their mobile device to visit your site. If they are running on a 3G connection, depending on their provider they can download at speeds from 350 kilobits to 1.7 megabits per second. Those speeds are under optimal conditions and can be/are often slowed by such factors as weather, network congestion, distance from the tower, tall buildings or trees and a host of other things.

While on average your mobile visitors can expect speeds faster than dialup, are they going to wait patiently while the beautiful 150 kilobyte image on your home page downloads? Chances are they won’t, especially if they are stopped at a red light trying to find your address or phone number.

SEO Considerations
I remember during Search Engine Strategies, San Jose in 2006, Google was already warning that Adsense relevancy scores were going to be tied to download times of the landing pages the ads led to. Since then, they have started using download speed as a signal for organic search results as well. I haven’t heard anyone specifically mention Bing using download speed as a relevancy signal, but I can well imagine if they are not using it now they eventually will.

To illustrate this point, Aaron Shear reported in his presentation at last week’s PubCon South during the Advanced SEO Tactics session, that performance gains alone accounted for a 5% increase in traffic to web sites he monitors because of better placement in SERPs on Google. How fast are your pages downloading? Could a performance gain help your placement in SERPs? It’s certainly something worth considering.

Speedometers
There are a couple tools you can use to check your download speeds. My employer uses Webmetrics as an outside monitor to alert if the web sites go down. Part of their weekly report shows download times for monitored websites from their multitude of monitoring sites along with  a comparison to the average of all web sites they measure. This is a paid service, but it might be worth the cost for keeping tabs on downtime and download speeds.

A great free tool is the download speed indicator found inside Google Webmaster Tools. This shows you how long it takes to download your pages, “straight from the horses mouth,” so to speak. Google Webmaster Tools has so many other great features, I highly recommend signing up and using it to help you manage your sites better.

Speeding Things Up
If you find your pages are taking more than 4 seconds to download, there are some things you can consider doing to speed them up:

• Check your image sizes. If you have images on your pages larger than, say, 50 kilobytes, consider putting in some smaller images with options to click for a larger version. Making sure text is text and not embedded in images will not only make the images smaller, it will help search engines index your content better.
• Consider ditching large Flash movies if you have them. If you have one of those “Please wait while the content loads” things on your home page, your Flash movie is too large. Consider moving the “cool” content to other pages with links to it from the home page.
• Use CSS to control the look of your site. This helps eliminate redundant code by taking many style-related tags off each page and refers back to the CSS file, which can be downloaded once and used from the visitor’s local cache.
• Watch for code bloat. If you have CSS files and you’re no longer using some parts of it, delete those parts out. Copy and paste unneeded lines into a text file somewhere off the site if you think you might need them again.
• Consider moving your images and CSS files into a cloud service with distributed data centers. This can help speed up your downloads because bandwidth for these services is usually higher and multiple locations offer better speeds for visitors because files download closer to them. This isn’t usually a cheap solution, but if you have a large web site it could pay off quite well.

What about you? Have you wrestled with download speeds to improve visitor experience and/or SERP placement? Feel free to share in the comments.

I had an interesting conversation the other day regarding file sizes. The person with whom I was speaking had the opinion that since broadband is so common and download speeds are so much faster, one didn’t really need to worry about image or download file sizes. We were talking particularly over some PDFs which were over 5 MB in size.

While it is true that dial-up is all but gone, there is a whole new class of browser which is likely to outstrip even plugged in broadband in just a few years: mobile. According to many predictions, mobile browsing is set to overtake “traditional PC” browsing sometime in the next couple of years.  Gartner, a leading prognosticator of things tech, quoted in this story in MobileMarketingWatch, predicts this will happen in 2013.

While mobile browsing on 3G networks is certainly faster than the old dial-up connections, it’s not as fast as WiFi or wired networks. Speeds will certainly increase as 4G networks become more common, but large downloads still will be an issue even for those on the newer networks.

Another consideration to keep in mind is battery life. It certainly takes more juice to download a 5 MB PDF than a 500 KB one. People will certainly notice if their battery dies faster after visiting your site than if they visit your competitor’s.

There are also search engine optimization considerations to keep in mind. Google very publicly lets us know they take download times into account when figuring out page rank. I’ve not heard that Bing does, but I’m willing to bet they do to at least a certain degree.

So, file size does still matter. It will continue to matter for the foreseeable future. Keep that in mind as you put together your marketing materials for download.

I previously wrote about the discussions going on with my Marketing colleagues about creating mobile apps for our customers. As you can tell from reading the piece, I’m rather “up” on mobile web apps.

However, in the spirit of keeping an open mind and learning more on the subject, I was happy to see a session at the recent InnoTech Conference in Austin called “The Future of Mobile Debate: Native vs. Web Technology.” The debate was held between Andrew Donoho (pro native app) and Brownell Chalstrom (pro web app). It was a lively discussion in which many ideas were tossed about.

Here’s some quick lists both pro and con native mobile and web mobile apps:

Pro Web App:

• Currently, mobile web apps already outnumber native apps by more than 2 to 1. Thus, people are likely more used to web apps.
• HTML 5 and CSS 3 (whenever they are approved) will help mobile web apps have a better user experience.
• Web apps are cross-platform and platform agnostic.

Con Web App:

• There is a temptation to make the app user interface cover the lowest common denominator. There are still a lot of low-end phones out there which are web capable, but with very small screens and text-only interfaces.
• Platform and browser neutrality are easier said than done.
• Complex JavaScript code is slower than native code.

Pro Native App:

• Native code will provide the best user experience possible
• Native code can access all capabilities of the phone (GPS, camera, etc.).
• It’s harder for someone to jump around to a competitor’s web site.

Con Native App:

• It’s not a good business decision to to give one company the power to shut down your mobile efforts. (I relate this to Andy Beal’s 80-10-10 Rule of reputation management which I mentioned in my post “Apples From Applesauce“).
• You can’t launch a native app from a search engine results page.
• Native apps can be exclusionary – if you don’t make native apps for all platforms some customers will be left out (an arguement I made in my previous post).

At the end of the debate, the middle ground agreed upon by both speakers was: If you want an excellent user experience, a native app is the way to go and if you want to be more utilitarian and deliver data easily and quickly a web app is the best choice.

A Note On Platforms
Later that day I sat in on a talk given by a Microsoft rep previewing Windows Phone 7.  Unlike the Windows Mobile model, Phone 7 will use xBox code and Silverlight to deliver a far better user experience. Microsoft has apparently learned the lesson that a mobile device is not another “desktop” platform. Phone 7 will be more consumer-oriented rather than enterprise-oriented as has been its previous efforts.

It seems to me the future lies primarily on three platforms:

• iPhone – currently the market leader.
• Android – from all accounts, it is currently outselling iPhone. They will continue to be a key player in this area.
• Microsoft – Windows Phone 7 may very well bring them back from mobile obscurity. I think they will continue to lag behind Apple and Android, but they will be a player.

Although I don’t think you should completely count out Blackberry, the severe limitations on their browser and lack of apps may make it an “also ran” in this race.

What do you think? What are your ideas in the “Native” versus “Web” debate? What are your thoughts on the future of mobile platforms? Please feel free to share in the comments.

photo credit: whatleydude

Warning: Major Geek Content

If you’ve been working with Microsoft’s Internet Information Server (IIS), and you check out your log files on a regular basis, you’ve probably seen error messages with content similar to this:

Process Information:
Process ID: 3264
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception Information:
Exception type: System.Security.Cryptography.CryptographicException
Exception message: Padding is invalid and cannot be removed.

Request Information:
Request URL: http://www.yourdomain.com/webresource.axd?d=d8qwertyu9a7asdfghjklzxcvn1&t=123456789012345678
Request path: /webresource.axd
User host address: 255.255.255.255

I often wondered what these were about, but all I ever saw in searches on the topic mentioned incompatibility with certain browsers (especially Safari) and miscommunication between the server and the browser. Not really good answers, but enough to know it wasn’t some serious hack attempt.

That was, until a few weeks ago when we started having some major trouble with timeout errors between our web server and the SQL Server which holds the data for our sites. We went round and round trying to figure out the issue ourselves to no avail. Thankfully, we have a subscription to Microsoft’s telephone tech support, so we finally decided to punt.

I have to give Microsoft some serious props when it comes to their top level support. When you get one of these folks on the phone you are dealing with a true professional; one with a lot of knowledge, background and experience to help you work through your problem. The service isn’t cheap, but it’s good.

We worked with a networking engineer who helped us narrow down the issue. He ended up calling in one of his colleagues on the IIS support team to help us find a resolution. 45 minutes on the phone with those two guys was about a week’s worth of education.

In the end, it turned out to be some errant code we put in for error handling. Rather ironic, I have to say, that the error handling caused the errors themselves.

But, the real education was in learning about the webresource.axd and what causes these System.Security.Cryptography.CryptographicException errors.

The webresouce.axd file is generated by the system. Like the web.config, it’s not a file that someone can just “browse” to. It’s requested automatically by the browser and is a helper file to assist with using script files.

The interesting thing is that the “d” portion of the URL string is supposed to be mixed case, but in every instance where I see this type of error, all the letters are lower case, like from the completely fake example I noted above:

d=d8qwertyu9a7asdfghjklzxcvn1

It should be more along the lines of something like this:

d=d8QWErtyU9a7ASDfghJKLzxcVn1

If you go through your server logs, you can track down the requests which cause the errors, compare them to other requests for the webresource.axd file and clearly see the difference. I didn’t notice this until I looked at the logs closely trying to troubleshoot my problem.

Checking closely in the log files, I can also see where sometimes the “&” between then end of the “d” string and the “t=” is sent like “&” – which apparently also causes issues.

There you have it – a “not to technical” explanation as to why you might see this type of error message in your log files. Apparently, so long as your server is patched and set up according to best security practices, this shouldn’t cause you any problems other than possibly filling your log files with messages.

My marketing colleagues and I have been talking about mobile apps here and there for the past year. As more of our customers and partners get smart phones and iPads they are asking for apps designed specifically for those platforms. If that wasn’t reason enough to consider adding mobile apps to our online efforts, the statistical predictions indicate mobile web use will continue to grow at a phenomenal rate. A recent Mashable article cites a Morgan Stanley report which predicts mobile browsing will eclipse desktop browsing by 2015. That’s just five years from now.

While I think it’s a great idea to get on this bandwagon now, I’m not so sure about putting a lot of effort into platform-specific applications. Even though the iPhone is the current market leader, does it make sense to develop an application which only runs on that device? From what I read, Android devices are coming up fast. And who knows what will happen with Windows phones, Blackberries and such. For many businesses, it doesn’t make sense from a cost perspective to put a lot of effort into creating applications which only work on one device.

This reminds me of the debate I used to hear about coding web pages so they would work properly on a Mac or in a browser other than Internet Explorer: Why would you purposely alienate a potentially large percentage of your audience because you choose not to take their browser or operating system quirks into account? I think a similar question holds here, only it relates to smart phone browser or operating systems quirks.

Enter The Web App
In my mind, a cross-platform application makes a lot more sense. And what could be more cross-platform than a web-based app which runs in a mobile web browser? While there are still design challenges involved in dealing with the various mobile browsers, the application  code remains the same. What works on the iPhone will, in all likelihood, work on an Android or Windows phone, too. While it is true that platform-specific apps have more potential for “bells and whistles,” a mobile web browser app can look good and be extremely useful.

Here are some advantages of mobile web apps over platform-specific ones:

• Cross-platform compatibility
• Web browser apps are easier to deploy, update and maintain.
• Because web browser apps predominately run on a central web server, there are no distribution issues like trying to get into the iPhone app store.
• Instead of having to train someone to code for a specific platform or outsource development, companies can use the in-house expertise they already have.
• If a framework such as .NET is used for web development, the same code that powers current web applications can be reused for the back end processes of a mobile browser application. This will cut development time and cost.

I’m not the only one thinking along these lines. While discussing the release of their iPhone app, the Jason’s Deli tweeter indicated they are going to follow up with a mobile browser-based app. The reason: it works on any phone.

What about you? What do you think about mobile web apps? Do you lean towards browser-based or platform-specific apps? Let us know in the comments.

photo credit: Symic

Your Frustration
Errors, glitches, failures and crashes are going to happen and they are frustrating. This is especially true when you’re working on a web site project with your IT Department or other techies. Think about it: you’re trying to get the new or updated web site project finished so you can move on to other things and you find features which don’t work, pages which won’t load, images missing … it can be very frustrating.

Then, when you report problems to your techies, they sometimes seem to drag their feet and don’t fix things right away. Worse is when they tell you they don’t see a problem on their end – and you’re looking at the problem on your screen.

Many times, these frustrations can be eliminated, or at least minimized, by better communication. You might be thinking to yourself, “But, I’m in the communication business. Surely I don’t need to improve.” While it’s true you’re in the communication business and in other areas of your life you are brilliant in this area, when it comes to talking to IT people you might not be “all that.”

Let’s look at it from the IT side.
Your techie counterparts are working in their darkened cubicles, hacking out code at a phenomenal rate. They are working hard to finish your web site by the deadline because they want to do a good job for you – and because they have other projects waiting in the wings with deadlines of their own.

All of the sudden they get an email (or phone call):

• “The site is down.”
• “Such-and-such page isn’t working.”
• “Your page crashed.”

They might sound annoyed when responding to you. This is because they most likely tested whatever it is giving you a problem at least a dozen times during development before they asked you to check it out. Also, being tech types, they lean towards linear thinking. They look at or listen to your message and a bunch of questions come to mind.  They sigh and think, “Here we go again” because they tell people (not just you) over and over they need more information if they are going to efficiently and accurately help you.

Here are some tips which you can use to help you better communicate your way through technical issues when working on a web project with your IT people. These are also quite handy to use when working through any tech support-related issue.

1. Be Descriptive – Don’t skimp on the details. Think of the “W’s.”
   One of the things they will have to do is reproduce the error to see what caused it. The more information you can give them the easier it will be:
   1. Who – of course is you. Is anyone else having the same problem? Ask around if you don’t know.
   2. What – The most important whats when troubleshooting web site issues are: What Operating System is your computer running? And, what web browser are you using and what version is it? If you can’t answer those, ask your IT people how to find out which you are using. Other important whats: What were you doing? What did you click on? What did you enter in the box?
   3. Where – What was the address of the web page you were on? Where was the link you clicked on?
   4. When – About what time did this happen? How long did it take from click to error?
   5. How – Is up to the IT folks to figure out.
2. Copy and Paste – If you get an error message either print it or copy and paste the message text into an email.
3. Use Screen Print – Sometimes copy and paste doesn’t cut it. In those cases, a screen print will work better. Keep in mind, you can’t do this if you’re troubleshooting a total operating system crash. Print screen creates an image of whatever is showing on the monitor you can paste into a file and email.
   Here’s how to do it:
   1. Keep the window with the error showing
   2. Hold the “ALT” key on the computer’s keyboard and hit the button labeled “PrtScn”.
   3. The “PrtScn” button is usually near the number pad on the upper left part of the keyboard.
   4. Open word or an image editing application
   5. Paste into a new document or image file.
   6. Save the file.
   7. Email the file.

While there is such a thing as “too much information,” in my opinion it’s better err on the side of giving too much than not enough. Also, be prepared to answer questions because they will arise. If you don’t understand some technical jargon in the questions don’t be afraid to ask for clarification.

Feel free to share …

If you’re a tech-type: what tips do you have for others who report problems with projects you’re working on.

If you’re a non tech-type: what kinds of things have you learned to help others communicate better with their technical people?

photo credit: mccun934

Are you having problems with parts of your web site since Internet Explorer 8 (IE8) was released? I’ve been seeing chatter around the web about parts of web sites all-of-the-sudden not working even though they work in other browsers. The menus on our own Business to Business site quit working when customers upgraded their browser to IE8.

The problem stems from how IE8 processes JavaScript. I’m not up on all the technical details, but I do have a fix – albeit a temporary one: add the web site in question to the Compatibility View list. Here’s how to do it -

• Open Internet Explorer
• Click on “Tools” in the menu
• Click on “Compatibility View Settings”
• Enter the web page’s address in the “Add this website” box
• Click on the “Add” button
• Click on the “Close” button.

You may have to close and then reopen IE8, but once you add the web site to Compatibility View list, the site should work properly.

We put a note on the home page of our B2B web site to let our customers know about the fix. As I noted above, it’s meant to be a temporary solution.

The long term solution is to figure out why that part of your web site doesn’t work in IE8 and find a fix for your code which will work in IE8 as well as other browsers.

It all goes back to testing your web site in as many browsers as you can to make sure it works in all of them.