I’ve been busy the past few days making some major changes to the catalog. Hopefully, you didn’t notice. You might have seen a few moments here or there where the border disappeared from the public 856 view, or the font size changed in a results page, but most of the work I’ve been doing has been behind the scenes, changing the way the catalog loads the assets that make the page run.
tl;dr: the catalog now requests fewer files and loads faster. Also, I have some ideas I’d like your feedback on.
Here’s a breakdown on what I’ve done so far, as well as some other changes on the horizon that might be a bit more noticeable (although hopefully not too much).
headOur catalog is sort of like a huge Content Management System (CMS) designed by Rube Goldberg with a spastic colon. It manages to make public web displays of all of the content we curate in our Integrated Library System (ILS), building basic system-generated templates so that most of the pages look the same. Unlike most CMSs, however, exactly how and why some of the templates work the way they do is not clear. Sometimes the catalog adds the page’s head information, and sometimes it doesn’t. It almost never adds a page’s Doctype on its own, which makes many versions of Internet Explorer do all sorts of wonderfully wonky things with the pages it generates. But when it does add the head, it loads a whole bunch of overlapping CSS and JavaScript files, which slow down the speed at which the page is displayed to users.
Thankfully, there is a trick to having more control over how browsers load these necessary JavaScript and CSS files, something that I’d tried before (without success) but which I rediscovered this week in an old presentation by Brad Czerniak, formerly of the Canton Public Library. (He also has a very detailed blog post about improving catalog performance, which helped me structure my plan of attack.)
The trick is that you open an HTML comment right above where the system generated head will be, and then close it right before adding your own head. The trick was moving the closing comment inside of a duplicated Doctype so that the trailing comment won’t display on pages that don’t have system-generated information. The hack has five steps:
In Web Options, add a Doctype and opening HTML comment to the INSERTTAGHTML field. I used an HTML 5 doctype, since it’s short and simple. We have INSERTTAGHTML = ‘<!—’ in our setup.
Still in Web Options, turn off a bunch of the options for including things in the system-generated head: INSERTTAG_INHEAD, STYLESHEET, etc.
Open Web Master and edit the toplogo.html file, adding the following as the very first line of the file: <DOCTYPE html -->. Then include an <html> tag and all the head fields you need, including the CSS you want to load.
Go through all the html files in Web Master and remove any hard-coded head elements. Instead, load the toplogo.html file using the III token: <!--{toplogo}-->.
Edit botlogo.html and add in the JavaScript files you want to load right before the closing body tag. Since these files block page rendering, loading them after the rest of the page has been loaded will give a perceived speed boost to your patrons.
Now I was controlling the files that were loaded into the head and I had moved the JavaScript files to the end of the document, but there was still room for improvement. By default, III loads their own JavaScript library is three files. I manually created a single JavaScript file of all their functions and minimized it, and then did the same for the custom JavaScript I’d written for the catalog. Now I was able to load just 3 JavaScript files: the stock JavaScript file, the jQuery library I use for some of the more radical changes I make to the system-generated interface, and my own custom JavaScript.
Since I was now maintaining a few custom JavaScript files, to make it easier to maintain these assets for the catalog, I created a new Git repository called opac, where I could store all of our opac assets.
CSS was a bigger mess. III loads several CSS files by default, as part of the template they provide. Then I was loading the base stylesheet maintained by the GVSU web team to help make the look and feel of the catalog match the pages in our CMS. Then there was a bunch of inlined CSS that has been part of the CMS template for years, setting navigation styles. Finally, I was loading the custom GVSU Library stylesheet which builds upon the base CMS stylesheet and contains our pattern library, which helps us maintain a consistent look and feel across all our sites.
To improve performance, I needed to load just a single stylesheet, but I didn’t want to start maintaining a custom stylesheet for the catalog that included content from the CMS. Every time the Web team updates the CMS stylesheet, I want the changes to populate to all of our tools. There are a lot of tools that help you build minimized CSS tools on the fly as the page loads, but we don’t have the infrastructure for that. So instead, I built a simple tool that lets me have it both ways: I can load a single, minimized stylesheet in the catalog while still pulling in changes from the CMS stylesheets, the pattern library, and more. (If you want to learn more, it’s available on Github.)
Now I was able to go from loading 6 different stylesheets on three different servers to loading a single, minimized stylesheet from one place. This made a huge difference in the speed of the site.
In the process, I ran all the CSS through CSSLint and resolved a lot of problems, including over 135 font-size declarations (!!).
Since I’m now loading all the CSS and much of the JavaScript for the catalog from our production server, I configured it to send all the files compressed to save additional bandwidth and speed things up. Once I’m done doing a lot of this tweaking, I’ll also tell the user’s browser to cache these files for a while so that they don’t need to reload them all the time.
While I was tinkering with the system I made a number of changes designed to improve the site’s usability for folks with that use assistive technologies. These changes were mostly semantic or descriptive: adding title attributes where necessary, adding an h1 element around the University Libraries link, ensuring that all images had appropriate alt attributes, and adding ARIA roles where appropriate. I’m still in the early stages of this, and III’s reliance on tables for layout (generated by the system) has made this a challenge. I’m also working on making all of the forms accessible by ensuring that each input is appropriately labeled. (Not a single checkbox in the whole app has a label or title attribute, and none have unique IDs which makes retrofitting them a challenge.)
This is an area where I will continue to work, especially since as a State University, we must comply with Section 508 of the ADA for all of our tools. (Its boggles my mind that library vendors don’t do this for us with the amount of dough we throw at them.)
In the next week, I’m going to start working on the last big performance hurdle for the catalog: images. Every link in the catalog is a button image, and each of those images has to be loaded from the server. Sometimes that’s 15 or 16 requests, and even though they are relatively small, they have a huge impact. When I redesigned the “My Account” screen last month I switched all of those buttons over to text links with CSS styles. They still look like the old buttons, but they are missing the little image next to the text. I’m not sure how useful those little icons are, but as I move to switch the rest of the buttons on the website over to text links, I’ll be adding in those little icons again.
I’ll do this by creating a single image that contains all of the little icons, called a sprite. The user can then load that single image (and cache it for a while) and then I’ll tell each button which of the little icons to display next to the button. This has the benefit of lowering the number of images we need to load while still making the catalog look pretty much the same.
I’m also proposing that we change a few other things in the catalog, but that’s down the line. I’d love to hear your thoughts on these:
There are also some long-term things on the “want list” folks have asked me about for years:
What else would you love to see from the catalog? What do you use that you can’t live without? Let me know!