by Ryan Irelan
This doesn’t happen often. I just knocked the prices down by 30% on a bunch of courses in the catalog.
It’s become an annual tradition to have a little Back to School Sale each year just as the kids head back to school after Summer break here in the northern hemisphere.
So, we’re doing it again. There’s no coupon to remember. You’ll see the prices already knocked down for some courses.
It’s the perfect way to get started learning something new and meeting your year-end learning goals.
by Ryan Irelan
This coming Tuesday, August 25, 2015, I will be on the ALA: On Air panel all about content management systems.
CMSes help and hinder; they inspire rapture and incite table-flipping. I’m thrilled to moderate the next ALA: On Air event, where Karen McGrane, Jeff Eaton, and Ryan Irelan will join me to discuss what they love about working in CMSes (administrative UX!), what drives them to frustration (decoupling!), and what meaty problems (integration with design systems!) they hope to dive into next.
The panel will cover a handful of topics, including decoupling systems and headless CMSes.
If you work with CMSes at all, this is the must see panel. It’s free, online, and if I do my job, fun and informative.
See you there!
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:
Current knowledge is that the term “performance budget” was first mentioned in an article by Tim Kladec 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.
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:
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.
A performance budget helps us make informed choices both during the site development and over the course of its life.
by Ryan Irelan
Ben Croker, the author of Craft Plugin Development, recorded a free bonus update to his course. The update covers some initial considerations for making your plugin Craft 3 compatible.
First, a side note: Craft 3 is in developer preview and still a ways off. You don’t need to build or ship Craft 3 plugins just yet.
In the short video Ben walks through the changes he needs to make to the Entry Count plugin (that’s the plugin he builds in the course) so it will work with Craft 3.
If you already purchased the course then this bonus video will appear in your Course Library inside the Craft Plugin Development course.
But we also wanted to make the video available for everyone. Here it is:
Ben’s Craft Plugin Development course is 90+ minutes, broken up into several videos for easier learning and reference. Ben will get you from not knowing how to develop plugins to having your first plugin done and working!
by Ryan Irelan
The Learning Craft course now has new videos covering the Matrix field type.
I broke the new tutorial up into 7 short videos so you can easily reference back to just the topic you want (like coding templates for Matrix or using the
If you already purchased the course then you’ll have the videos in your Course Library as part of the course.