Cache Busting in OUCampus

The Cal Lutheran website runs on Google’s Pagespeed Apache module to automate certain cache settings, CSS rewriting, image compression, and a host of many other page loading performance related enhancements. Since CSS stylesheets are generally considered to be static assets on a site, they aren’t expected to change often between user visits. This is where PageSpeed’s caching and rewriting helps us with getting that critical above-the-fold CSS delivered to the browser. If a page is not yet cached by PageSpeed, it will load a javascript on the client side to analyze what CSS declarations are likely to be needed to paint the page above the fold. This chunk of CSS code is then injected in a style tag at the top of the page. Every subsequent reload is pulling from that same cache. This greatly helps with page performance as the first visible CSS is loaded immediately.

This works great until you need to push out a new change to a stylesheet. While the cache does have a timeout until the next refresh, there are times when you need to force out an updated stylesheet out to visitors. The first way to do this is to add an additional parameter to the filename, such as styles.css?v=1. The browser will see this as a new file and be force to make a request to the server for a new version. Making additional changes on that version number will continue to force new versions, however this isn’t exactly sustainable to manually update every time.

How can we automate this in OUCampus? In our main XSL file used for template transforms, usually common.xsl or template-matches.xsl, I added a template match to catch all stylesheets requested off our own domain and append that version parameter to the filename. Instead of incrementing a number as I mentioned above, it is using the current timestamp as of publish as the versioning number. e.g. styles.css?v=4-29-19

Formula One 2019 on Behance

In 2019, Formula One called on the team at |drive| to augment the F1 brand and refine the opening title with a more “race day” approach to our original concept. Our team recognized that the most emotive way to inject team-like color into the driver sequen…

Source: Formula One 2019 on Behance

Love seeing the iterations of the graphic style of the new F1 intro. Bringing up the identity of the drivers has been a big thing Liberty, the new owners of Formula 1, have been emphasizing.

The Bones of the Web

My grandfather was a mechanic who worked on ship engines in the Navy, cars, and later airplane engines. In his time, a steering wheel was turning a rack and pinion by the force of the driver and the engine timing was controlled mechanically. Fast forward today and look how much computers control every aspect of a car. The engine timing is controlled electronically, the inertia created by the brakes send power to a hybrid’s battery, and drivers are assisted by lane guidance and GPS. A old Jaguar from the 1960s he worked on is a far cry to today’s modern Tesla.

Any new functionality brings complexity. With that complexity, we become further removed from the original bones of that technology. A car from the 1960s and today share many common bones: four wheels, a seat for the driver, a steering wheel, and pedals. However, it is clear that there is an evolution between then and now. Add computerization and the driver is further removed from the actual mechanical movements making the car operate.

The web development world has seen this shift as well. The bones of a web page have always been based around HTML, CSS, and Javascript. Developers from the early Wild West era of the 1990s were writing every line of code by hand, one page at a time. Later come tools to manage pages and separate the content from the templates. Web standards and CSS allow greater expression of how the content is displayed. Javascript and AJAX give greater functionality on the front-end. Everyone of these layers takes developers further away from the bones of a web page.

This takes us to today with modern frameworks like React and JSX to do the work of writing HTML and CSS for us. Node JS-based tools like Gulp, Babel, and Webpack do the heavy lifting of managing dependencies and transpiling code into other code.

There are so many more things we can do in a web browser today, more so than Tim Berners-Lee could have imagined, but it is important for any craftsman/person to deeply understand their craft. Remember what the bones the web are when you are working in a dozen layers of abstraction away from the HTML.

Web Components will replace your frontend framework

Source: Danny Moerkerke: Freelance full-stack Javascript developer

Web Components look really interesting, but I don’t think I will drop everything to start implementing it quite yet. There is something really satisfying about a self-contained chunk of code that can be reused into project.

Edge Goes Chromium: What Does it Mean for Front-End Developers? | CSS-Tricks

In December 2018, Microsoft announced that Edge would adopt Chromium, the open source project that powers Google Chrome. Many within the industry reacted

Source: Edge Goes Chromium: What Does it Mean for Front-End Developers? | CSS-Tricks

Adactio: Journal—Split

Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

Source: Adactio: Journal—Split

This is exactly the kind of thing I have been thinking about with the growth of today’s web development workflow. Jeremy Keith has such a great way of hitting the nail on the head when raising big issues in the web development world.

Testing 1, 2, 3…

Is this thing on?