The Mijingo Blog

Latest news, updates, free tutorials, and more from Mijingo.

Behind-the-Scenes at Mijingo

by Ryan Irelan

In the last Mijingo newsletter, I included a video that showed some behind-the-scenes shots of producing videos here at HQ.

The frame I chose for the thumbnail is definitely a favorite of mine:

Record at Mijingo HQ

Animating SVG with JavaScript

by Ryan Irelan

Animating SVG with JavaScript is best achieved using a library that has a healthy amount of functionality and broad browser support. For our examples, we will use the Velocity.js JavaScript library.

Velocity is a lightweight library that “re-implements jQuery’s $.animate() for significantly great performance.”

Let’s jump right in and start animating our SVG.

The first thing we want to do is to tell Velocity which object we want manipulate. For our logo example, we’ll hook into it using the class names we assigned to the SVG shapes.

$(".two")
 .delay(500)
 .velocity({ fill: "#333", strokeWidth: 2})
 .velocity({rotateZ: "10deg"})
 .delay(500)
 .velocity({x: "+=20", y: "100%" });

View Intro to SVG: Example 20

In this example we are selecting the shapes (rect in this case) that have the class of two and then manipulating them. We start with a delay, change the fill color of the shape from white to a black, and then rotate the shape 10 degrees. After that we delay another 500ms and then animate the shape from its starting point to 100% (basically, off the canvas) by changing the x and y coordinates of the SVG shape.

Here’s an example with all of the SVG shapes transformed and moved off the viewport or canvas: View Intro to SVG: Example 21

Browser Support

Velocity.js works all the way back to Internet Explorer 8 and Android 2.3 on mobile devices.

Using Variables in Twig and Craft CMS

by Ryan Irelan

Twig allows us to set variables in our templates so we can repeatedly output a value without calling another method. It also helps make our templates cleaner because a variable can be a shorthand way to reference a value.

There are a few different ways to create and assign values to variables, and they all use the set tag.

The simplest way is like this:

{% set title = "About Happy Lager" %}

by defining the variable name using the set tag and then assigning a value (in this case a string).

This variable can now be used throughout the template using the double curly braces syntax:

{{ title }}

If we had multiple variables to set at once–perhaps some metadata for the page that we wanted to use in multiple places–we can do that by separating both the variables names and their values by commas.

Here’s a simple example:

{% set title, subtitle, description = 'About Happy Lager', 'The history behind the company.', 'Learn more about the history of the this mobile design and development agency.' %}

Each of those variables would then be available in the template, using the double curly brace syntax:

{% set title, subtitle, description = 'About Happy Lager', 'The history behind the company.', 'Learn more about the history of this mobile design and development agency.' %}

<html>
 <head>
  <title>{{ title }}</title>
  <meta name="description" content="{{ description }}">
 </head>
 <body>
  <h1>{{ title }}</h1>
  <h2>{{ subtitle }}</h2>
  <p class="description">{{ description }}</p>
 </body>
</html>

One last way of setting variables in Twig also uses the set tag but instead of as a single tag, we use it as a tag pair. Using it as a tag pair allows us to capture a block of text or code and assign it to the variable. This is handy for assigning a chunk of markup and content to a variable.

{% set description_formatted %}
    <p class="description>Learn more about the history of this mobile design company.</p>
{% endset %}

And that is the basic usage of variables in Twig and Craft CMS.

Ready to learn more about the Craft CMS?

My Craft Starter Pack is 4 ½ hours of premium learning that will get you started building sites with Craft for yourself, your company, or your clients.

Get Immediate Access

Web Performance Testing: Finding TTFB

by Ryan Irelan

When we do web performance testing, one of the performance metrics that we’ll want to test is Time to First Byte (TTFB).

Before I jump in to how to measure TTFB (via the video below–wait don’t skip!), let’s review what TTFB is and how it fits into the bigger picture.

Firstly, is not a sole actor. It is only one of the four network metrics that can impact page load time.

There are also:

  • DNS lookup time
  • Connection time
  • Download time

We’ll cover the rest another time, but for now let’s focus on TTFB.

What is TTFB?

Time to First Byte, TTFB for short, is the amount of time it takes for the browser to receive the first byte of data from the server after the browser makes the request.

TTFB does not include DNS lookup or any SSL negotiation that has to take place before there is a connection to make the request to the server. You can see this demonstrated in the video below where I show how to find out your TTFB using both Google Chrome and the Webpagetest.org.

Let’s roll the video:


Why is TTFB important to measure?

TTFB is important to measure is because it can create the perception that your page load is slow.

A fast TTFB will not help us if we have other performance problems with our webpage (e.g. if our page weight is too heavy or its assets not optimized).

Even if we have a snappy page in terms of other non-network metrics, a slow TTFB can give the perception of a slow page speed.

You can do all the work you want on improving other metrics for your webpage performance, however, if the TTFB is unacceptably slow, then your page speed will be perceived as slow by the end-user.

Clients & Performance Budgets

by Ryan Irelan

A performance budget sounds great but how do I implement this in the real world, with real clients?

One bit of advice to get started (I learned this the hard way): don’t have an internal-only performance budget and use it to fend off client feature or design requests without first including the client in the formation of said performance budget.

They’ll be confused and you will probably look defensive at best, aloof at worst.

If you have clients that are not used to having a performance budget in a project, then here are some tips for talking about performance budgets with clients:

  • Be transparent. Explain your thinking behind a performance budget, using non-technical terms when needed.
  • Focus on how it helps the project goals. Frame the performance budget in terms of how it will help their website goals (sales, leads, information, etc). How will a well-performing site help your client’s business or cause?
  • Share performance numbers with each update. Every significant deliverable should include information about the performance budget. This is especially true during development.
  • Create use case examples to give context to the performance budget numbers.

It’s always (always!) easier to be upfront and transparent with your clients. Doing the same with performance budget will yield better project results.

The burden is on you–the designer, developer, owner–to show why a performance budget isn’t just some nerdy, tech-y thing that makes us feel good about ourselves and the tools we use. Make it yet another tool that helps you work together with the client toward the project’s larger goals.