Here at VIA, we believe web performance optimization (WPO) is essential for all websites. But some may wonder: is performance really important for 

 website? How can I tell if my site performs well? And how can I fix it? Let's discuss.

A poor-performing website can impact your customer’s experience with your brand. It can reduce conversion rates, affect the perception of your brand, and even cost your customers time and money.

In this article, we will explore what a “performant website” is, how a poor-performing website costs your business and your customers, and steps you can take to improve your existing website’s performance.

Finally, we share a case study about how we used this work to increase a client's website's revenue by +16%!

What we talk about when we talk about performance

A performant website loads quickly and is immediately interactive.

The site takes multiple seconds to begin displaying content.

Content starts appearing quickly but trickles in slowly.

Content appears to be loaded, but nothing is clickable yet.

A performant website loads only the required assets, which should be tailored to the user's device and preferences.

A performant website displays its content without shifting its layout as sections load in, responding to user input without delay.

Now that we've established web performance, you may wonder why it matters. "Sure, a fast site sounds great, but so does a fast car, and my [insert affordable family car] serves my needs just fine. Does my site really need to be blazing fast?"

 generally involve supporting users with physical or cognitive disabilities, but a user's socioeconomic status is also a concern. Users with low-powered devices or slow internet connections are the most impacted by poor web performance. Someone with a fast device on a fast network may not notice that a site has a large Javascript bundle or unoptimized images; someone without either may not be able to load it at all. And for those without unlimited data, accessing an unoptimized site may literally cost them money.

Optimizing a website's performance will make it more accessible to users on any device.

Time is Money: The Business Value of Web Performance

, WPO expert Tammy Evert opens by observing that "performance is very much a human issue." She shares a concept called "web stress" and points to research suggesting that using a slow website can actually increase your blood pressure. We will touch on the business implications of this shortly, but it's important to consider that we have a responsibility to the people who use our products. We should be respectful of their time and health, and we should also try to give them a good experience whenever possible.

It's important to note that a fast website alone does not make a happy user. A fast site with a confusing layout can still frustrate a user; its design is a significant part of the user experience. Even the best design is simply an attempt to mitigate a user's stress level when finding information or looking for a product. Slowness or other interruptions only add to that stress. The combination of a good design with no performance issues can create a happy user or at least one with a little less stress than before.

Here's Everts again: "When users are happy as a result of a fast website, they're more likely to follow calls to action telling them to register, download, subscribe, request information, or purchase." Note the variety of actions here. Happy users simply *do* more. Regardless of your goals for the site, it is more likely they will be met if your users are interacting with a performant site.

, where Everts and Tim Kadlec of WebPageTest (more on that later) curate web performance success stories. While you might expect large companies like 

Yelp to see improvements in their conversion rates by reducing load times

online dress retailer seeing a 30% conversion rate increase by moving to a faster eCommerce platform and optimizing images

. Performance improves results for businesses of all scales.

, a collection of metrics for measuring a site's performance and user experience. We'll discuss these metrics in the following section, but here's the critical thing to know here: 

in 2021, Google incorporated the web vitals into their search ranking algorithm

SEO and WPO are now intrinsically linked.

If you are doing the work to optimize your search rankings with searchable content and keyword tracking, but you are not optimizing your site's performance, you are missing a huge step.

You might wonder: "So performance is important, but how can I tell if my website is performant?" There are two ways to measure performance at a high level: field data and automated testing.

The absolute most effective way to tell how well your site is performing is to see how actual people are using it. This can mean:

Asking users for permission to record their usage

It is obviously not practical for everyone to bring in actual users for observation, which is why we have automated testing. Still, it's important to remember that automated tests are just 

As discussed above, Google's Web Vitals are metrics designed for measuring page performance, and while other metrics exist, these are the standard measurements across the web.

There have been a few variations, but these are the three prevailing metrics at the time of writing:

: how long it takes for the largest visible image or text block to load

: how much the content moves as it loads in

: how long the main Javascript thread is blocked by executing code, preventing user input

 is a tool made by Google for measuring website quality. It predates web vitals and tests for more than just performance, scoring on accessibility and best practices. Its results can vary from web vitals a bit, but the slightly different approach makes it a good complement to the basic metrics, and it's easy to run: just open the **Lighthouse** tab in the Chrome Dev Tools.

 is a tool that incorporates everything we've discussed so far. You can provide a URL and schedule a test that does the following:

It is the absolute best place to start if you want to get a sense of your site's performance.

You might have run a WebPageTest and been overwhelmed by all the data you're presented with. Now that you have it, where to begin?

Here are the most common problems on a site and how to fix them.

To reduce file size and improve Largest Contentful Paint:

Restrict the image dimensions to the dimensions at which it will be displayed on the page

Use multiple image sizes and `srcset` to only deliver the image size needed by the device

Set `width` and `height` attributes on the image so the browser knows how much space to save for it

When analyzing a request waterfall, you may notice that some important files, like those with critical CSS, are blocked by less important requests, like Javascript, that are not needed until the content is ready. There are a few ways to improve this.

 to optimize the order of `<head>` elements.

Move `<script>` tags to the end of the body and/or use the `async` or `defer` attributes

Loading a large Javascript bundle can block the loading of content and extend the Total Blocking Time, which prevents user interactivity. Take steps to deliver the minimum required JS.

Include only the most essential analytics scripts

, recently asked us to audit their site parts eCommerce website, 

. We had just added some new features, like Algolia autocomplete in the search and a dynamic Parts List for users. We wanted to take a step back and ensure everything was as optimized as possible without changing functionality or architecture. We did not build the site originally, so we also saw it as an excellent opportunity to better understand how things were structured.

We ran a WebPageTest and found that there was room for improvement. Emulating a 4G network connection on mobile, we got the following results:

It also identified a large number of uncompressed images, and ct.css determined that several critical assets were loading out of order.

Lazy-loaded all background images below the fold (i.e., not in the viewport on the initial load before scrolling)

Deferred the loading of all hidden images (e.g., images in the navigation's mega menu dropdowns)

Resized and compressed all background images

For the hero image above-the-fold, used Cloudinary's API to generate resized copies for each device breakpoint to avoid loading the desktop-sized image on mobile

Re-ordered the `<head>` elements and added `defer` to the Javascript scripts

Audited the Google Tag Manager and removed some unnecessary tracking tags

After all of these updates, we re-ran the test and found that we had cut both the LCP and the TBT in half (LCP: 3879ms (-57%); TBT: 4414ms (-48%)), and the site was noticeably faster for our QA testers.

The effects of these updates can be measured by more than just improvements in site speed and performance. In the 3 months following the updates, the website’s performance with user engagement and business goals also improved.

In the three months after making these updates, site users viewed an average of an additional page per session, and the average session duration increased by nearly 30 seconds!

In terms of revenue, site revenue increased by +16%, eCommerce conversion rate increased by +39%, and average order value increased by +24%.

HTML, CSS and Javascript form the "presentation layer" of modern web development in your mobile and desktop browser. These things together are considered "Front-end Development". The tools, techniques and standards are changing all of the time - but our development team is always staying abreast of the latest. For our partners, we do the research, experimentation and testing needed to make sure your audience has an accessible, fast, reliable experience.

Frontend Development

Search Engine Optimization isn’t just a buzzword - it’s a mindset. We think strategically about how we write and develop our websites to provide useful, informative user-facing content that provides maximum search engine value. Using the latest analysis, tracking and reporting tools, we keep your website and its content ahead of the curve and atop the search rankings.

Your Website's Performance Could Be Costing Time and Money

The old viastudio.com website launched nearly a decade ago atop of Wordpress - our go-to custom website development platform. 

But much has changed in those ten years in web development - and the goals we had for the

We wanted something that would create a unique, elegant, interesting user experience, delivered "scary fast"  - that was also easy to develop and maintain.

We love Wordpress - it has been and remains our go-to for custom website development. In order to achieve our user experience and development goals for the 

, we found that they aligned closely to the offerings of the JAMstack: static markup, delivered fast and enhanced with Javascript. This is commonly known as a "headless" content management system (CMS).

There are many JAMstack CMS options- including using Wordpress in a "headless" mode. But would that fit our needs?

JAM is part of VIA Studio's web development process.

Read How We Customized the Sanity CMS

The biggest challenge was moving our data from WordPress to Sanity, mainly our blog posts going back years. Fortunately, we were able to write a tool using PHP and Node to convert all of our WordPress data into a format that we could import into Sanity.

Read About Our How We Migrated Our Content

For a framework, we had two main options: Gatsby and Next. For me, the choice was easy. While Gatsby offers a theme and plugin ecosystem that resembles Wordpress’s in some ways, Next’s ability to dynamically work as a static site generator or a server side rendering framework on a page-by-page basis is a huge win. We had recently tested it out on our 

 and were immediately impressed. In the time since that project, Next has rolled out features like the incremental static regeneration which means that we can generate our featured case studies at build time, generate additional case studies at runtime when they are requested and also create server-rendered landing pages that can take advantage of A/B testing, cookies, etc.

Next also introduced API routes, which means instead of relying on a full custom server for things like form handling, we can just create a file at “api/form,” and Next will generate an API endpoint for us where we can run server-side code while doing everything else on the client.

Using a React framework also enabled us to take advantage of libraries like Framer Motion, which provides physics-based animations that give layout changes a more natural, playful feeling than duration-based CSS animations.

Vercel was our first choice for hosting because it supports Next out of the box as it is built by the same team. But more than that, they provide a great development experience. We have our project set up as a monorepo, for which Vercel recently rolled out support, which means our CMS and frontend are two separate packages that we host in one repository, and they each have their own project in Vercel with continuous integration through Github. Any time we open a PR for one of the projects, Vercel creates a preview deployment where we can view all the changes just how they will appear in production, and when we merge it into our “main” branch, a new production deployment is created. And if anything goes wrong, we can easily roll back to a previous deployment.

While we always work closely with the design team throughout the development process on a project, we often don’t get involved until fairly late in the design process. For this project, the goal was for design and development to collaborate on the design system and build it from the ground up, with an emphasis on componentization, since we knew we would be building the site with React.

Before design even got started, we got to work on the foundation of the design system. Inspired by the layout primitives in Andy Bell and Heydon Pickering’s Every Layout, we created React components for basic layouts that can be truly modular and intrinsically responsive, so we could use them all throughout the site. My favorite is The Switcher, which switches directly from a row to column layout with no breakpoint and no awkward in-between wrapping states with orphaned items.

To help with testing these primitives and collaborating with design, we built our components in 

, which enabled us to isolate components, visualize variants, and test responsiveness and accessibility. With this workflow we could develop layout primitives individually and share them with design; then design could construct layouts with these primitives in mind and hand back components, we could build those in Storybook and have them reviewed and incorporated into full page layouts, which we could then build in our Next.js app. This workflow brought design and development much more in sync and enabled a more efficient back-and-forth compared to a more standard hand-off where development begins after design has already completed the full page layouts.

Example content wireframe for a customer testimonial.

VIA Studio designs web components for fluid application.

Testimonial Wireframe

Content space examples for large space and right justified imagery.

Behind the scenes look at the new VIA Studio website.

Website Layout

The most exciting thing about our new site is what’s yet to come. Moving to a modern stack has opened the doors to all kinds of new ideas and experimentation. We’re only restricted by our imaginations.

We are extremely proud of what we were able to build and are excited to continue work on improving the site for our employees, clients and friends over the coming years.

While we have wide and varied development expertise and experience the core of our development skill is with PHP, Javascript, Vue and React, allowing us to maintain and develop new features for 80% of all websites on the Internet. That said, we regularly explore new and useful platforms to stay ahead of the ever-changing development curve.

PHP, Javascript & React

Custom Dev

Developing the New via.studio

As a front-end developer in 2020, it is time that I fulfill the FEDeral mandate that I publish words regarding the JAMStack. If you follow too many developers on Twitter, it’s likely you’ve heard about the Next Big Thing in web development, but I’d like to put this trend (fad? movement?) into context to better understand what’s truly new about this approach and whether it’s worth using.

VIA Studio uses the JAMstack to build user-friendly websites.

JAM Web Development

What even is a stack? You may have heard the term “full-stack developer” and know it refers to someone who does both frontend and backend work, but what is the actual stack? A stack — in the web development world — describes the combination of tools being used to host, serve and render a web project. Traditionally it has four components: an operating system, a server, a database and a programming or scripting language.

Let’s look at a couple notable stacks in recent history.

The LAMP Stack comprises Linux, Apache, MySQL and PHP. This is 

 stack of the early 2000s, and due to its ubiquity it will be around for many years to come. Notable LAMP sites — include Facebook (which has since migrated away), Wikipedia (technically using MariaDB rather than MysQL, for the record) and Yahoo (remember Yahoo?). Most importantly, though, is Wordpress, which powers something like thirty percent of the web and is almost certainly the biggest reason for the average person to build a LAMP stack site in 2020. Because of its history and popularity, though, there is a huge community of developers with LAMP knowledge, and it’s very easy to find affordable hosting from almost any provider.

As you may have noticed from the lack of an acronym, this is not a stack per se, but it is a highly opinionated web framework that became a popular alternative to the LAMP stack architecture in the mid-to-late 2000s. It is database agnostic, so you could still use a MySQL server, but Rails itself generates models, controllers, tests, database migrations, etc. and famously enforces the Rails method of application building. Github is a notable example of a Rails site. To this day, if a company is building a monolithic server-based website, it will likely choose either Rails or a framework it’s inspired, like Laravel for PHP.

Arguably the JAMstack of 2014, the MEAN Stack comprises MongoDB, Express.js, AngularJS, and Node.js. As is apparent from all those suffixes, this stack is JavaScript all the way down. The advent of Node.js, a Javascript environment that allows the language to be used anywhere, not just the browser, opened the door for a new era of web development where the full stack could be written in one language. Innovations were being made on the backend with NoSQL databases like Mongo, and the Javascript framework wars were beginning with Google’s Angular and Facebook’s React. (At the time, Angular had the edge. Since then, the frontend community has largely unified around React as the framework of choice, which contributed to the decline in popularity of the MEAN Stack.)

This is very much not a stack but feels worth mentioning as it’s a trend that feels transitional between the MEAN Stack and the JAMstack. With the popularity of React and its tool Create React App, as well as libraries like React Router, a client-side routing tool, many developers began creating sites that were completely client-side: a single index.html with a React application container that simulates a multi-page application without any server-calls or page changes. But while this is useful for interactive web applications like drawing tools, for more traditional websites it meant abandoning server benefits like SEO and resulted in extremely large Javascript bundle sizes.

From a stack perspective, the OS has been replaced by a CDN, the web server has been replaced by serverless functions, the database is optional, and JavaScript is the only required language. Like Ruby on Rails, this approach relies one one tool: the static site generator.

A static site generator is a tool that pre-renders web pages from a combination of markup and Javascript and will usually also perform code-splitting and other optimizations on the codebase. By pre-rendering the pages, the files can be served statically from CDNs rather than having to be rendered at runtime by a web server.

There are many tools available, depending on your language of choice. For true versatility, use something like 

 to take any type of markup — Markdown, Liquid, plain old HTML — and generate static pages without the need for a Javascript framework. Similar tools are 

For those who have a Javascript framework of choice, each big framework has its own choices for SSGs. For React, Gatsby is a popular choice for generating static pages from a React application and has an ecosystem of themes and plugins to choose from. NextJS can do the same but is notably more than just an SSG. On a page-by-page basis, it can either generate a static page or server-render it, providing extra options for those who want the speed and simplicity of static pages without sacrificing the benefits of server-rendering for pages that need it.

The core concept behind JAMstack is that almost any functionality you would need from a server has an API available already. Need CRUD for your MySQL database? Use 

 to generate a GraphQL endpoint for it. Authentication? Use 

. CMS? Well, that’s a whole other blog post, but 

. These are usually referred to as "headless" services, as they have been decoupled from the front-end.

For anything else, use Netlify’s serverless functions or NextJS’s API routes to spin up a little endpoint that handles what you need on the fly.

So should you start building all your sites with the JAMstack? As always, It Depends. Let’s take a look at some of the key decision points.

Static sites are extremely fast. Pages. Unfortunately, they can be very slow to build. If a site has thousands of pages, an SSG generally has to generate every single one of those pages every time the site is built. This can take a long time and severely hold up deployments. Fortunately, features like NextJS’s incremental static page regeneration allows for a hybrid approach where some pages can be generated at build time and the rest aren’t generated until they’re requested.

Some may also argue that static page speeds can be replicated by simply putting Cloudflare’s CDN in front of a Wordpress site, for example, but it’s nice that the speed is there out of the box rather than requiring the setup of a CDN or caching solution on top of the site build.

A common complaint about Wordpress is that they are vulnerable to hacking attempts. This is not so much a problem with Wordpress itself as it is with the fact so many websites are built with it. But the reality is that because JAMstack sites don’t have a server, there isn’t really anything to hack into. And because data fetching can be done in serverless functions, you can also avoid exposing API tokens like you might in a fully client-side site.

On the other hand, you have to put a lot of trust in the services you’re relying on, especially for e-commerce, so it’s important to vet all of your APIs and not rely on the lack of a server for solving all of your security problems.

This is arguably one of the largest benefits of the JAMstack. Static site generators generally have great build tools that enable features like fast refresh, code splitting and ready-made development environments. There is generally very little setup required to get a project started, and libraries, APIs and build tools can be added as needed, if needed. Frameworks like NextJS will handle things like Webpack and Babel configurations, routing, and enforcing best practices for front-end development, freeing up developers to Just Write Code. The only risk here is getting greedy and simply writing too much of it! It’s tempting to use every library out there and end up serving way too much Javascript. But when used responsibly, you can painlessly create great front-end experiences.

Monolithic approaches like Wordpress, Ruby on Rails or Laravel are still extremely useful for developers or teams with a need for fully custom backends or simply want to use a tried-and-true approach with endless resources and hosting options. For developers who want to quickly spin up fully custom marketing sites, ecommerce shops and blogs to deliver rich frontend experiences without needing to build custom servers, the JAMstack is an exciting new methodology that provides great experiences for both developers and users.

Websites are the cornerstone of marketing in this day and age. Your website is the place where you have ultimate freedom to express your brand and interact with your audience and customers how you’d like. Using agile, user-focused strategies and design, we build highly accessible, highly useful websites that meet your goals.

Websites

What's the JAMstack?

 is a plugin that allows Wordpress to render files written with 

, a PHP template engine. We built a recent project with it and found that it greatly simplified the theme-building experience. Let's dig into why Timber is so useful for building Wordpress sites and how you can get started with it.

If you’re a Wordpress developer, you’re probably familiar with this:

™️ in use. This is how we access a post in a template and make its data available for rendering. You'll notice a few things common to most Wordpress templates: switching between PHP and HTML code frequently to access and arrange data, calling several Wordpress functions to check for the availability of and access post data and using Wordpress functions to render HTML.

Here's how we can do the same thing in Timber:

Ooh! At a glance, it's much easier to read, but let's dig into some of the benefits of using Timber: improving the readability of template code, separating data accessing from our templates and generally offloading a lot of the tedious work of Wordpress.

And that’s important! I’ve been building Wordpress sites for a little while now, but every time I open a Wordpress template file my brain shuts down for a second. It's usually either a mess of interspersed PHP and HTML blocks with Wordpress functions that seem to span entire lines of code or the mess has been abstracted into other files that you have to dig through to get a clear picture of the architecture. Both of these scenarios make it difficult for a developer who’s new to the project (or yourself after going on vacation!) to understand how things are set up and get to work.

A big contributor to the clunkiness of Wordpress templates is that the data fetching and arranging are being done right alongside the templating. In Model-View-Controller terms, the template file is acting as both the controller and the view.

Timber allows us to use the PHP files as controllers that fetch and arrange the data and then pass them as variables to the views: Twig files.

In the example above we only need the post object, which as we'll see later is often available automatically. But what if we need derived data? Let's say we have a Product post type, and on a certain page we want to display all of the products, as well as all of the categories and the lowest price item.

In traditional Wordpress, we would need to write and run all of these queries and make the necessary calculations inside our template alongside the actual display code. This can result in messy files with business logic interspersed in our view. But in Timber, we can grab all of this data and simply pass it to the view as variables, so we don't have to include any query code in the template.

Now in our Twig file we can simply reference {{ cheapest_product.meta('price') }} and not clutter up the view with any math.

As we've seen, we don't need to bother with The Loop anymore! We can grab the data we need in the PHP file and treat them like normal objects in the view.

Often, the post is the only object we need in context, so we don't even need to write PHP files! By using 

, we can just use page.php as a catchall, so we can just create a page-example.twig, and it will be routed through the already existing page.php and automatically get the post object without us having to do anything!

Timber also adds other shortcuts for doing basic Wordpress things. For example, there's no need to remember all of the Wordpress functions for accessing different post data. Instead of remembering whether it's get_the_thumbnail() or get_the_post_thumbnail() or if you actually need wp_get_attached_image() or maybe get_attached_media() — quick quiz: which one of those doesn't exist? — you can just call {{ post.thumbnail }} anywhere in your Twig template. No need to remember all those functions! And if you ever forget what data is available in the object, you can just use the debugging tool covered below to easily find it.

Random Cool Things Timber and Twig Can Do

Let's take our single.twig example above and convert our featured image to webp on supported browsers and to JPEG on non-supported browsers.

If you use ACF, working with Timber is an absolute dream. Let's say we have a page with a Repeater field that contains an indefinite list of employees: an image, a name and an email.

The resulting field will be displayed on the Employees page for data entry. Now to render the content in the page. How would this work in PHP?

Again, no need to worry about remembering function names! All of our ACF data is stored in the post's meta property, and the repeater is just an array that we can loop over.

Ever get stuck trying to figure out what exactly is in a variable you're working with and try the ol' var_dump($variable); die(); only to be presented with a page-long string of characters that allegedly contains the value you're looking for?

An unwieldy output from PHP's var_dump function

, simply calling {{ dump(variable) }} will output a nicely formatted block of code to investigate. This is great for debugging the data that's available in a template's context. And nothing has to die()!

The nicely formatted output of Timber's dump function

So you're convinced! Where to begin? Let’s assume we’re starting from scratch. While Timber can be installed and applied to an existing theme incrementally, beginning with the starter theme will get you up and running very quickly and help you learn the fundamentals you’ll need to start picking and choosing which pieces you want to use.

First, make sure you have a Wordpress installation. Then, grab the 

. Download it, unzip it, and add it to your wp-content/themes directory. Now run composer install in the theme to install Timber.

Note: While Timber can currently be installed through the Wordpress plugin directory as well, that option will be removed in the upcoming version 2, so go ahead and get comfortable with the Composer method.

Now activate the Timber plugin and then the theme, and you’ve got a working Timber installation!

You already have pages here that should be getting post data. Now let's create a custom page. In Wordpress create a new page named My First Page. It should have the slug my-first-page.

Now create the file page-my-first-page.twig. Copy the contents of page.twig over, customize as you'd like and now when you visit My First Page you should see your template!

You can now start adding content and ACF fields and render them in your new template. 

 for additional options for setting this up.

We strongly believe in open-source technologies. Our CMS of choice is WordPress, not just for its ease-of-use, but the large community that pushes its development to new and exciting places. Active in the Wordpress community, we also develop 

WordPress

Building a Wordpress Theme with Timber

There are three people to keep in mind when writing code: the user, the client and your future self. For the user you need to build something accessible and intuitive, for the client something on time and under budget and for yourself something you can come back to in two months and easily update.

This last goal feels obvious, but when there are deadlines involved, organizing code is often the last thing on a developer’s mind. And when it comes to implementing a design as a front end developer, this usually means tacking more and more CSS rules into ever-growing files and more and more 

Here at VIA we often continue working on sites after launch. Clients may want to polish parts of the site, fix things that break (it happens!) or add new features as their needs change. So we want to write code that we can confidently dive back into, find what we need and add or update without fear of breaking anything.

Here are a few strategies to implement reusable and maintanable styling.

In programming we have the DRY principle: Don’t Repeat Yourself. The idea being that, in order to both write less code and keep it maintainable, you should use functions or abstractions wherever code can be reused. The same mindset can be used in design. Rather than treating every page or section as a separate piece, designers can create reusable components to be used throughout the site.

For example, most design systems have a card component. In Google’s Material Design, this is a rounded box with a headline and some copy. And then variants can be chosen: elevated, outlined, with media, with buttons, etc.

When implementing a component-based design as a developer, this structure should be maintained as closely as possible. The simplest option to start with is to work with a Javascript framework or library like React, Vue or Svelte. (Or Angular, if you’re still into that!) These tools allow you to actually split your code into reusable components that you can drop anywhere in your code. This makes it extremely easy to mirror the design system structure in your code.

So we’ve organized our markup into components. Where should we put our CSS?

BEM and ITCCS are two separate CSS methodologies; BEM focuses on naming and organizing selectors, while ITCSS covers the organization of files, roughly speaking, so they work best in tandem.

BEM stands for Block, Element and Modifier. To put it in the language of components that we’ve been using, a block is a component (e.g., 

), an element is a piece of the component (e.g., 

) and a modifier is a variant of the component (e.g., 

The main principles of BEM are to allow block styling to stand on its own and keep all of the styling at the root level, so we can prevent confusing cascades and specificity wars. It also helps visualize how the pieces of a component relate to each other, so code is more immediately understandable.

ITCSS, or Inverted Triangle CSS, is an approach for managing the cascade. The triangle is the one below, which establishes a hierarchy for your selectors.


Here’s an example of what the main CSS file might look like when using ITCSS:


This might look familiar to the way you might structure a large CSS file, with global selectors at the top, moving down to more specific ones. But by explicity organizing your code into files and folders this way and enqueuing them in this order â especially used in tandem with BEM â you can ensure that all of your styles are being applied in exactly the order you want them to be, and know exactly where you should make any updates down the road.

For projects built with a Javascript framework, including CSS within the actual components is a great way to keep your styles right next to the code they’re affecting so there’s no need to go hunting for the selectors you need. There are about 12,000 libraries for this: if you’re using React you could use Styled Components, Emotion, styled-jsx, JSS, etc. Any one you choose will get the job done, really, so don’t sweat it too much. The main benefit here is that the styling can have access to your component state and props. Here’s an example of a component using style-jsx to conditionally apply styling based on a prop:


If you prefer your styling to be even more tightly coupled with your markup, consider Tailwind, a CSS framework that provides utility classes for styling your code without even writing CSS. While many may feel that styling with utility classes clutters up markup, it does help keep the styling right alongside the markup its affecting, and even moreso Tailwind allows you to work within the constraints of your design system. While you have the option to use custom CSS, having your designer work with the set colors and spacing available within the framework, or creating your own constraints, help you incorporate your actual design sytem into your code.

We used Tailwind on the recently launched 

 and found the option to apply styling without having to leave the markup extremely useful when creating page templates. Here’s an example of a Laravel Blade template applying styling to a card group (and note the use of a partial view!):


In this case we’re applying styles like 

. This way we don’t have to make up a class name like “card-link-container” or use a selector like 

 that could break if we reorder the markup.

Using Tailwind alongside a tool like PurgeCSS also allows you to remove all of the unused styling during the build process, so you don’t ship any of the framework’s styling that you don’t need.

Ultimately no matter how you approach your coding, just remember to be kind to your future self. 

Alec Robertson

Journal Entries

Your Website's Performance Could Be Costing Time and Money

Developing the New via.studio

What's the JAMstack?

Building a Wordpress Theme with Timber

Organizing Web Styling