Tag: Drupal

Draft Mode & More Forms

Over the last year, one feature we’ve heard requested over and over again is the ability to save a draft of your content and come back to it later. This last weekend we finally got it working, using a module called Workbench Moderation.

This module actually makes some pretty significant changes for everyone, even if you never use drafts, so let’s take a look.

In order, "View Published", "New Draft", "Moderate", "Webform", "Results"

The most easily noticed changes are the tabs along the top of pages you edit. The first one, “View Published”, is the same as the old “View” tab. You’d use this tab to see the content that the world currently sees. The second tab, “New Draft”, replaces the “Edit” tab. The last change is the new “Moderate” tab, which replaces the old “Revisions” tab.

For most people, your workflow shouldn’t really change. When you want to make an edit, click “New Draft”, make your changes, enter your revision message, and click save.

But if you’d like to save your work for later, click on the “Revision Information” horizontal tab at the bottom of the page. Below the log message you’ll find a dropdown showing three states: Draft, Needs Review, and Published.

Shows a Revision Log Message box, above a dropdown for moderation state.

If you set your Moderation State to “Draft”, and click Save, Drupal will make a draft for you. Alternatively, you could set your state to “Needs Review”. This is an intermediate state – you’re no longer making changes to it, but you need someone else to take a look at it before you publish it.

You can manage the states of your page using the Moderate tab:

Shows a list of revisions to a page. The top one includes the text "This is the current revision. The current state is draft". The second one has the text "This is the published version"

This is a bit confusing at first, but it makes sense after you’re used to it. The top entry is the current revision of this node – the one that’s been saved as a draft. If you’d like to change it to Needs Review or to publish it, you can use the dropdown on the right hand side. The second entry is the currently published version – the one everyone sees.

The second big change we made was to the forms module, where we upgraded four minor versions. On the webform tabs, you’ll see some extra options for your forms, including the ability to add a progress bar on multipage forms. You should also see improved handling of unicode characters (non-latin alphabet) and better Excel exports.

If you’re a content editor, expect an email with further details soon. And, as always, if you’d like more information about forms or draft, just email Lori.

Changes in Drupal Land

There’s a couple changes happening in Drupal that you might want to be aware of:

Google Analytics Modifications

Currently, we’re using the old style Google Analytics embed code, and adding it directly via our template in html.tpl.php. This works, but it isn’t optimal. For a long time we’ve known that there’s a couple users that use the website in a way that doesn’t reflect real visitors: the Lane Web Team.

To take me as an example, yesterday I looked for old links to www2 urls, and found them on sixty different pages. I directly navigated to each of those pages, stayed on them for about fifteen seconds, loaded the edit window, made a change, saved the page, and left, directly navigating to another page. The statistics for that day are now ever so slightly skewed toward a person that appears to change pages at random, staying on them for almost no time at all, and who appears to come from nowhere. I’m making it harder to understand what people do on our website, and how we can serve their needs. And it isn’t just me – the whole webteam could tell a similar story.

So, this weekend 9/20/14, we’ll be installing the Google Analytics module. With it, the tracking code will automatically be disabled for our administrative roles, who together represent a disproportionate number of visits. How does this impact you? Soon it will look like our traffic numbers went down – probably about 2% – just because we’re not tracking those three roles. So, if you get an analytics report mailed to you, don’t be too alarmed if the numbers go down, just adapt to the new baseline. And remember, you can always contact us if you’d like help thinking through your analytics numbers.

Friendlier URLs

By default, Drupal uses ugly URLs. The contact page is technically something like lanecc.edu/index.php?q=node/106. We’re using a couple of modules (Path Alias, part Drupal Core, and Pathologic) to make those urls look friendlier, like lanecc.edu/contact. But, ever notice what happens when you try to edit a page? You get another ugly url, like lanecc.edu/node/106/edit. This weekend, we’re also going to try to fix those, using the Extended Path Alias module. All of those pages that previously had a node number in them will now have a nice, aliased URL, like lanecc.edu/contact/edit.

I’m sure that doesn’t seem very exciting. But it is, because when someone submits a webform, they were previously taken to a confirmation page with an alias like lanecc.edu/node/86/submission/75309. Because that url starts with /node, Drupal isn’t able to figure out which menus to include, meaning the person that just submitted your webform is effectively no longer on your part of the website.

Of course, by replacing all those technical looking URLs with friendly ones, that makes it harder for you to tell us the node number, or to paste a node number into the link dialog when editing a page. So we’re also going to make it easier to find those node numbers – starting next week, just look to the right side of your screen while logged in and you’ll find a little black tab with the node number written on it.

EDIT (7/9) – Unfortunately, we had to roll this one back. With this enabled, /it/somepage.html would actually go to /it/, meaning no 404 was served. We’re still looking for a solution at this time.

Print Styles

This one is actually live right now! We’ve added a print style sheet to the pages, which attempts to make webpages more useful when printed out on paper. It’ll probably work best in Firefox or Chrome, but when you print:

  • The left menu will be hidden
  • The header of the page will be hidden, except for the department title (if present)
  • The megamenu will be hidden
  • The footer will be hidden, except on the landing pages
  • Links will have their urls added to them, so that if you stumble across a link in a printed page that you’re interested in, you can at least type that link into a browser manually.

If you notice any bugs (There’s a LOT of printers on this campus, and its impossible for me to test all of them), please let me know.

The Importance of Revisioning

When you’re editing one of our Drupal pages, you may have noticed a little tab down at the bottom, right above the save button:

A picture of the bottom of our Drupal Edit screen. Of note is the "Revision Information" tab which defaults to closed.See that little grey box? The one that says “Revision Information”? That’s actually a very helpful box. In there, you’ll find a place to enter a revision log message, where you can describe the changes you made to the page, like this:

Shows a revision message added to a node: "Modified the header style"You may not have been aware, but if you click on the revisions tab at the top of a page, you can get a list of who made changes, and when those changes were made. If everyone also includes revision log messages, then we can also, at a glance, see what was changed. And that can be super helpful:

The revision log for our sample node, at the top is the revision made in the previous picture, including the message left. Other revisions didn't have a message.
Unfortunately, this example may be a case of “Do as I say, not as I do”

As you can see, the first 4 revisions, by me, have no revision message. It’s very difficult to see at a glance what changes I made, or why I made them. But the most recent message, “Modified the Header Style” tells you exactly what I changed.

If we wanted an ever better message, we could have written “Changed page header from a paragraph to an H2, in accordance with the guidelines provided by the webteam”. Then we’d know not only what was changed, but why.

So revisions are awesome, right? But they work best when everyone uses them, so that if I modify your page, you’ll know what I did, and I’ll know what you did before me. For that reason, this weekend we’ll be turning on a module that enforces a revision log message. In other words, if you forget to enter a revision message, you’ll get a nasty red message that highlights the revision message box and asks you to fill it in. Please take the time to write a brief, meaningful message. It’ll help everyone out.

This change is part of a broader set of changes we’re hoping to make to the Drupal editing experience to allow more flexible workflows. Expect more details in the upcoming weeks!

DrupalCon Portland, and the evils of and

Last week, two Lane Web Team members went up to DrupalCon Portland.

The Drupal "Drop" under a pendulum at the Portland Convention Center
Did you know Oregon has the world’s largest Foucault Pendulum?

In addition to opportunities to network with other institutions running Drupal around the state and world, there were a ton of awesome speakers and “Bids of Feather” sessions, where groups of like minded people got together to talk about issues relevant to them. Take a look:

A whiteboard, showing a grid of different sessions at various times, including such sessions as "Pantheon and HigherEd" and "Higher Ed Content Strategies"
This seems like a weird thing to take a picture of, but the BOF listing couldn’t be found on the web anywhere – wifi at conferences is notoriously poor, so it wouldn’t have done us much good.

The second day’s keynote, by Karen McGrane, was about user experience and design, and provided some excellent insights for us (watch it here!). The one that will impact you most is our removal of the <i> (italics) and <b> (boldface) elements from the list of allowable elements on Drupal content pages.

As per why, it has to do with two things: Future Proofing, and Accessibility. Back in the day, when content was designed for paper, boldface and italics made a lot of sense. So the <b> and <i> HTML elements were used to replicate this on the web. But, not too long later, people realized that these elements didn’t actually convey any semantic information – they were purely visual. So they added the <strong> and <em> (emphasis) elements.

Now, here’s the thing. Strong text, and emphasized text look exactly the same as boldfaced and italicized text – this sentence actually uses <strong> and <em> tags. So the average web user won’t notice any difference. But what happens if you’re using some futuristic wearable computing device that reads web pages to you? With <strong>, your device would know to read a certain word or sentence strongly, and to emphasize text in <em> tags. But if they were <b> or <i> tags, you wouldn’t have even known they were there . Turns out this is the same way screen readers work.

As of this morning, we’re filtering out <i> tags and <b> tags. There’s a 99% chance this doesn’t impact you at all – using the buttons in the WYSIWYG on Drupal automatically uses <em> and <strong> instead. But if you’ve been doing something fancy after disabling the rich text editor, you might need to change your page some.

 

Common Pitfall – Links

During our last deployment, we stumbled across a couple of errors our content editors made. When we talked to them about it, we learned that often, the editors weren’t even aware there was an issue. So I’d like to bring special attention to one of those errors that is easy to prevent, and helps make the website work better for everyone.

Links

There’s just a little bit of technical background you should be aware of. In Drupal, every page has a node number – an internal number that Drupal uses to identify your page, independent of the page title or URL. For example, our contact page, at http://www.lanecc.edu/contact, is node 105, which you can see for yourself just by clicking those links.

The URL for your page is based on two things: the ‘chunk’ your page is assigned to, and the title you’ve given your page. For example, the page http://www.lanecc.edu/math/division-projects is in the “Math” chunk, with the page title “Division Projects”. When that page title changes – say to just “projects”, then the URL of that page will also change. The new url will be www.lanecc.edu/math/projects.

Why does this matter? Well, a number of our content editors are adding links to their pages by simply pasting a link on their page. Drupal, being a friendly, helpful CMS, automatically turns URLs into links. All is well and good until a page title changes and the URL changes. Suddenly, the pasted link isn’t to the right URL any more.

The fix is to use the LinkIt module. You might recognize it as the “Insert Link” button, from this image on our help documentation, and from the WYSIWYG editor:

The Drupal editing interfaceWhen you click that “Insert Link” button, you’re given a little popup window, where you can search for content and select the page you want to link to:

The Drupal TinyMCE interfaceThere’s two input boxes in that white box. If you’re linking to an internal page, start typing in the top box, and Drupal will search page titles for you, and let you select the page you’re looking for. If you’re linking to an external (not on Drupal) page, paste the URL in the bottom box, and then just say insert – there’s nothing to search for.

Again, why does this matter? Because Drupal knows the node numbers of pages, and instead of linking to lanecc.edu/contact, it will link to lanecc.edu/node/105. When someone visits the contact page, Drupal looks up what the URL is for node 105, and gives the visitor a link to the right place. In other words, you don’t need to worry about updating internal links – we’ll take care of it for you.

Unfortunately, because not using LinkIt has resulted in a number of preventable 404 errors, we’re going to make some changes to the Drupal interface to make sure they don’t continue to cause problems. Soon, Drupal will no longer automatically link up URLs that you paste into the page – you’ll need to use LinkIt if you want them to work. And pasting a www.lanecc.edu link into the bottom box of LinkIt won’t work either – we’ve disabled that as well. *

To help get the entire site back to where it should be, we’ll be checking the database over the next few weeks and helping editors that seem to be struggling. Don’t worry – we’re just trying to make sure that all the links on the site always work. And if you are having trouble, check our help pages (Drupal authentication required), and don’t hesitate to contact someone on the web team.

* There’s also some room for User Interface improvement here, and we’re working on it, but it involves some tricky changes to some code that we didn’t write, and unfortunately user interface improvements often can’t be at the top of our priority list. But we won’t forget about this one.

Website Accessibility Improvements

As an educational institution (and as responsible web developers!), we’re very concerned with the accessibility of our website. Although our primary concern is following the Section 508 guidelines, there’s a number of other best practices we’re trying to follow.

Before I get going, I’d like to note that this post only applies to our Drupal redesign, and to the pages on www2.lanecc.edu (though we’ll soon be moving www2 to www).

Section 508

508 contains sixteen standards that directly address web content. I think it’s worth looking at each of these standards in detail.

(a) A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).

Through a combination of limiting editing functionality and filtering tags when pages are saved, we’re only allowing four non-text elements on pages: images, YouTube videos, Flickr slideshows, and Google Maps. This is a significant improvement over our old site, where we had no method to limit tags, allowing any number of non-text elements to be introduced.

When a user editing a page in Drupal inserts an image, they are prompted to add an Alt Tag, with a note about its importance in improving usability. Just to make sure no images escape our attention, we run a weekly report that checks all of the images on the site for alt tags, and alerts us if improvements are needed. Additionally, the importance of Alt tags and accessibility in general, is discussed with Drupal users during our normal Drupal training.

Unfortunately, there are some accessibility concerns with Flickr. For this reason, Flickr is not intended to be our final image slideshow solution, and is only a temporary measure while we explore alternate solutions. We’ll be rolling out an alternate slideshow solution, with a goal to be totally away from Flickr by the time we upgrade to Drupal 8. In the mean time, users are responsible for providing relevant accessibility information for their own Flickr accounts.

For more information on the accessibility of YouTube videos, see guideline b, below. More information on Google Maps accessibility can be found at http://www.google.com/accessibility/products/.

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

Unfortunately, there is no automated method for us to ensure compliance with this standard. To improve the likelihood of compliance, we have removed the ability to embed videos on pages from sites other than YouTube, which has the best closed captioning support, sometimes providing them automatically. During our media training, we make a special note of pointing Drupal users toward captioning resources (which can be found at http://support.google.com/youtube/bin/answer.py?hl=en&answer=100079).

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

As part of standardizing the appearance of our website, we’ve tried to reduce the role of color in providing information. Generally, users are unable to modify the colors of their pages, and where color is used to convey information, such as tables and alert notices, markup is provided to convey its purpose (through thead tags and alert classes, respectively).

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

When developing the new Drupal site, one of our goals was to make each page’s content work independently of style, not only for accessibility, but also to facilitate easily modifying page style in the future. We’ve tried our best to ensure that pages use ordered, semantic HTML, to provide hierarchy that’s easy for screen readers to navigate, and we’ve added helpful links to allow screen readers to jump over or directly to the page navigation.

(e) Redundant text links shall be provided for each active region of a server-side image map.

We do not use image maps on our site.

(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

We do not use image maps on our site.

(g) Row and column headers shall be identified for data tables.

When using the table wizard in our Drupal page editor (TinyMCE), table headers are automatically provided. Row headers are not always relevant, and as such are not automatically inserted. If we notice a pattern of missing row headers, we’ll add a test to our weekly accessibility and 404 check script and assist the owners of problem pages.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

At this time we are unaware of any tables on the site with more than one row of header information. Multiple header rows should automatically be incorporated into a single thead tag, however at this time we depend on our users to be aware of table header accessibility issues. Again, if we notice our users are misusing table or row headers, we’ll add a check to our script.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

We do not use framesets on our site, and where iframes are used (rare), they are automatically tagged with titles.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

Our pages should flicker at the rate set by end users (refresh rate). For most users on LCD screens, this should be around 60Hz, though it’s important to note this isn’t something we can control.

(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

As we are unaware of any areas of our site where we’re out of compliance, we’re planning to discontinue our existing text-only site, which was unfortunately often out of data with our main site.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Due to security concerns, the use of JavaScript is actually disabled for Drupal content editors. Javascript is only used as an integral part of two pages: The SAP Calculator and the Tuition Estimator. The Tuition Estimator is provided to us, and thus we’re dependent on the makers of that software to ensure accessibility. Neither page uses JavaScript to render interface elements. Although the SAP Calculator does depend on JavaScript to perform calculations, instructions for calculating SAP independent of the calculator are provided, as is contact information for help if needed.

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

Java is not required to use our website, so applets do not apply. Flash elements should prompt the user automatically if needed.

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

Form elements are automatically assigned names, and labels are automatically created to associate those labels with the appropriate elements. This is a significant improvement, as our old site relied on hand created forms that may or may not have had accessible elements.

(o) A method shall be provided that permits users to skip repetitive navigation links.

The first two links on every page are hidden to most users, but should be read by screen readers. The first will allow a user to skip directly to the main page content. The second will allow a user to skip directly to the main navigation.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

There are no timed responses required on our site.

Additional Accessibility Practices

Proper use of Structured HTML

As part of migrating content to the Drupal site, our content migrators were instructed to insert header tags where possible, providing a structured outline to many pages. This was a dramatic improvement, as many of our old pages simply used bold or large text to denote a new section.

Additionally, we’re developing our pages in HTML5. Although not fully supported by all screen readers, our pages are now marked up with meaningful divisions, such as nav and article, which help screenreaders to automatically find important sections of the page.

Retraining of users

As part of moving to a CMS, all of our content editors were retrained in a series of one to four trainings. Accessibility information was distributed at each of these trainings, and linked help documentation throughout the site includes accessibility guidelines.

Text Size

One common request we’ve had is to increase the default size of the text, in order to make it easier to read. This is actually an unwinnable battle, as the size of the text is actually dependent on a lot of things other than the styles we set. For example, the resolution of your screen has a tremendous impact (I know I have difficulty reading text on my 1920×1080 laptop screen that I didn’t have on my old 1440×900 laptop).

But it is reasonable for us to increase the text size some, as on the whole devices have been increasing in resolution. We will be exploring different options with CSS Media Queries to use a larger size than you may be used to seeing, even after we launch the new site. The most important change we’ll be making is to ensure pages look good regardless of the zoom level you use at home. If you increase the size of the text in your local browser, it should continue to flow correctly on our page, rather than overlap with other elements.

Color Blindness

Although I’m not able to show them here yet (coming in a future post!), we’ve run mock-ups of our new website through color blindness simulators to make sure there’s enough contrast in our content to make it visible to all sighted users. You can get an idea of what we’re talking about online.

Use of Tables

For a long time in HTML, tables were used not only to display tabular data but also to lay out pages, which violates the idea of semantic HTML. Unfortunately, our site was very guilty of this practice. We’ve since removed all the tables that were used for layout, and instead replaced them with appropriate block level elements.

Tables are tricky on mobile devices, as they force a width that will accommodate their contents. We tried a few different solutions, and settled on one that provides an alternate visual layout while preserving the existing table structure, which should allow screen readers to work even from mobile devices.

Because tables can be so difficult, we’ve also sought places where tables were improperly used to list data, and have converted most of those to ordered or unordered lists.

Drupal User Accessibility

Although we are not aware of any accessibility concerns for our users at this time, we also make an effort to improve accessibility for our content editors. Drupal has some accessibility resources, as well as a group dedicated to accessibility concerns that can be helpful. The WYSIWYG editor that our users use to make changes to pages has a similar page for accessibility information. We’ve also made a conscious decision to avoid administrative modules that rely heavily on the use of javascript to provide functionality.

Conclusion

Possibly the most important thing we’ve done is to refocus ourselves around constantly improving accessibility. We regularly share articles about site accessibility with each other, and try to stay current on things like WAI-ARIA. We’ve also started including disability demographic information in our surveys, to get a better picture of our audience. Accessibility factors into every decision we make as a webteam.

As with any other current technology, accessibility on the web is a moving target, changing every year. We do our best to make our site accessible, and try to continually improve troublesome areas. Of course, if you notice something on our site that isn’t accessible, please let me know!

Speeding up Drupal 7

It’s fairly well accepted that it’s important to have a super fast webpage. We’ve spent much of the last two weeks working on our back end design to make the new Lane webpage as fast as it can possibly be. This blog post will be about sharing our results. A few notes before we begin:

  • These tests were conducted mostly on my own laptop, which was busily doing other things, so results aren’t scientific – but it’s good enough for the type of basic improvements we’re going here. On the plus side, this will totally eliminate network effects, since there isn’t really a network.
  • We’ll be testing on the development version of our contact page at http://www.lanecc.edu/contact
  • Some of these improvements are technically still in testing, and thus you won’t see on the main website (yet). Others were actually implemented weeks ago, but I’m rehashing them here because they’re some of the simplest improvements you can make.
  • I’ll be using Firebug to watch the event timeline to see how long things took. This isn’t perfectly accurate, but it’s pretty good for us. And Firebug is amazing.

Baseline

In any testing, you need a baseline. Here’s the timeline for loading the contact page (remember to click on any image to see the full size):

53 HTTP requests over 4.59 seconds

Right away we notice three things – first, that there’s a font that hasn’t finished loading, and which is highlighted in yellow toward the bottom. That’s actually an issue with Firebug, so we can just ignore it.

We also notice that there’s a TON of requests. In this case, 53 (technically 52, since we’re ignoring the font one). When we’re dealing with a local server like this, each of those requests happens super fast. But when we’re dealing with a remote server, like with 99.999% of web requests, there’s a limit of how many requests you can make at one time – always less than 10. So we can get a significant speed boost if we combine requests (You can see some of that limit at the bottom of this post).

Finally, we see a huge purple bar up at top. Any time you see purple in Firebug, that’s when we’re waiting on the server to do something. In this case, we can see that it took about 4 seconds for Drupal to render the page. Surely we can do better!

CSS/JS Aggregation

Our first step will be to combine CSS and Javascript files. We won’t see much of a difference on our tests (things might actually get worse!), but we’ll see a significant improvement on the actual site.

Down to 20 requests

We’re down to 20 requests, just by telling Drupal to combine JavaScript and CSS files where it can. Eliminating 30 requests is actually a significant speedup (Sorry I can’t easily show it here, but you can see other research online).

Also worth noting is the file ‘sprite.png’ that’s listed on there. This is essentially the same idea, applied to images. You can look at our sprite here.

Medium Level: APC

We’re going to skip over the next most obvious method of speeding things up and instead have a look at the Alternative PHP Cache (APC). Drupal is written in PHP, which is an interpreted language. That means that when we process the index.php file, we first turn it from normal PHP code to optcode, which is then run on the PHP virtual machine. APC lets us store (cache) optcode, so that we can skip that first, interpreting step.

The other night, we found that our server was actually freezing on some requests. We had a look at the apc cache, and we found something like this:

A full APC Cache

The circle is all red – there’s no more free memory available for APC to use to cache optcode. Our memory is also fragmented – APC can’t keep things near each other, which is going to make the cache work harder than it should. Together, these two things make us ‘miss’ the cache – on my computer, there were 4200 opportunities to speed things up that we missed. So we simply increased the cache size.

300ms load

Now we’re loading the entire page in 640ms, and it’s only taking Drupal 277ms to get us the page content – less than 1% of the time it took before.

Medium Level: MySQL Caching

The other place to do caching is our database. Some types of requests to the database are really simple, repetitive things that could easily be stored in memory instead of on disk. MySQL provides a query cache where it learns what those things are. By default, this cache is turned off. If we turn it back on:

212 ms for Drupal to load the node

Now Drupal is able to get us that page in 212 ms – almost 25% faster.

Now what?

So we’re pretty quick. But, being programmers, we’re never satisfied. On our actual server we’re also:

  • Minifying additional JavaScript & CSS
  • Tuning our Web Server parameters so that we always have something waiting for your web page request
  • Pushing some resources onto a Content Delivery Network (videos, fonts, some JavaScript), so that they’re shared between multiple websites, reducing the likelihood you’ll need to download them.
  • Running much JavaScript from the bottom of the page instead of the head, so that the page will render in your browser before doing Javascript – giving the appearance of it being faster.
Here’s the timeline from the actual server to my computer, as it is right now:
800 ms

But there’s one more big thing we can do.

Anonymous User Caching

When Drupal renders a page, it needs to fetch information from the database, process a bunch of templates, check user permissions on a ton of objects, and then build the page. Then Apache, our web server, needs to serve that page to you. Apache is a good web server, but it’s a general purpose web server, designed to serve many different languages. There are faster alternatives.

We currently have a server in testing which is designed from the ground up to serve pages as fast as it possible. Pages loaded from that look like this:

 

Varnish gives us the page in 2ms

Our Varnish server is an entire separate server that sites between you and Drupal and does nothing but determine what pages could be stored in RAM as complete pages, ready and waiting for when you want them. In this case, it was able to return the contact page to me in 2ms – most of the rest of the time was spent waiting for other resources – CSS, Javascript, and fonts – to load. Now it’s obvious why reducing the number of HTTP requests would speed up our page  load – those bottom requests would be made sooner.

Varnish posed a special problem for us these last two months while we were testing it. First, it doesn’t do encrypted traffic. For that we have a separate nginx server, which takes care of passing your encrypted requests straight to Drupal. But our second, more fun problem was figuring out how to load test Varnish. My laptop wasn’t strong enough, then our other web server wasn’t strong enough, and then a set of 5 other machines on the same network weren’t strong enough. Varnish was able to handle thousands of requests per second, and not even blink.

Finally

Thanks for sticking with me this long! Except a much faster web site before the end of the month, as we finally turn on Varnish for the rest of the world. And we know there’s still work to be done. Our next design should feature fewer requests and less JavaScript, letting your page load and render just a little bit faster.