Optimizing Site Speed

Talking about site speed today almost seems superfluous, with so many users accessing the web with powerful Internet connections and download capabilities. Most desktop users access the web via cable or fiber optic lines, brandishing download capacities of 15 megabits per second (Mbps) or greater. Although many users will often access those same Internet services via wireless signal, the rapid spread of 4G networks has brought similar download speeds to mobile devices even when they aren’t connected to WiFi.

Despite all that, there are still some desktop users that access the web using DSL or dial-up connections and many mobile users that are restricted to less powerful networks.

But, regardless of all the latest technologies, there will always be some subset of users that hit your web site with poor Internet connections. In addition, many mobile users are limited to how much they can download over their provider’s data network. Personally, I’m limited to 2 gigabytes of data usage per month, excluding any data transferred over WiFi.

That means that when we build and maintain web sites, we need to be cognizant of users’ technology capabilities, as well as their limitations, and plan accordingly.

Understanding Your Users

The first step towards building an optimized web site is simply getting to know your users. Getting a basic idea of user demographics such as age, income, and location will allow you to make some general assessments about how they are accessing your site.

I recommend utilizing Google Analytics to help verify (or nullify) any assessments that you have made about your users. There are several “Audience” reports that will help you gain some insight.

  1. Demographics > Location – Shows where your users are located geographically.
  2. Technology > Browser –  Shows what browsers your users are accessing the site with. I like to check this prior to development to help determine what browsers need to be supported for the site.
  3. Technology > Network – Shows what Internet networks are being used to access your web site. This may give you some idea about your users’ download capabilities.
  4. Mobile > Overview – Shows a basic breakdown of your total desktop, mobile, and tablet users.

Google Analytics doesn’t collect enough information to paint a detailed picture, but these reports, combined with your own experiences, should give you a pretty good idea of what to expect.

Once you understand your users, you can then determine which optimization practices are necessary for your site.

Optimization Basics

Here are some easy techniques that I recommend for all sites, regardless of user technology.

  1. Minify CSS and JavaScript files. This will remove all unnecessary spaces from your files and reduce their size. I prefer cssminifier.com.
  2. Combine CSS files to reduce HTTP requests. Previously, I would keep my screen, mobile, and print styles in separate files, but I have begun combining them into a single file to reduce the number of requests the browser has to process.
  3. Create image sprites. Likewise, you can reduce requests by creating a single image with all of your design files. High traffic web sites like Amazon.com use this technique frequently, but I find it to be a bit cumbersome and avoid it unless I feel it’s necessary.
  4. Scale down and optimize images for the web. I recently noticed a client site was loading slowly and discovered that three of the photos on the home page totaled over 12 mb. By simply scaling those images down to dimensions that fit their container, I was able to reduce the page weight to well under 1 mb.
  5. Optimize PNGs. Photoshop is notorious for creating bloated PNGs. There are many services that you can use to reduce the bloat and overall file size. I like TinyPNG.
  6. Only reference the files that you really need. If you are only using JavaScript on the home page, only call the file on the home page. There’s no need to impact the loading of other pages if they never use the file.
  7. If you are using jQuery or another popular code library, consider referencing Google’s hosted copy. Since many other sites do the same, users may already have the file cached in their browsers, which will save loading time.
  8. Many JavaScript libraries such as Modernizr allow you to customize what code is included in the file that you create. Only download the functionality that you really need.

Most of these steps are simple and can easily be implemented on any web site without impacting quality or deadlines. Doing these things will reduce page weight, decrease loading time, and ultimately improve user experience.

There are many other things that you can do to help reduce page weight and decrease load time, but you’ll need to decide what techniques are right for you and your site. In many cases, the basics may be fine, but in others, every kilobyte may be important.

To learn more about page weight optimization, I recommend reviewing the Network and Audits features within Google Chrome’s Developer Tools. I also really like the Pingdom Tools website speed test. Both of these will break down how long it takes each resource to load and provide suggestions for optimizing your site.

Advertisements

Supporting New Software? No Problem.

One of the first stages of the software development life cycle is the roll-out of brand new software and with it comes that awkward honeymoon phase – it’s anyone’s guess as to what problems might arise during the first few weeks of use. With this comes a sense of uncertainty, but it doesn’t have to be all that scary! Since I’ve started working at Algonquin Studios, I’ve seen many old and grizzled systems scrapped in favor of bright and shiny new ones and I’ve learned a lot about piecing together a support process for when you aren’t totally familiar with the new software. Here are a few important things to keep in mind when venturing into uncharted territory:

There will be bugs. Probably more of them than you expected.

Even if you have the most fantastic software developers imaginable (like we do here at Algonquin), there are going to be unforeseen issues that pop up, so expect a sizable workload increase in the first couple months after releasing a brand new system. This leads to my next point…

Stay organized and consistent with bug tracking.

With an increase in bug reporting, it’s vital that the support team is clearly documenting all bugs reported and all team members tasked speaking with end users are kept up-to date on issues as they develop. Being diligent about your tracking will ensure that when it comes time to fixing those nasty bugs, everyone has as smooth a ride as possible.

Make sure you manage customer expectations.

As with all customer support issues, it’s important to manage expectations about bug fixes and requests for new features (Hey, I actually wrote a whole post about that here!). If there’s an issue or request that a user is anxious about seeing to resolution, let them know that you’ll be documenting the issue to be reviewed, but make no promise of when it will be completed. Not everything can be fixed or added at the same time and it’s best not to give false expectations.

Create and update a Knowledge Base from the get-go.

If you’re not keeping an updated Knowledge Base for your support team, you need to start… And you need to start yesterday. A centralized location for in-house use is crucial to being able to provide consistent answers on issues as they arise. Are you receiving the same questions on how to do a specific task in your software? Create a step-by-step “how-to” that you can send to customers quickly and easily, saving everyone a whole lot of time and confusion.

Have a simple way to escalate issues on a regular basis.

Whether it’s a weekly meeting or a regularly-sent report, there needs to be a way to let upper-level management know what’s going on. It’s ultimately not up to the front-line team to decide what gets fixed and when, but it is their responsibility to make sure the higher-ups are able to hear about the most dire issues. If there’s no process in place to communicate this, make sure you create one so the development life cycle can progress naturally.

Remember, as bleak as handling support may seem at the launch of new software, it will always get easier as time goes on. Implementing a brand new system is a learning process for both end users and support teams, so treat it as such! Look at it as an opportunity to grow your own skills and knowledge and reassure everyone involved that the process will all be worth it in the end. Every company will handle the launch of new software differently; what are some examples of procedures that your team utilizes when implementing a new system? Leave a comment and let us know!

Know Your Requirements!

Often times at Algonquin Studios, clients ask us to improve on their current software solution. The existing solution is either out of date or it simply isn’t giving the client what they need. For the user, changing systems can be a scary proposition. People grow comfortable with what they are accustomed to however, following a routine that you’ve done for years is the safe route. For this reason, it’s very important to sit back and think about what the system needs to accomplish. We want to make sure we maintain the output they are expecting from the software they use on a day to day basis, but keep an open mind on how to get there. In order to ensure this outcome, we spend a considerable amount of time conducting requirements analysis.

During the requirements analysis phase, one of the most important parts of a project, we determine what exactly the client needs are and how we will provide that solution. Time and again we run into the same obstacle of getting the client to see the difference between “what your users have today” and “what do you need the software to accomplish.” Clients often want everything they have today, in addition to the improvements we will provide with our software. Unfortunately, this could cause unnecessary features to be included in the software and add additional costs into the project going forward (training, support, system complexity … etc.). Costs that could be used elsewhere, either for the company or to build out additional features that are needed in the new system.

So, when coming into these requirements meetings it’s best to come prepared. To be better prepared it’s most important to know what is needed, as opposed to going screen by screen showing us everything they have today. There are many other ways to be prepared for these meetings, here are a couple:

Question your users

As a client, when was the last time you asked your user base about the program they use on a day to day basis? Requirements and business needs are always changing over time. Depending on the size of the user base, and the software being used, these questions could vary (and there are many). In the end, the client should find a way to determine:

  1. Which features are being used the most?
  2. Which features are rarely (if at all) used and aren’t needed?
  3. Is there anything you need the system to do that it doesn’t do today?
  4. Does the system provide repeatable work that the software doesn’t handle, costing people time every day?
  5. Are there current features that need to be revised to accommodate current needs?

There are many ways to gather this data.

Is this software internal, used by only a handful of people in your office? Have a meeting to review the software and gather the information firsthand from the users. Come prepared to ask about features that work and those that don’t. Are there any that have lost value over the years?

Do you have thousands of users using the software across the United States? Setup online user groups and invite people to provide valuable feedback on the software. Depending on the capabilities of your software, you can limit the groups to certain sections of the software and provide questionnaires about those sections. This should help you gather all the necessary information to bring to your developers, so we can make sure we build you an efficient, quality application that suits all your needs.

Clearly Define the Inputs/Outputs

Frequently, a screen can be so overloaded that one loses focus on what exactly is needed. Determine all the inputs of the screen and make sure they are all required and are what you need. Next, identify inputs that are unnecessary or misused. Keep in mind that just because they exist today doesn’t mean they’re needed going forward. Additional inputs only cause more complexity.

As important as it is to define the inputs, it’s equally important to define the outputs. Outputs that are currently delivered may no longer be needed or efficient or may simply be delivered differently in the new software; Once again, this is often difficult for a client to understand. Asking a lot of questions in the requirements meetings about those features can help ease the process because in the end, the more inputs/outputs you have the more complex your system will be. Our team of consultants are really good at letting clients know if the value they’ll receive from a feature is worth the effort and, generally, we can determine this during the requirements meeting.

In the end, if the client does their part in determining what’s exactly needed out of a system in order to eliminate all the old, antiquated screens and logic, the better the software will be. This will ultimately save the client in the long run.