Website Performance

An introduction and a discussion about how developers need to change their mindset to think about web performance from the start. Kyle also presents a few initial resources including a discount code for the O’Reilly HTML5 Cookbook and some projects like LABjs, grips, and h5ive. • HTML5 Cookbook O’Reilly discount code: AUTHD

While this presentation will focus greatly on optimization, performance tuning is only one piece of the development puzzle. Weaving these practices into your natural workflow will keep your website’s performance a priority and not an afterthought. Steve Souders once said, “Eighty to ninety percent of the end-user response time is spent on the front end”. Website optimization should start there.

Great performance can lead to great user experience. The opposite is true too. A website’s performance influences a user’s first impression. Comparing performance data from one site to another is a great way to start gauging areas of poor optimization. The document ready state is the point when a user is able to meaningfully interact with a webpage. Optimizing the document ready state can increase the perceived performance of the page.

A well performing site can create a higher conversion rate. Every second counts when qualified leads have reached your content. Optimized code is quality code. Reusing quality code can save time and money on future development projects. Measurement and perception define web performance. Web professionals must measure the optimization techniques to determine if higher performance has been achieved.

Worrying about the speed of the non-critical parts of a website can lead to wasted time. Start with the critical parts. Most users are not able to distinguish the differences when response times are less than 100 milliseconds. The threshold for response time is typically 1000 milliseconds, or 1 second. Anything over 1 second will exceed the tolerance of a user.

Owning poor code is expensive. Deciding to write poor code now and optimize it later is unrealistic and causes the code to become systemic. The dirty little secret of front-end performance is that most of “front-end” optimization actually happens in the “middle-end”. This workshop will start by focusing on optimizing the “middle-end”. Then it will move to front-end performance enhancements.

YSlow is one of the first browser plugins that allowed developers to test the performance of a website. YSlow uses a set of rules to gauge the performance. The first rule is fewer HTTP requests. The next YSlow rule is to use a CDN. CDN’s have multiple locations all over the world and can take advantage of shared caching. Using expires and cache-control headers give you the ability to control the loading policy around stable content. Gzipping can compress your content anywhere from 50%-70% decreasing loading time.

Another rule of YSlow is to include your stylesheets at the top and scripts at the bottom. With scripts, remember that including them at the bottom simply gives priority to the rest of the markup. You may need to include your scripts at the top in situations where they become more important. Avoid CSS expressions because they will slow down the UI thread greatly. Also, externalize your JavaScript and CSS so they will take advantages of performance features like caching. Fewer DNS lookups will also increase performance by decreasing the latency of the page. Minifying JavaScript and CSS should be higher on the YSlow list because it’s an easy way to reduce the size of a web application. Avoiding redirects is another YSlow rule. An example is a website redirecting to the “www” version of the domain. When you are using the same JavaScript framework across a website, ensure you do not have duplicate script requests. ETags are hexadecimal codes generated for a particular resource. They function like a finger print to enable the conditional loading of that resource. Cacheable Ajax adds an additional layer of expiration on top any external resources you are loading. While these 14 YSlow rules can occasionally contradict each other, they are a basis for proper website performance.

There are many ways to incorporate the 14 YSlow rules into a website. Kyle outlines a few techniques of implementing fewer HTTP requests, Gzip, and conditional requests. Yahoo has published a number of additional performance rules. They include reducing the cookie size and optimizing sprites. The YSlow plugin gives you a letter grade and a numerical grade for your website. Remember to look through the report carefully and consider additional optimizations even in categories with higher scores.

In this exercise, test three websites with the YSlow plugin. Select the site with the lowest grade and examine some of the ways the performance could be improved based on the YSlow reports.

Between November 2010 and November 2011 the average web page size has grown from 625kB to 784kB. This is largely due to the increase in JavaScript usage and image size. Using an image optimizer can help trim down image size. Image sprites combine multiple image resources into a single image and utilize CSS background positioning to one display a single sprite within that image. Use a tool like SpriteMe to create sprites of your images assets. Inline images reduce the amount of external requests however the ability for the image to be cached is now tied to the CSS file.

There are many options to minify JavaScript and CSS code. Some perform better than other. Concatenating code can also help reduce download time and HTTP request. A helpful online tool for identifying scripts you can concatenate is zBugs.

Use YSlow to obtain a benchmark for performance of the supplied website. Then analyze the report and begin optimizing the website with the tools shown so far. After some time, Kyle dives into the solutions and discusses some of the ways the site could be optimized.

The middle-end is a layer that exists between what’s happening in the browser and what’s happening in a database. Developing the correct architecture is the key to tying together the front, middle, and back ends.

Architecture starts with the markup of a webpage. Think about a single-page website design. Can you architect a page that is able to load all mark-up once so any dynamic content is simply a duplication of what’s already loaded?

Often times data validation rules are written twice: Once on the client, and once on the server. A performance goal would be to have these rules written once. One way to achieve this would be with a middle-end written in server-side JavaScript.

While JSON can be faster than other data formats like XML, remember it’s easy to add bloat to your data and get lazy with how it’s structured. Laziness can lead to latency and a slower web application. Ajax requests have been used for years and tend to be the de facto means for asynchronous communication. Web sockets, however can reduce the amount of data sent and open the door for two-way communication.

The first technique that can be used for preloading is the prefetch relationship attribute in the link tag. This method does not guarantee preloading. It simply suggests to the browser to load the resources.

Lazy loading is often referred to as on-demand loading or post loading. This technique waits until it’s absolutely sure the resource is needed. Lazy loading is on the other end of the spectrum from preloading but both methods are in a developer’s arsenal of tools for performance tuning. A simple coded example of a JavaScript file being lazy loaded on a web page.

The focus of parallel loading is to preserve the execution order. Using a script loader like LABjs will help the parallel loading of resources. The big difference between a script loader and relying on a browser’s native parallel loading technique is when the document’s ready event fires.

Object oriented code in the browser does not work the same as object oriented code in a compiled language because, in the browser, it’s a live interpreted link of inheritance. It can lead to more abstraction than necessary.

The point of this exercise is to look at some object oriented JavaScript code and apply some performance testing. Identify the classes that have composition relationships and which classes have substantive object oriented behavior. Can you modify the code to remove inheritance and abstraction to improve performance?

Offloading animations from JavaScript into CSS can drastically improve the performance of your website. Using the setTimeout function in JavaScript can lead to inconsistent animation behavior and be unreliable. Same is true with setInterval. HTML5 added a better interface for animation called requestAnimationFrame. The purpose of this API is to tell the browser to run some code the next time it’s going to repaint the screen. This API is a better way to animate in JavaScript.

CSS animations are a powerful way to keyframe animations with CSS. CSS transitions, on the other hand, are pre-calculated animations based on a starting and ending property.

Compare the differences between the JavaScript animations and CSS transitions.

Threading allows more than one operation at the same moment in time. Threaded programming can be very complex to implement. JavaScript, however is single threaded. Don’t confuse asynchronous programming with parallel programming. While JavaScript has asynchronous code execution, the event loop is single threaded. The UI Thread in the browser is single threaded. This means the CSS rendering engine, DOM, JavaScript engine, etc. are all on the same thread.

Web workers allow you ask a specific JavaScript file to run in its own thread. This means the execution of that JavaScript file will not affect the performance of the overall web application.

JavaScript allows you to create variable and elements in the DOM, and then remove the references to those objects. This flags the object for garbage collection and it will be eventually removed. The time the object is removed, however, is arbitrary.

Explore two different files: One focusing on the UI thread and another focusing on garbage collection.

jsPerf is a web-based tool for running head to head test of JavaScript snippets and testing their performance.

Kyle looks at a number of the common JavaScript performance misconceptions and demonstrates how to interpret the results in jsPerf.

Visit an already created jsPerf. Test it out a few times and analyze the results.

Conclusion