Article Archive by Jordan Sandford

July 10 2009

An Overview of Optimizing Your Web Pages for Speed

by Jordan Sandford

As long as the Internet has been around, long before search engines came on the scene, speed optimization was an oft-pursued goal. Whatever made the user wait the least time for a page to show on their monitors would be employed. Now, search engines are measuring load time for pages and using this metric to help determine quality. Even in the age of high speed internet, page load time is both an SEO issue and user experience (UX) issue. In addition, not all high speed connections are the same “high speed.” This difference is noticeable depending on your proximity to urban areas and internet connection type (fiber, DSL, cable, satellite, etc.)

In my first post in this series on speed optimization, I will provide some general areas where speed optimization can take place. In other posts, I will discuss some tools that can help in this effort.

I’d like to make some comments before I start. Depending on the current state of your website or web pages, making just one of these optimizations may not be apparent. Making several optimizations, however, should cause a noticeable change. It’s a good idea to fully understand these suggestions and match them to your site (consider your site’s type, size and daily/weekly traffic patterns) before implementing them, because you may actually end up slowing your site down instead of speeding it up.

General areas for speed optimization

  1. Remove unnecessary HTML code (or, using techno-speak: remove unnecessary DOM elements).
    As an example, you don’t need a DIV as the only tag inside another DIV. As another example, you don’t need tags like DIV or SPAN sitting around with nothing inside them. Removing unnecessary HTML decreases “code bloat,” makes the browser display the page faster (a.k.a rendering time) and increases content-to-code ratio, which helps your SEO efforts. You want the search engines to have to sort through the least amount of code to get to your content.
  2. Use the least amount of websites to serve content (a.k.a. host names).
    Examples of different host names are:,,,, The benefit is that every time the browser needs to find the internet address of a new website, it takes some time. The less address look-ups, the faster the page will display. Note: This is more applicable with images than with video and other web services like Google Maps, YouTube and Twitter.
  3. Move as much CSS and Javascript to external files as possible. This also helps with your content-to-code ratio and helps separate the content from the programming.
  4. Use the least amount of external files as possible.
    Any time a file is requested from a website, the browser has to wait for the request to go all the way to the server and then wait for a response. In addition, there is always a bit of “meta” information about this communication that must be transmitted as well.
    Here is an example: you may have 10 different external Javascript files that are responsible for different things on your site. Consider merging them, either using an automated or manual process.
  5. Optimize all files, including images, videos, PDFs and Flash files.
    Don’t forget to optimize text-based files such as CSS, Javascript, HTML and XML files by removing empty lines. Especially useful on Javascript and CSS files, “minifying” removes all unnecessary spacing. This causes the file to be the smallest possible while allowing browser to interpret the file correctly.
  6. If you have a lot of media content and a lot of traffic, use specialized servers that are tuned to serve specific types of content.
    These servers are part of systems called content delivery networks, or CDNs. A well known CDN is owned by Akami Technologies, and is used by large websites such as CNN. A more likely option for an average site would be Amazon’s CloudFront (read a review of CloudFront by Amazon Launches Cheap CDN for SMB Web Publishers).
  7. Even if you do not use a CDN, consider properly adjusting cache and compression settings in your website.
    Caches settings, when used properly, help the browser re-download content only when it has changed. Compression settings allow the transmission of the files to be faster, since the file will be compressed when in transfer, but uncompressed after it gets to the web browser.
  8. Limit the use of HTTPS.
    HTTPS is a secure communication system used when transmitting sensitive and personally-identifiable information back and forth to websites. This is extremely important for many sites that use sensitive data and want to maintain a high level of customer trust, but serving content via HTTPS is slower than by HTTP, so make sure your site only uses HTTPS where it must.
  9. Try to limit the amount of redirects needed between when a user clicks a link (or types a URL) to when they see the page.
    Redirects can cause slower load times, but many times are the only answer for various problems, including SEO issues. All redirects cause the “meta” information, mentioned in item 4 above, to be transmitted, regardless of whether any real content is transmitted. When redirects occur, especially multiple redirects, time is wasted when the browser has to wait for the real content to be transmitted.

These items do not encompass nearly all areas in which speed optimizations can take place, but they should be a good start to the concepts I will discuss some future posts.

June 15 2009

Trouble with Google’s Snippets

by Jordan Sandford

Recently, there has been some fuss about Google’s page snippets showing inaccurate and misleading information. Google’s page snippets help the searcher quickly find relevant search results and are the parts of a search engine result page directly under the title of the page (in larger, blue text) in black. Snippets contain phrases from the indexed page, and the phrases themselves contain text that matches the keywords typed in Google’s search box.

In one incident, the first of its kind, someone typed in “Zwartepoorte,” a name of an auto dealer in Europe, and “failliet,” the Dutch translation of “bankrupt.” One of the results was a page from the site “Failliet” was found in one section of the page and “Zwartepoorte” was found in another section. Google usually notifies the searcher that the snippet phrases came from non-contiguous parts of the page by adding ellipses between the phrases. This was the case in this incident (the ellipses between “BMW” and “Dit”), shown below. However, a legal battle ensued because the resulting snippet essentially said that the auto dealer was bankrupt, when that was not the case. The web master of ended up having to pay the consequences.


Ellipses are probably used to conserve space so that Google doesn’t have to put each phrase on its own line. They are also used to signal a break in text. The issue is that the ellipses are hardly noticeable nor distinguishable from other ellipses that may be in the original text. If they were a bit more noticeable, the average user might then investigate their meaning. Google could even add a helpful link next to the “Cached” link, such as “Composite Snippet.” It might look like this:


Another issue I see is that the definition of “non-contiguous” is left up to Google’s algorithm and their engineers. I’m sure there are known ways of how to deal with this potentially slippery issue, such as separating the text by some large distance (as it appears to Google’s algorithms, i.e. ignoring any Javascript and styling) or by putting them in separate HTML elements. These are simply ideas off the top of my head and not necessarily realistic ways to approach the issue. Especially if the content on your pages are dynamically created, it may be very difficult to circumvent some inaccurate snippet text being shown on Google’s result page.

However, there is a way to cause Google to stop showing all snippet phrases from a specific page on your site on their search results. You can find more information about this on Google’s blog post, The Robots Exclusion Protocol. Essentially, you would add the following meta tag on any page for which you want Google to hide the snippets:


Beware that, in addition to completely removing the snippet, this renders the cached version of that page (and therefore the Cached link) inaccessible to searchers.

June 9 2009

Quelling Fears of Implementing a CMS

by Jordan Sandford

Today, I’d like to help reduce your fears and address concerns about implementing a content management system on your website.

You may be thinking about the vast number of pages on your current site, the difficulty of maintaining them and considering how using a Content Managements System could help relieve your headaches. One of your first tasks in going down this road will be matching your needs to a CMS. Here are a few survey questions to help you articulate your needs:

  1. How many main sections (applications) does your site have or will you be planning to implement on your new web site (for example, an articles section, a blog, a forum, a store, wiki, CRM, etc.)?
  2. Do these sections need to be integrated in any way?
  3. How many different content pages do you have (not blog entries, forum or store/product pages)?
  4. How often do you make changes to your content in each section of your site?
  5. How many people will be administering various parts of your content?
  6. What are the skill levels of the people administering the site?
  7. How many visitors do you expect in any given hour?

Fear #1: High Cost
While there’s no question that some CMS implementations have been an expensive endeavor for some, it doesn’t have to be that way. If you take an accurate and thorough assessment of the scope of content and features you want to migrate before creating expectations, you will thank yourself for not having to change requirements down the road. Having a well thought out organization of your content and interface (“information architecture” and “user experience,” respectively) before starting to implement your CMS will save you a lot of time and money. Even if you are considering a proprietary CMS and you need some features that aren’t part of the core CMS, find one that is designed to be extended easily. Whether you or your vendor implements the new features, having the features as add-on modules (instead of bolted on to the CMS core) will drastically reduce the development time later on.

Fear #2: Steep Learning Curve
I’m sure you will want to be able to edit your content right away and not have to read the manual in order to make adjustments to your site. The learning curve of your CMS will largely be dependent on the amount of flexibility you need in the system: the more flexibility, generally the steeper learning curve. It is also dependent on the simplicity of the administrative concepts. Consistency in the administration interface also helps to speed your learning curve. Remember that a modular design goes a long way in maintaining simplicity and consistency in both the CMS as a while as well as the administration interface. The good news is that most modern content management systems use this design.

To help reduce the learning curve, it’s a good idea for most people to choose a system that doesn’t have an exorbitant amount of core features over and above their needs. There are hundreds of content management systems from which to find a great match for your organization’s needs.

Fear #3: Not Flexibile
Everybody’s needs are different. Even if you do not pick a CMS that is custom-made from scratch, you may still need a fair amount of flexibility to adjust it to your needs. One of the best ways to attack this fear is to consider systems that have a large user-base and are modular by design. Again, many modern content management systems are designed like this. Usually a large user-base will naturally increase the level of flexibility the CMS has, because all those users have a large number of various needs, and to support all these needs, a successful CMS must be flexible.

Fear #4: It Will Take a Lot of Work to Migrate My Data
If you have a lot of pages and have not profiled your data to see the various formats and systems your data is in, I would suggest you do that. Otherwise, your fear may be unfounded. For example, if you’re using some kind of template system, like a Dreamweaver template, the HTML code surrounding the main content will usually be the same for all your pages. You can then use a search-and-replace process (using a good text editor or a program like RegexBuddy and possibly practicing creating simple regular expressions) to extract the content from your pages, making it faster to put the page’s HTML code into the CMS’s database.

If your content is already in a database, there may be very little work that needs to be done to migrate your data.

Fear #5: It Will Be Difficult to Integrate With Other Systems
Every organization’s needs and situations are different. Not everybody uses the same shopping cart package or the same blog software. The amount of software combinations we find our clients using is huge. However, chances are that other people using the same software you are using have some experience integrating it with other systems. Google searches such as [integrate SOME CMS HERE with SOME APPLICATION HERE] can get you started.

Once you’ve found a good, modular CMS, you should consider writing (or have some one else write) a single module that ties all your other systems to the CMS. This is as opposed to adding code to the core of the CMS for each system you are integrating. All modules written for a specific CMS generally have the ability to communicate with the CMS already built in because they are built from the same framework or foundation. This approach to integration reduces variables, streamlines your development and leaves the interchange between the module and the 3rd party systems as the only thing left to create. All of these reduce development time. Once you have written the interchange between the first third-party system, you will have learned how to interface with the module, and all other interchanges will take less time to code.

Fear #6: Support Will Be Hard to Find
Hopefully you won’t need support for your CMS, but if you have a lot of requirements and many users, eventually a support issue may arise that will be best answered by a live person after you read the manual.

MoreVisibility’s CMS implementations are part of our Optimized Design package, which can be utilized with any amount of optional maintenance hours. If you are not using our CMS, your vendor may provide support. Or, if you’re using a well known CMS, there should be plenty of support resources on the web including forums where you may be able to ask questions. In addition, there may be tutorial DVDs or books available, as well as third-party vendors that specifically support your CMS.

I hope I have addressed your concerns about implementing a content management system. If you haven’t yet, please read my blog series called Content Management Systems and SEO for general information about how they work and what to look out for.

© 2021 MoreVisibility. All rights reserved.