The Mijingo Blog

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

Guide to Google AMP

by Ryan Irelan

Google AMP (officially known as the AMP Project) is a new way to deliver fast pages to mobile users through special HTML markup, lean HTML documents, and caching (via the AMP Cache).

But AMP is not without controversy, mostly because it requires a new HTML syntax to work properly and a fair amount of template work.

But the promise is a big one: faster pages and maybe better search rankings.

AMP stands for Accelerated Mobile Pages. It’s an open source framework with the goal of delivering faster pages to mobile users. Google has been pushing web page performance for several years (to learn more about it check out my Web Performance Testing course) but mostly wth tools that helped developers measure performance, not create fast pages.

However, Google AMP is an implementation that helps you create faster mobile pages. Instead of providing the tools to measure fast pages, Google is now offering a tool to create them, too.

AMP is a three-part system:

  • AMP HTML, a custom HTML syntax that Google parses. This is added into otherwise normal HTML documents.
  • AMP JS, a JavaScript library that is the engine that supports the HTML implementation
  • AMP Cache, a CDN that caches and serves AMP documents and assets (your pages and assets) via HTTP/2.

I put together a free lesson so we can “plug in to” AMP, learn what it is, how it works, and then step through a simple implementation together.

Watch the Lesson

New Course: Web Performance Testing

by Ryan Irelan

Web pages are getting bigger. In 2015, according to the HTTP Archive, the average web page increased in size by 16%.

2 MB pages are common now.

But assigning blame isn’t a solution. Hand-wringing and finger-pointing do nothing to improve the situation.

However, understanding how your pages perform_while you are developing them_ does.

If we can become more aware of how our feature, design, and development decisions impact the performance of the website, we can address problems before they impact the site’s user experience.

And that’s what we’re after in Web Performance Testing.

Start Learning

Web Performance Testing Metrics

by Ryan Irelan

In a previous lesson I covered how to find TTFB, the Time to First Byte. TTFB is one of several metrics we can use to measure the performance of our websites.

In this lesson, we’ll expand the coverage of performance testing metrics and review the most important performance metrics to consider when building and testing your website.

Watch the Lesson

A Performance Budget is a Plan

by Ryan Irelan

The main reason to create a performance budget is to have a tangible starting point for conversation around a web page or website. It shouldn’t act as gospel, but it’s a thing you can measure against. It’s your frame of reference. -Dan Mall

A performance budget is a plan.

It’s a guide against which to measure your work: your design and development decisions, and feature choices. The performance budget is meant to aid you during the web design and development process and then be a data point when you deploy the new site to a staging and production server against which to measure other performance testing and metrics.

A performance budget is not a hard line that you cannot cross.

You certainly should not ignore it completely (otherwise what’s the point of having one) but treating it as a best case scenario is a pragmatic approach.

A performance budget lets you make informed decisions.

Consider the performance budget when you are:

  • considering new features,
  • adding banner ads for revenue generation,
  • including a new scripting library,
  • or adding web typography

Current knowledge is that the term “performance budget” was first mentioned in an article by Tim Kadlec in the context of web design and development teams.

Tim covered this in the context of improving the performance of responsive websites after a trend of heavier page weight sites being designed. On a fast connection the extra weight was nary a problem, but on mobile, where bandwidth is often more limited, loading a full desktop site worth of assets for a more constrained mobile device view was an issue.

Performance Budget and Money Budget are the Same

You can think of a performance budget the same way you think of a budget for your personal finances. You set a limit on what you want to spend in a given month and then assign values to categories accordingly, until that limit is met.

As the month progresses, you have to make choices along the way. Do you go out to that fancy steak dinner for $200 and deplete your Eating Out budget? Or do you skip it so you can get lunch out for the next couple weeks instead of bringing a ham sandwich to the office?

It’s okay to choose either option, but if you choose both, you’ll exceed your budget.

The same approach is used for performance budgets. Instead of setting a monetary amount we can’t exceed, we set some webpage metric. This could be one of the following:

  • total page weight (in KB)
  • total number of HTTP requests
  • total render time (in a controlled environment, like local development)

The first two are fairly straight-forward to test and shouldn’t vary much across environments.

The last one, total render time, is a bit harder to test because it could vary depending on the environment (bandwidth being the wildest variable here) and the web browser used.

I like to use the total page weight and total number of HTTP requests because I can regularly and reliably test it.

The advantage of using number of HTTP requests and page weight is that they nicely adapt to a site that is out of active design and development and in the QA/Launch phases.

This is when you are ensuring the site performance meets your expectations based on the budget you set earlier in the project. No matter which environment we’re in, the number of HTTP requests and the page weight are still good measurements. This is the case even if those environments affect the total measurements (due to extra code for analytics, A/B testing, etc); we still want to hit—or come close to—our performance budget.

Make Informed Choices

A performance budget helps us make informed choices both during the site development and over the course of its life.

Instead of making choices about whether to have a steak dinner or 10 lunches out, we choose between different site features (the big slideshow on the homepage with 8 images) and implementation details (using a JavaScript library instead of coding the feature from scratch) to keep the project with the performance budget.

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

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.

What are our customers saying?

"Just purchased your Flexible Twig course. Love it!"
Tyler Morrison
"Been enjoying @mijingo 's Learning Craft video tutorials. Feeling like I've got a good basic understanding of #craftcms Very impressive"
Laura Montgomery
"I bought your Craft Starter Pack a year and a half ago. Worth every dollar. In fact, I would've paid twice as much for it, because you saved me so much time."
Timothy Ingram
"Ben's knowledge of Craft combined with his relaxed and informal teaching style makes for a great learning experience."
Steve Abraham
"Ben puts a lot of thought into his teaching approach and has the ability to explain complex concepts in a way that just make sense"
Gareth Redfern
"Ben is great at taking a complex subject and breaking it down in a way that you can wrap your mind around. I thought that plugin development was something I would never understand, and happily Ben proved me wrong!"
Jonathan Melville
"I really appreciate all the videos and writing you have done. Your work has given me a jump start on my front end development business."
Shan Ricciardi

Perfect for Small Teams & Companies

Mijingo's courses are perfect as the training curriculum for both small teams and entire companies.

Our courses are offered in Team Packs (up to 5 people) and Company Packs (up to 25 people), so you can make one simple, fast purchase to train your entire staff.

Prices are listed with each course. Need more than 25 or something custom?

Send Your Requirements
Team Pack2-5 People
Company Pack6-25 People
Custom Pack25+ People