On the Air With Palantir, Ep. 03: Increasing Performance

In this episode of On the Air With Palantir, host and Account Manager Allison Manley is joined by engineer Joe Purcell who shares a thorough yet entirely accessible definition of performance, and how it relates to your website.

In this episode, On the Air With Palantir host and Account Manager Allison Manley is joined by one of our magnificent engineers Joe Purcell. He shares a thorough yet entirely accessible definition of performance, why it matters, and what you can do to increase it. This episode is valuable for anyone in the midst of a web project, about to start a new project, and, of course, developers working on the web in any capacity.

iTunes | RSS Feed | Download

We'll be back next Tuesday with another episode of the Secret Sauce, but for now subscribe to all of our episodes over on iTunes.

We want to make your project a success.

Let's Chat.

Transcript

Allison Manley [AM]: Welcome to On the Air with Palantir, a podcast by Palantir.net where we go in depth on topics related to web design and development. I’m Allison Manley, an Account Manager here at Palantir, and today my guest is Joe Purcell, one of our magnificent engineers, who is here to speak with me about all the many ways you can improve your website’s performance.

Hey Joe! How are you?

Joe Purcell [JP]: Hello, doing well, thank you.

AM: So you’re going to talk with me today about performance, yes?

JP: Yes!

AM: Tell me about your history with the web community and performance.

JP: I’ve been part of the web development community since 2003. Performance-wise, I’ve had a number of opportunities to work with organizations to help them understand how to scale a web application, or just improve their website performance. So the topic of performance is something I’ve been very interested in.

AM: So it seems obvious what performance means, but what is it? What’s the definition?

JP: This is good. Performance is just as squishy and misunderstood as security. And I think it’s important for people in the web development community to educate the public and even their own companies, so people who are experts on this topic — they should help other people understand what performance exactly means.

I want to break it down into two different perspectives of performance. One is objective and the other is subjective. And that may sound cliché, but let me delve into that and describe what I mean. So objectively when we talk about performance, essentially what we’re talking about is efficiency of using a resource. So colloquially, you can think of an energy-star rating on a furnace - it's using electricity in a way that's very efficient. When it comes to computing, you need to understand some basics about how computing works, to understand the factors of performance. So I’ll give a couple of general categories that people look at when it comes to performance.

One is the storage disk or hard drive. This could be like files on disks. So if you have a website with a bunch of PDFs, that’s going to use a lot of storage. Another is memory. Let’s say you have a website that’s processing a lot of very complex data. Maybe it’s parsing XML, for example. It might be loading the XML into memory and using a lot of memory. So it depends on what type of web application or website, the details of what it’s doing, as to whether or not it’s using a lot of memory. Another is going to be computation time. How much time is the CPU spending in processing a request to your website? That’s something that you would look at. And lastly, network. This is where things like page weight come into play. If you’re serving a lot of images, you’re going to be using a lot of network traffic. So those are the things to look at. And what’s interesting about the objective perspective – there’s objective from the server point of view, the server that’s rendering the pages of your website or your web application, but there’s also the user perspective. The user may have a laptop from ’95 [laughs].

AM: Here’s hoping they don’t, but you never know. [laughs].

JP: But that’s an objective perspective of website performance.

AM: Back up a second - page weight?

JP: Okay, page weight is essentially – take a look at all the JavaScript, all the images, all the other API calls that are made. How much data is transferred over the network? That’s page weight.

AM: So you have to put your pages on a diet and make sure they’re lean and mean?

JP: [laughs] Yes, but especially for mobile.

AM: So what about the subjective list?

JP: The subjective aspect of performance, I don’t want to delve into too much, although it’s very interesting. Subjective performance is basically, how fast does the website appear? You can do some really interesting things from the subjective perspective, and I want to make a comparison to security again. You may have heard the term “security through obscurity”. Objectively, you’re not making something secure – it just appears to be secure. You can do the same thing with performance. Objectively speaking, maybe you’re not changing how the website performs. But maybe to the user, it is. So as an example, if you send an email using Gmail, that email is sent asynchronously. When you click the “send” button, it’s not going to wait to make sure that the email has sent. But Gmail has some really good error handling, so that, okay, this email didn’t send, so you understand that it didn’t send. Or if you’ve ever received one of those errors like ‘email failed to be received by the recipient’, everybody’s had those emails before. So from the user experience, it’s not waiting to confirm that, but there’s good error handling. It’ll send you an email back saying, this email was not received. But the important takeaway here is that subjectively it’s taking less time for the user to process the email.

AM: So as a client – let’s run through a few of these. Why do I want to improve performance? Why does my website need to be as fast as possible?

JP: Well, it depends on what your business is, but there are a couple of things that you want to consider. While I couldn’t answer what for each business the aspects that are relevant, I’ll just give a few aspects, and you can decide if they’re relevant to you. So one is just user experience. For example, imagine you’re Facebook. If the user experience is really slow, people aren’t going to want to use it. They’re going to want to use something that’s really fast. If they have to sit and wait seconds to scroll through their feed, that’s not going to be enjoyable. They’re going to be more inclined to use something else.

AM: We’ve become so impatient as a species. We want everything right now [laughs].

JP: Yeah, and the expectation is not that we’ve plateaued. The expectation is that things become faster. If the user notices a delay, that has a real impact on their experience. So the reason you want to improve performance in that way is just that you want people to have a great experience when they come to your website.

Another one is SEO. Search engines will give you a penalty if your server response times are slow. It would be worth checking to verify, but things like page weight may come into play as well. So let’s say your home page has a ton of very large images. That might be something that ties into SEO.

AM: What’s the penalty?

JP: The penalty would be page rank. Let’s say your server response times are a second, or two seconds. That might result in a penalty of you showing up on the third page of Google search results, instead of the second or first.

Another aspect is hardware. Depending on how large your website is, this is going to vary, but for very large websites, better performance means you need to maintain less hardware, which means you’re spending less money per month on hardware. This could mean, for large websites, even in the thousands of dollars.

So the three main aspects are the user experiences, the discovery of your website, and how much you’re spending a month on hardware to host your website.

AM: What are some ways we can improve performance, and what do they mean exactly?

JP: I want to come back to, there’s the user and the server involved. So let’s say you are the user. You’re just, like, browsing websites. Get a better Internet connection [laughs]. Or get better hardware. If you’re on a ‘90s laptop, get a better laptop. Because your computer could be spending a lot of time just processing the JavaScript, for example. But probably what you’re interested in is the server side. So you can do the same thing – you can get better hardware. And that’s always going to be the cheapest and simplest. Well, not always, but in the majority of cases, just buying better hardware is going to go further than trying to do performance tuning on your application or website. You’ll probably end up spending less time and less money, and it’s going to be the simplest solution too. One way you could do that is, if you’re not hosting the website or application, you can look at different hosting providers. And they might target your type of organization or your type of website. So it might be worth exploring different hosting providers.

But another really important one when it comes to ways to improve performance is caching. Caching essentially is, I’m a user, I make a request to your website. Caching can happen at a couple of levels. There’s what’s called HTTP proxy caching. That means that when I make a request to your website it’s hitting a proxy cache before it even gets to your server. And there are ways that you can implement that. Another one is application caching. So this means that, okay, I made a request to your website and your website is processing that information, let’s say it’s making a request to the database to get information about staff at your company, An application cache could, instead of inquiring in the database, have a runtime cache that’s reading directly from memory. It’s going to be significantly faster than reading from your database. And then there are things on the database layer that you can do as well for improving caching.

But you asked about improving performance, and I also want to note about the subjective perspective – and this one is really interesting because it’s all about appearance of speed. Here’s a warning, though, that when you talk about the subjective experience of performance – it either gets really technical or very sensitive, from the user’s experience.

AM: Why is that?

JP: Technically, it gets really complex because, for example, when we start talking about loading the critical path of CSS first, or how to paint your website as it shows above the fold first – being able to implement that takes technical knowledge that a lot of people don’t have. That takes a level of front-end development experience that most people wouldn’t be able to have a conversation about, unless they’re a FED.

AM: Front end developer, you mean [laughs].

JP: Yeah, yeah, thank you [laughs]. One of the problems of talking in technology is that there’s so many acronyms.

AM: That’s why I’m here to help [laughs].

JP: Please pause me any time [laughs]. So another example is lazy loading JavaScript and images. That’s something you wouldn’t know how to do. If you have a WordPress site, there might be a plug-in that can address some of these, but the actual implementation is really complex. Or pre-fetching pages or DNS requests, those are things that are really technical. So that’s what I mean by, it gets technical very quickly. Because those are all subjective still, from the user. The application as a whole isn’t changing. Even if you load above the fold, you load that CSS, the browser still needs to render the full page. So it’s still a subjective thing. But from the user experience, you can do things like asynchronous buttons. I gave the example of sending an email. So the user clicks an email, and right away, it says, hey, you’ve sent an email, great! Well, it didn’t actually complete. There’s still processing happening in the background. So for the user experience, it feels fast, but objectively speaking it’s no faster. You’ve not improved the objective performance – it just appears faster to the user. And this is why I say it’s very sensitive from the user experience perspective. It might be really frustrating if you hit the button and it sends an email, but you maybe don’t get a proper error message back. You’re talking to your friend, and you’re like, did you get the email, and he’s like, no, and two days later you get a reply saying ‘email failed to send’ or something [laughs].

AM: And you say, but I just sent it! Why isn’t it there? [laughs]

JP:  Oh, and another great example of this is asynchronous file uploads. How many of you have tried uploading a whole bunch of files? Objectively speaking, the time it takes for that file to transfer over the network is basically consistent, unless you address those objective concerns. But one of the things you can do is, you can allow for multiple files to upload at the same time. So imagine the user being able to drag and drop a whole bunch of files, or being able to drag and drop a folder to have them upload. It’s still objectively taking the same amount of time, but from the user experience, it feels really good because you’re not spending time uploading each file, waiting for it to complete, load another, et cetera.

AM: So it sounds like the responsibility is shared among a lot of people, because if you’re the owner of a WordPress site, for example, and you’re not an engineer, there are certain plug-ins that you can effect on the back end. Once you have the admin ability to do that, you can do some work. And the engineer obviously can influence a lot. Is there one person who should be more versed and responsible for performance, or should it be a shared responsibility?

JP: That’s a really good question.

AM: Or does it just depend on the organization? [laughs]

JP: Well, things like performance and security, anything on that level, a high-level look at your website – those are going to be relative to your needs as an organization, because maybe performance isn’t a major concern. Maybe the website you’re talking about is an internal application and it’s okay to have a two-second load or something like that. Maybe that’s just understood. I would say that there needs to be terminology and a common understanding among your whole organization and among whatever vendors you’re working with – anyone who is responsible for the website or is actually implementing the website. Everybody needs to be understanding about some basic terminology, so they know what you’re talking about. Conversations about security and performance, like I said, they can get really squishy. So having that terminology is really important, so that you’re not conflating ideas.

But I would say, if you wanted to point at specific people, look to people like your senior FEDs or your senior engineers. Or look to your sysadmins or your DB admins. System admins are the people who are hosting. DB admins are the people who run the databases. Essentially, look to the people with high technical expertise. It’s not unlike SEO – it’s not infrequent that you find people who think they know what they’re talking about when it comes to SEO. And it’s often the case with security and performance that you find people who think they know what they’re talking about. Just make sure you’re talking with experts when it comes to performance.

AM: Well, what is ideal performance? I understand that it’s going to depend greatly, as you mentioned earlier, if someone’s got an internal site where performance doesn’t matter, then a two-second load time is fine and it’s not so critical. But there must be some general benchmarks that we’re trying to hit here.

JP: Absolutely. And this is a great question because we’re sort of talking about, what do we accept as humans? In the end, that’s what it comes down to – what do we accept per month in hosting costs? Or what do we accept when I make a request to Google? How long am I willing to wait to get the little search bar to come up? There’s definitely the subjective element, but when we look at ideal performance, you can look at averages across websites. And I would encourage you to look up what averages are for websites, because that’s something you could set as a baseline. But my personal take is, averages tend to move you away from what’s actually acceptable.

So, for example, average page weight is 2 MB. Let’s say you’re a restaurant, and you have a website for your restaurant. Most people are going to be looking at your website on a mobile device. 2 MB is not going to be a good experience for them, unless they’re on LTE, which means they’re on a newer iPhone or a newer mobile device. So if you’re shooting for that average of 2 MB, you might be missing out on your key customers to your website.

But I would say, in general, most pages that the users experience that feel okay with the time to first paint, or the time to when they actually see the first information on the screen, is generally a second. Or less than a second. That’s about as long as most people feel comfortable waiting. If you’re advanced in looking at performance, or if you can look at the network requests, typically people are looking at around 100 milliseconds per network request. That would be considered fast, or ideal if you will. And if we’re looking at mobile page weight, we’re looking at about 20 KB. Again, the average is about 2 MB, but the mobile page weight recommended by W3C is about 20 KB.

AM: So there’s a lot of work to do there across the web universe, if the average is 2 MB and we’re trying to get it down to 20 KB for mobile. So generally you want your network request time to be less than 100 milliseconds, and time to first paint, as it’s called, to be less than one second, or around one second. And mobile page weight to be 20 KB. Those are some good general principles.

JP: Yes, but that said, these numbers change over time. So listen to the experts who are dealing with this on a day-to-day basis.

AM: And who are those experts? How do you find one?

JP: That’s a good question. Talk to the experts in your own organization. If you have a senior engineer or senior technical staff, talk to them about this. Get their ideas. Or task them with, hey, spend a bit of time and go find out where our website performance is at and where should we be. But as far as places to look, I’ve seen some really great things. W3C has a mobile website validator, and that will give you some indicators as to where your mobile website is compared to other websites. Luke Wroblewski, his website is lukew.com, he comes up with some really great articles about where performance is currently, and just some really great dialogue about performance. Smashing magazine has some really great conversations about some user experience things you can do for performance. And if you have a highly advanced web site or web application, highscalability.com has some really great information. But that would be targeting more the database administrators and the system administrators.

AM: Does the content management system, the CMS, does it make a difference?

JP: Certainly, but I think we need to start with: does it make a difference with what? What exactly are we wanting to look at when it comes to performance? If we’re talking about performance on the server, yes, absolutely. Say you’re using Drupal, for example, which is a content management system or CMS. If you’re using PHP7, it’s going to have a drastic performance difference than PHP5. Another thing is, is there application cache implemented in your CMS? If you’re using WordPress, there’s caching plug-ins you can use. If you’re using Drupal, there’s modules you can install that address application cache.

So yes, your CMS can make a difference. If you’re looking at, our server response times are really slow, yeah, definitely look at what your CMS is doing. I’m assuming, though, the way your set is architected is your CMS is not only where you modify content, but it’s also serving content. Some websites might be what’s called headless, or maybe you’ve heard of single-page applications. The content is not actually being rendered by your content management system. It’s either API serving network requests, or some other system is consuming that content. But those are more complex cases. Typically you’re using a CMS and that’s what’s rendering your pages. So definitely the CMS makes a difference, for sure.

AM: Well, I’m going to ask another obvious question. How does improving performance on a website save that website, or the people running that website, money? What’s the tangible benefit that they get? I can immediately think of the fact that, you know, if you’re trying to fill out an application online and it’s frustrating, of course you don’t complete the application. You’ll probably see in your Google Analytics a drop-off at that point where your application’s not getting completed and you’ve lost that customer. So those sorts of things. What other tangible benefits can someone see from improving performance?

JP: Oh, this is a fun question. So I wish I had some stories ready [laughs]. You may have heard of websites, like Amazon for example, moving a button, and their conversion – like, for example, their checkout experience could result in thousands of dollars’ difference.

AM: I would say millions of dollars’ difference if they’re Amazon [laughs].

JP: Some of them are! Some of them are stories in the millions of dollars, where just changing the user experience has resulted in huge revenue changes, Now that gets into the territory of, when we talk about performance, when we talk about user experience – coming back into performance, though, that can move you into UX territory, user experience territory. But coming to performance, yes, if you have a website that is taking too long, you very well might be losing users. I don’t know if you’ve seen Etsy – I don’t use Etsy but I follow their development blog, and they have some really good articles talking very candidly and very openly about their website performance. And it’s really interesting to hear them try to make the connection between website traffic and revenue, and how it relates to performance. So while I can’t give you a very clear, like X, Y, and Z translate to this dollar amount – again, this is why I go back to, talk to experts. Because they’re going to be able to walk you through, for your scenario, what performance is going to mean, and what dollar amounts. You can save significant money.

I would say, one important thing to know about performance is that it’s not a convenience any more. A fast website is not a marketable thing. Like, it’s baseline.

AM: It’s expected.

JP: It’s expected that your website is performing. You’re going to see more and more people who simply don’t traffic websites that are slow.

AM: Are there ways to improve performance that are not visual? Something happening on the back end that can be improved, response time of queries, what can be done specifically there?

JP: Yeah, absolutely. This is definitely going to depend on your website. If it’s Drupal, there’s definitely going to be things you want to look at that are not visual. If it’s WordPress, there are different things. And this is why people pay for system administrators and database administrators. They understand how to deal with these things. And your expert front end developers and your expert programmers, they’re going to be able to talk through where your website is and what things you can tweak.

But, yeah, there’s definitely things you can do that are system-related. One of the exciting things is, there’s a phrase that’s, like, HTTP caching is great but nobody’s using it. It’s definitely worth taking a look. Talk to someone who understands HTTP caching and see if your website has caching headers. If you’re using a lot of images on your site, make sure they’re being served from a content delivery network, a CDN. There’s a lot of things that aren’t visual that are going to impact performance.

So the key things I would say are, look at cacheing, look at how your content is delivered on the site. Make sure your JavaScript and CSS are being minified. And take a look at how your website is hosted. A great way to evaluate where you need to look is, there’s a browser plug-in called YSlow, it’s from Yahoo. It’ll give you some quick metrics to look at to see where or how your website is performing. Because if it’s network time, you may look to the hosting provider – maybe you have a conversation with them, or get a recommendation about another hosting provider. Or if it’s page weight, maybe what you might consider is eliminating some images on the website, but that definitely ties into visual. But there’s non-visual things you can do to impact performance, and I would say that’s where you should first start looking. Assuming this isn’t a ‘90s website with a whole bunch of images [laughs].

AM: Flying unicorns [laughs].

JP: Yes, assuming you have a reasonably well-designed modern website [laughs], I would first look to the non-visual things and how that’s impacting your performance.

AM: So the grand Internet in which we all live is getting faster, bigger, stronger all the time, every second. Are there things coming down the pipe that we can prepare for, or anticipate, to keep performance high?

JP: Yes. Gosh, there’s a lot I want to say here! I would say one thing to be continually looked forward to for the foreseeable future is, hardware is getting faster. It’s still getting faster. Now there are some plateaus because there’s a balance between hardware commoditized and how much money can be generated from faster hardware. But there’s still things coming down the pipe. One of the things is, I was at a conference last year, and I saw where they’re using a certain type of hard disk, it’s actually a PCIe card[F1] , it’s not actually like what most people think of as a hard disk, it’s very different from that. And they were able to achieve an order of magnitude increase in throughput when writing to disk. So there’s definitely things that are coming down the pipe from a hardware perspective. One of the things that I’ve seen, too, from a hardware perspective, is that there’s hardware that’s now targeting certain applications. So you can buy a server that’s designed and optimized for MySQL[F2] . Now that doesn’t substitute for having a database administrator and a good technical team, but that’s something to look forward to as to where hardware is going.

Another thing that’s exciting is that languages are maturing.

AM: Computer languages?

JP: Yes, computer languages. So WordPress and Drupal are written in PHP, so the code that’s executing on the server is PHP. One of the things that’s really exciting in the PHP community is PHP7 has been released. And for Drupal, some benchmarks I’ve seen are a 70% increase in performance in Drupal using PHP7. So we will see some things on the programming language level that are exciting.

Another thing that’s exciting is that hosting providers are becoming – for lack of a better word, they’re maturing. They’re able to commoditize very interesting things that are simply very challenging to do, as a small organization or even a mid-size organization. Things like geo-distributed content delivery. Some hosting providers will, out of the box, take your images and serve them from the closest data center to your users. That’s something that frankly a lot of people don’t even know how to implement.

So to summarize, there’s going to be great things coming with hardware, great things coming from programming languages, and hosting providers are bringing some really exciting things.

AM: Sounds cool! So to use a sports analogy, what’s the Olympic gold medalist of websites? What’s the best performing site you've seen out there that you can recommend – what for you is the best one?

JP: From my perspective – Google. Anything Google, both from the objective and subjective experience. Google is so simple, their interfaces are so simple. That said, there are some things that I don’t like [laughs], but in general you don’t see the kind of clutter in user experience that you do in some other search websites. The simplicity is brilliant.

AM: But you’re talking more from a UX perspective, right? Or are you talking performance?

JP: From a UX perspective, yes. For example, I’m sure a lot of people saw the change -  I don’t recall when this was, but in the last couple of years – you type in your search query and Google automatically auto-populates the list for you. That’s an example of a performance improvement that isn’t objective, it’s a subjective improvement, but the ability to see your list of results is faster. But they do things on the server level that are simply unbelievable. If you read any of the Google developer blogs – it would be truly amazing to see what they’re doing.

I would say the most interesting, though, is Facebook. They’ve pioneered some really interesting subjective performance things. So, for example, if you go to your Facebook profile, if you’re on a slow connection you’ll see various areas of the website that are loading faster than others. Basically, each section of the website is broken down into components that can load independently of each other. So they’re doing some really interesting things that I like. But the gold medal I would have to give to Google.

AM: With a silver to Facebook [laughs].

JP: Yep [laughs].

AM: All right, great. Well, thank you, Joe, for trying to help everyone out there have a better performing website.

JP: Yeah, sure thing. Glad to share.

AM: Thank you so much for listening. If you want to hear more episodes of On the Air with Palantir, make sure to subscribe on our website at palantir.net. You can also follow us on Twitter at @palantir, or read our blog at palantir.net. Thanks so much!

Development Site Building