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
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.
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 Miljoenhuizen.nl. “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 Miljoenhuizen.nl 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:
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.
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:
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.