Tag Archives: Enterprise Technology & Infrastructure

Website Improvements #3: Better Performance

During the week since the new website has launched you many have noticed slow page-load times, especially when logged in and saving edits. For the past week the Web Application Development team and our colleagues in Central Systems & Network Services have been working to improve the performance of the site and prevent low performance from overwhelming the servers and causing intermittent outages. We have made several fixes over the past few days that bring us out of the slow-site woods and into sunny pastures of snappy responses.

The first big change was documented by Ian in Website Improvement #1: Reducing home page load time by 80%.

The second big change this week was a fix to prevent Google and other search engines from crawling a particularly slow editing page. Repeated hits to this page were overwhelming one our web-servers and slowing down requests for everyone.

The big change today was to move the databases for other web applications off of the database-server used by Drupal. This change has drastically improved our query-cache hit-rate and been the main factor in speeding up saves and other editing operations.

Travis has reworked how the Athletics-roster images were fetched from their database, improving the image-load times from 11 seconds to 12 milliseconds. The Athletics page loads much faster now.

The last performance improvement this week came from a fix to the access denied page. This fix prevents browsers from periodically falling into a loop of redirects that never ended. Preventing a never-ending stream of redirects gives a better user experience when trying to access a restricted page, as well as leaves more server power available for handling pages that will load successfully.

At this point authenticated users should be experiencing page-load times between 300 milliseconds and 5 seconds for almost all view and edit operations (down from a range of 2-25 seconds). Unauthenticated users should be experiencing page-load times between 20 milliseconds and 3 seconds for all page views. We plan to improve performance even further in the coming weeks, but our hope is that page speed is no longer a major impediment to performing needed tasks.

Thank you to our whole community for your patience while we worked through these growing pains.

Website Improvements #2: Custom Redirects

Our GO service has been and will continue to be our supported way for maintaining permalinks to resources. By publishing GO links to resources online and in print, you are able to move your resources to new homes (such as a different location in the new site, a blog, or a wiki) and update the go link with the self-service GO management screens.

During the web-makeover project planning it was decided that we need to move forward with a new site architecture (where everything lives) and drop support for the old URLs from previous versions of the site that are 3-15+ years old. Most of the time links can and should be updated at their original locations, but if that is impossible (such as in a print mailing), you can now ensure that the correct link shows up on the main site’s 404 page.


Steps to add a link for a 404 page on the main site:

  1. Create a nice GO shortcut to the new destination if one doesn’t exist.
    Go to the GOtrol Panel and create a new go shortcut to the new destination URL.
    If a go shortcut for this destination already exists, then you can skip this step.
  2. In the GOtrol Panel, click on the ‘Create’ tab and add an alias for your shortcut from step one. The important thing here is that the alias ‘name’ is the path portion of the URL that is hitting the 404 page after the initial ‘/’.

    For example, if this URL is getting a 404 page:
    then the alias name should be:


  3. Go back to the 404 page and verify that it now includes the GO link to your resource.

We still recommend that you update the pages that link to the site to use their new URLs or GO links, but if that is impossible, you now have a work-around to direct users to the appropriate place.

Website Improvements #1: Reducing home page load time by 80%

Now that the new www.middlebury.edu site is live, we’ll be making continuous updates to improve the design, interface, and performance of the site. After launching the site, the most obvious area requiring improvement was load time for the homepage. Even on campus, the page would take between 12-15 seconds to fully load. Most of this was loading the list of stories to display on the homepage. This used a View in Drupal which would execute this query on the database:

SELECT node.nid AS nid,
   RAND() AS _random
 FROM node node
 LEFT JOIN mm_recycle mm_recycle
   ON node.nid = mm_recycle.id AND (mm_recycle.type = 'node')
 LEFT JOIN term_node term_node
  ON node.vid = term_node.vid
 LEFT JOIN term_data term_data
  ON term_node.tid = term_data.tid
 LEFT JOIN vocabulary vocabulary
  ON term_data.vid = vocabulary.vid
 WHERE (node.type in ('story'))
 AND (mm_recycle.id IS NULL)
 AND (node.promote <> 0)
 AND (vocabulary.vid = '11')
 AND (term_data.name = 'Home')
   ORDER BY _random ASC

The Views module claims that it take this amount of time total to execute this query:

Query build time 12.57 ms
Query execute time 7.83 ms
View render time 28.9 ms

So, about half a second total just to run the query. Unfortunately, the Views module can’t return all of the information I need to build the list of stories, particularly the database IDs for all of the images used in the stories, which are stored in a module that we haven’t fully integrated with Views at this time. While it will be great to get the server-side operations of this query optimized, we needed a good short-term solution for shortening the load time of the home page.

The other problem with the Views approach is that the results were not being efficiently cached by the server. The list of stories on the homepage will change weekly, or daily, but with thousands of people hitting the site at the same time, new requests are fetching the information many times per second. We can assume that most of these people are going to receive the same list of stories, so we now have the server hold onto a copy of the list of stories until someone saves a story node on the site. This is now done using a direct query of the database, bypassing the Views module.

Here’s the difference in page load time:


The list of stories is the fourth line and takes 181ms to load, or two tenths of a second. The main bottleneck for the homepage is now loading the Google Analytics graphic from the remote service. Of course, occasionally you will experience a slow load as you’re the unlucky one that hits the home page right after a cache clear due to someone saving a story, but on average you’ll find the site faster. We expect that this change will have ripple effects in increasing performance on the rest of the site as load on the database is decreased.

This post is the first in a series meant to shed light on the improvements we’re making on the site. My goal is to do at least one thing each week to dramatically improve our website experience for someone. If there are particular things about the site that you feel need improvement, please fill out the web feedback form. If you have questions about this topic, leave a comment.

New WordPress Themes

New WordPress themes have been added to WordPress at Middlebury.  This blog has been updated to use Translucence, an interpretation of theme designs drafted by White Whale as part of the Web Redo project.

Translucence, like ShadowBox, is a theme series that includes a number of variations and options for layout.  This blog is currently configured to use a flexible width such that the width of the blog will vary with the size of your browser window.  As well, it is configured to include  2 right sidebars (instead of a single left and right sidebar).

Feedback/comments/suggestions welcome.