Showing posts with label performance. Show all posts
Showing posts with label performance. Show all posts

Tuesday, March 31, 2015

A Baseline for Front-End [JS] Developers: 2015

A Baseline for Front-End [JS] Developers
It's been almost three years since I wrote A Baseline for Front-End Developers, probably my most popular post ever. Three years later, I still get Twitter mentions from people who are discovering it for the first time.

In some ways, my words have aged well: there is, shockingly, nothing from that 2012 post that has me hanging my head in shame. Still, though: three years is a long time, and a whole lot has changed. In 2012 I encouraged people to learn browser dev tools and get on the module bandwagon; CSS pre-processors and client-side templating were still worthy of mention as new-ish things that people might not be sold on; and JSHint was a welcome relief from the #getoffmylawn admonitions – accurate though they may have been – of JSLint.

It's 2015. I want to write an update, but as I sit down to do just that, I realize a couple of things. One, it's arguably not fair to call this stuff a "baseline" – if you thought that about the original post, you'll find it doubly true for this one. One could argue we should consider the good-enough-to-get-a-job skills to be the "baseline". But there are a whole lot of front-end jobs to choose from, and getting one doesn't establish much of a baseline. For me, I don't want to get a job; I want to get invited to great jobs. I don't want to go to work; I want to go to work with talented people. And I don't want to be satisfied with knowing enough to do the work that needed to be done yesterday; I want to know how to do the work that will need to get done tomorrow.

Two, my world has become entirely JavaScript-centric: knowledge of the ins and outs of CSS has become less and less relevant to my day-to-day work, except where performance is concerned. I know there are plenty of very smart front-end developers for whom this isn't true, but I have also noticed a growing gulf between those who focus on CSS and those who focus on JavaScript. That's probably a subject for another blog post, but I bring it up just to say: I am woefully unequipped to make recommendations about what you should know about CSS these days, so I'm not going to try.

In short: if this list of things doesn't fit your vision of the front-end world, that's OK! We're both still good people. Promise.

JavaScript

Remember back in 2009 when you read that HTML5 would be ready to use in 2014, and that seemed like a day that would never come? If so, you're well prepared for the slow-but-steady emergence of ES6 (which is now called ES2015, a name that is sure to catch on any day now), the next version of JavaScript. Getting my bearings with ES6 – er, ES2015 – is hands-down my biggest JavaScript to-do item at the moment; it is going to be somewhere between game-changing and life-altering, what with classes, real privacy, better functions and arguments, import-able modules, and so much more. Those who are competent and productive with the new syntax will have no trouble standing out in the JS community. Required reading:

  • Understanding ES6, a work-in-progress book being developed in the open by Nicholas Zakas.
  • BabelJS, a tool that lets you write ES6 today and "compile" it to ES5 that will run in current browsers. They also have a good learning section.
  • ES6 Rocks, with various posts that explore ES6 features, semantics, and gotchas.

Do you need to be an ES6/ES2015 expert? Probably not today, but you should know at least as much about it as your peers, and possibly more. It's also worth at least entertaining the possibility of writing your next greenfield project using ES6; the future will be here before you know it.

New language features aside, you should be able to speak fluently about the asynchronicity of JavaScript, and using callbacks and promises to manage it. You should have well-formed opinions about strategies for loading applications in the browser and communicating between pieces of an application. You should maybe have a favorite application development framework, but not at the expense of having a general understanding of how other frameworks operate, and the tradeoffs you accept when you choose one.

Modules & Build Tools

There's no debate that modules should be the building blocks of client-side web applications. Back in 2012, there was lots of debate about what kind of modules we should use for building apps destined for the browser – AMD or CommonJS. The somewhat-gross UMD wrapper arose to try to avoid answering the question while still allowing code reuse – because hey, what's a few more bytes between friends?

I don't feel like this debate is anywhere near resolved, but this is the area where I feel like we've seen the largest transformation since my 2012 article, though perhaps that's a reflection of my personal change of heart. I'm not ready to say that I'm done with AMD, but let's just say I'm floored by how practical it has become to develop and deploy web applications using CommonJS, including modules imported with npm.

With much love for all that RequireJS has contributed to the module conversation, I'm a bit enamored of webpack right now. Its features – such as easy-to-understand build flags – feel more accessible than RequireJS. Its hot-swap builds via its built-in dev server make for a fast and delightful development story. It doesn't force an AMD vs. CommonJS decision, because it supports both. It also comes with a ton of loaders, making it fairly trivial to do lots of common tasks. Browserify is worth knowing about, but lags far behind Webpack in my opinion. Smart people I trust tell me that systemjs is also a serious contender in this space, but I haven't used it yet, and its docs leave me wanting. Its companion package manager jspm is intriguing, allowing you to pull in modules from multiple sources including npm, but I'm a bit wary of combining those two concerns. Then again, I never thought I'd break up with AMD, yet here I seem to be, so we'll see.

I still long for a day when we stop having module and build tool debates, and there is a single module system and sharing code between arbitrary projects becomes realistic and trivial without the overhead of UMD. Ideally, the arrival of ES6 modules will bring that day – and transpilers will fill in the gaps as the day draws closer – but I find it just as likely that we'll keep finding ways to make it complicated.

In the meantime, front-end developers need to have an opinion about at least a couple of build tools and the associated module system, and that opinion should be backed up by experience. For better or worse, JavaScript is still in a state where the module decision you make will inform the rest of your project.

Testing

Testing of client-side code has become more commonplace, and a few new testing frameworks have arrived on the scene, including Karma and Intern. I find Intern's promise-based approach to async testing to be particularly pleasing, though I confess that I still write most of my tests using Mocha – sometimes I'm just a creature of habit.

The main blocker to testing is the code that front-end devs tend to write. I gave a talk toward the end of 2012 about writing testable JavaScript, and followed up with an article on the topic a few months later.

The second biggest blocker to testing remains the tooling. Webdriver is still a huge pain to work with. Continuous automated testing of a complex UI across all supported browsers continues to be either impossible, or so practically expensive that it might as well be impossible – and never mind mobile. We're still largely stuck doing lightweight automated functional tests on a small subset of supported browser/device/OS combinations, and leaning as hard as we can on lower-level tests that can run quickly and inexpensively. This is a bummer.

If you're interested in improving the problem of untested – or untestable – code, the single most valuable book you can read is Working Effectively with Legacy Code. The author, Michael Feathers, defines "legacy code" as any code that does not have tests. On the topic of testing, the baseline is to accept the truth of that statement, even if other constraints are preventing you from addressing it.

Process Automation

You, hopefully, take for granted the existence of Grunt for task automation. Gulp and Broccoli provide a different approach to automating builds in particular. I haven't used Broccoli, and I've only dabbled in Gulp, but I've definitely come to appreciate some of the limitations of Grunt when it comes to automating complex tasks that depend on other services – especially when that task needs to run thousands of times a day.

The arrival of Yeoman was a mere 45 days away when I wrote my 2012 post. I confess I didn't use it when it first came out, but recently I've been a) starting projects from scratch using unfamiliar tech; and b) trying to figure out how to standardize our approach to developing third-party JS apps at Bazaarvoice. Yeoman really shines in both of these cases. A simple yo react-webpack from the command line creates a whole new project for you, with all the bells and whistles you could possibly want – tests, a dev server, a hello world app, and more. If React and Webpack aren't your thing, there's probably a generator to meet your needs, and it's also easy to create your own.

Given that Yeoman is a tool that you generally use only at the start of a project, and given that new projects don't get started all the time, it's mostly just something worth knowing about. Unless, of course, you're also trying to standardize practices across projects – then it might be a bit more valuable.

Broccoli has gotten its biggest adoption as the basis for ember-cli, and folks I trust suggest that pairing may get a makeover – and a new name – to form the basis of a Grunt/Yeoman replacement in the future. Development on both Grunt and Yeoman has certainly slowed down, so it will be interesting to see what the future brings there.

Code Quality

If you, like me, start to twitch when you see code that violates a project's well-documented style guide, then tools like JSCS and ESLint are godsends, and neither of them existed for you to know about them back in 2012. They both provide a means to document your style guide rules, and then verify your code against those rules automatically, before it ever makes it into a pull request. Which brings me to…

Git

I don’t think a whole lot has changed in the world of Git workflows since 2012, and I'd like to point out Github still hasn't made branch names linkable on the pull request page, for f@#$s sake.

You should obviously be comfortable working with feature branches, rebasing your work on the work of others, squashing commits using interactive rebase, and doing work in small units that are unlikely to cause conflicts whenever possible. Another Git tool to add to your toolbox if you haven't already is the ability to run hooks – specifically, pre-push and pre-commit hooks to run your tests and execute any code quality checks. You can write them yourself, but tools like ghooks make it so trivial that there's little excuse not to integrate them into your workflow.

Client-Side Templating

This may be the thing I got the most wrong in my original post, for some definition of "wrong". Client-side templating is still highly valuable, of course – so valuable that it will be built-in to ES2015 – but there can be too much of a good thing. It's been a hard-earned lesson for lots of teams that moving all rendering to the browser has high costs when it comes to performance, and thus has the "generate all the HTML client-side" approach rightfully fallen out of favor. Smart projects are now generating HTML server-side – maybe even pre-generating it, and storing it as static files that can be served quickly – and then "hydrating" that HTML client-side, updating it with client-side templates as events warrant.

The new expectation here – and I say this to myself as much as to anyone else – is that you are considering the performance implications of your decisions, and maybe not restricting yourself quite so thoroughly to the realm of the browser. Which, conveniently, leads to…

Node

You say you know JavaScript, so these days I expect that you can hop on over to the Node side of things and at least pitch in, if not get at least knee-deep. Yes, there are file systems and streams and servers – and some paradigms that are fundamentally different from front-end dev – but front-end developers who keep the back end at arm's length are definitely limiting their potential.

Even if your actual production back-end doesn't use Node, it's an invaluable tool when it comes to keeping you from getting blocked by back-end development. At the very least, you should be familiar with how to initialize a Node project; how to set up an Express server and routes; and how use the request module to proxy requests.

via rmurphey.com by

Friday, February 27, 2015

How to Make Your WordPress Site Blazing Fast

WordPress Site

Today's web users have the need for speed. With internet and cellular connections getting faster and faster, users expect sites to feel snappy. As developers, we must make sure we're doing our best to serve those pages quickly. This article will focus on what you should be doing to make sure your WordPress sites are as fast as possible.

Make your Wordpress site blazing fast

There are essentially two main categories that performance can be broken down into: front-end and back-end. Back-end is anything related to the server and how data is populated on a page (PHP code in your theme is the "back-end"). The front-end consists of all your assets (CSS, JavaScript, images, etc.) and markup. Everything a web browser reads and interprets is the "front-end". This distinction is important because it's good to know what you're optimizing and, even more importantly, where you need to optimize the most.

To actually test site speed, use a combination of WebPagetest and Google PageSpeed Insights. WebPagetest gives you a good idea of the actual time (in seconds) that a site takes to load, explaining where bottlenecks may be. PageSpeed Insights is best for looking at how your front-end is site is rendered by the browser.

Front-end performance

The golden rule of performance, according to Fastly's Steve Souders is that 80-90% of a page's total load time consists of the front-end. The back-end's 10-20% is crucially important, but even if you're using the fastest host around, your site still won't live up to its full potential without optimizing the front-end and users perceive it to load quickly. Perception is an important part of front-end optimization. A user doesn't care how many seconds a site takes to load. A user cares about how quickly they can interact with a site without a delay. Not that you shouldn't be worried about the actual load time (you should), but by following these techniques, you can make sure that your site is in a usable state fast, before loading the rest of the page assets.

WordPress Site

CSS

Before delivering CSS to the browser, it’s important to compress it and remove unused selectors.

Once your stylesheet is ready to go, the easiest (and standard) way to load it is to reference it in the head. The browser will load and parse it before the rest of the DOM is loaded. However, there's a new technique where "critical" styles are inlined in the head and then the full stylesheet is loaded asynchronously using JavaScript. This technique can be used when trying to get a site to load (or perceive to load) in under a second, but it's a great tool to keep in your arsenal. Check out this great extensive article on using this technique.

WordPress Site

JavaScript

The golden rule(s) of optimizing JavaScript are simple: serve as few JavaScript files as possible and minify and concatenate. Third-party WordPress plugins can bloat your document with unminified blocking JavaScript files, so it's important to be mindful when choosing plugins. Ideally, you'd concatenate ALL JavaScript files into one and then minify it. When that's not possible, HTML attributes called async and defer can be used to load JavaScript files asynchronously or once the rest of the page is loaded.

The most common place to reference JavaScript is at the bottom, right before the closing tag. However, there are more advanced techniques to load JavaScript. The Filament Group has several tools you can use for this. The best approach is to load scripts dynamically by inlining a small function in the head that appends script tags without blocking the rest of the page. For more information, check out the loadJS script.

Images

Images are often the biggest files on a page, responsible for the largest load time delay. The good thing about images is that, unlike CSS and JavaScript, most browsers load them asynchronously. That helps with the perceived performance of a page. But it's still important that A) you're serving as few images as possible and B) those images are compressed as much as possible.

Compression tools are necessary for squeezing out as much excess as possible on images. ImageOptim is a great free Mac compression app, along with OptiPNG and jpegtran for use with task runners like Grunt.

WordPress Site

Fonts

Web fonts are super common these days. Google Web Fonts make sites pop. It's easy to not realize the performance hit you take by just referencing them in the head. The performance hit is small, but every little bit counts! For best performance using web fonts, check out the the Web Font Loader, co-developed by Google and Typekit. It's an open source script that both manages the loading of your fonts from third parties like Google Web Fonts and allows them to load asynchronously (getting tired of that word yet?).

As to be expected, there's some configuration needed to get Web Font Loader integrated into your project, so check out the project on GitHub for setup info.

WordPress Site

Back-end performance

The front-end has all kinds of tricks for speed, but we're not so fortunate on the back-end. A server is either fast or it's not. It's critical that your site gets to the browser as quickly as possible, which can be accomplished by getting on a quality host. Managed hosts like Flywheel are the most realistic way to see true performance gains for WordPress sites.

Dedicated Wordpress Hosts

There are are a host of managed WordPress hosts (pun intended). What managed hosts typically provide is a dedicated VPS (virtual private server), a caching layer and other infrastructural bonuses that set them apart from your typical shared hosting. These all matter when it comes to loading your site fast, so the best and first step to a super fast WordPress site should be the host.

For example, let's take a look at Flywheel. Flywheel is a managed host, and their infrastructure is designed so your sites never touch another customer's. Compared to a host that crams as many sites as possible on the same server, having your site on a server by itself works magic for speed. It means that server's resources are just working for you, not for everyone else.

WordPress Site

Theme Logic

There are many things you can do while developing to make your back-end as performant as possible. Nasty loops that do tons of comparisons and use lots of memory slow down a site down. There are lots of articles on performant PHP, but just take care when writing theme logic!

Another important time saver during database queries is the Transients API. WordPress transients store cached data in the database temporarily, which means your logic only has to run once (whenever the first visitor loads the page). The results are then stored in the database. The Codex has good documentation on the usage of transients.

Caching

Caching assets is one of the best ways to improve performance. Once a user loads your site the first time, you can take advantage of browser capabilities to cache the contents of that site locally, so on the next visit the user already has them loaded. The most common WordPress caching tool is W3 Total Cache plugin. This plugin (or one similar) is needed on most shared hosts. However, WordPress specific hosts like Flywheel handle caching for you behind the scenes. With hosts like Flywheel, all of the caching is done on the server outside of WordPress, which means your sites are already tuned for max performance.

WordPress Site

GZIP

Gzip is a file format that's used to compress other files together, similar to just zipping files. Gzipping allows files to be sent over the web at a compressed size. Once a browser receives gzipped data, it unzips it to get the source data. Gzipping is super important for speed, as it sends your data over the wire in much smaller packages (50 - 70% smaller, in fact). Smaller file size equals faster load times!

You should always check to see if your host supports Gzipping. Managed WordPress hosts like Flywheel enable Gzip compression by default, so it's one less to to worry about!

WordPress Site

CDN

A content delivery network (or CDN) is a network of servers that serves up your website and its assets from different locations based on the user's location. For example, let's say you're not using a CDN and your site is hosted in San Francisco. When someone from, say, Spain visits your site, they have to retrieve all your assets from your server in San Francisco. The long distance between the two locations clearly takes longer than if someone from San Francisco loads your site that's hosted in San Francisco. A CDN serves your assets from the closest geographical data center. Users will hit the server closest to them, speeding up the physical time and distance required to load the page.

Some of the most popular CDNs include Amazon Web Services, CloudFlare and MaxCDN. If you want a super easy setup, check out Flywheel's MaxCDN add-on.

WordPress Site

Conclusion

Tuning a web site to maximum capacity can be challenging. There are a lot of moving parts. By working through both the front end and the back end, a site can be designed or overhauled for maximum speed. On the front end, saving as much time and space as possible means the con-tent you’re serving gets to the content faster. But if even if your front end is brilliantly designed, none of that will matter the servers you host the site on aren’t running at their peak performance. Managed WordPress hosts tune sites to peak performance and take out the frustrations behind web hosting. Hosts like Flywheel will not only make your site fly, but make your hosting experience worry-free.


Wednesday, October 03, 2012

Improving site performance with YSlow

Improving site performance with YSlow

We spend a fair bit of time improving the performance of our application servers and databases, but truth be told 80% of a web request is spent working on the frontend. The screenshot below shows the entire request time of a large eCommerce site using New Relic. (Shown with their permission, of course). As you can see, the average total request time is 3.2 seconds but only a fraction (5%) is spent in the web app layer (in purple). The other 95% is spent in the network, DOM processing and page render. So looking at performance from the frontend is critical and that's what we're going to do in this post.