Synthetic Monitoring

Simulate visitor interaction with your site to monitor the end user experience.

View Product Info

FEATURES

Simulate visitor interaction

Identify bottlenecks and speed up your website.

Learn More

Real User Monitoring

Enhance your site performance with data from actual site visitors

View Product Info

FEATURES

Real user insights in real time

Know how your site or web app is performing with real user insights

Learn More

Infrastructure Monitoring Powered by SolarWinds AppOptics

Instant visibility into servers, virtual hosts, and containerized environments

View Infrastructure Monitoring Info
Comprehensive set of turnkey infrastructure integrations

Including dozens of AWS and Azure services, container orchestrations like Docker and Kubernetes, and more 

Learn More

Application Performance Monitoring Powered by SolarWinds AppOptics

Comprehensive, full-stack visibility, and troubleshooting

View Application Performance Monitoring Info
Complete visibility into application issues

Pinpoint the root cause down to a poor-performing line of code

Learn More

Log Management and Analytics Powered by SolarWinds Loggly

Integrated, cost-effective, hosted, and scalable full-stack, multi-source log management

 View Log Management and Analytics Info
Collect, search, and analyze log data

Quickly jump into the relevant logs to accelerate troubleshooting

Learn More

10 questions about web performance – Jeremy Keith at Clearleft

10 questions about web performance

This is the first in a series of interviews about web performance. We kick off the series by talking with Jeremy Keith, the Technical Director at Clearleft, a UX agency in Brighton, United Kingdom. Jeremy has authored a number of books on topics including HTML5, Ajax, and DOM scripting.

Let’s find out what Jeremy thinks of the current state of web performance.

Would you be surprised if we tell you he has a lot to say on this topic?

Pingdom: Why is web performance such a hot topic right now?

Jeremy: Yeah, finally. Finally. Which is good, it should’ve been a hot topic forever. But people got really complacent there for awhile. I think everyone was building websites under the assumption that everybody had broadband connections.

Pingdom: There’s a lot of evidence that web users tend to leave a website if it loads slowly. Are users getting more demanding and impatient, or are there other reasons behind this?

Jeremy: I think the emergence of the mobile web has contributed to this, for sure. That was the kick up the behind basically. And it’s a good thing. Like I said, I think we should’ve been paying attention anyway, because it’s always been a myth; this idea that everyone on a desktop computer has a broadband pipe. That’s never been the case and particularly in certain countries. I got home to Ireland at Christmas time and used a modem to get online and then you really, really appreciate fast sites.

So yes it’s the rise of mobile that’s kind of thrown it into sharp relief, but it was always a problem. It’s like so many things, mobile is highlighting the problem but the problem was always there.

It’s the same with the way we’ve been building fixed-width sites 960 pixels wide or whatever. That was always under an illusion that everybody had screens of a certain size. And now with the rise of mobile people are realizing that ‘oh we need to build flexible layouts.’ That situation wasn’t created by mobile, it was highlighted by mobile. I absolutely welcome it, I wish we had been paying more attention to it sooner.

Jeremy Keith

Pingdom: Web performance involves a lot of testing and numbers. But at the end of the day, isn’t a user’s experience a personal and subjective experience? How do you reconcile the two?

Jeremy: Absolutely and I think there can be a very developer mindset approaching problems where we are focused on numbers and we’re focused on time, without thinking about how it actually feel to the user.

A good example of this is the whole responsive image question where everyone’s coming up with different solutions. Obviously performance is a real question because we don’t want to make two HTTP requests for an image, you wanna make just one if possible. But now, how do you serve the bigger image to the desktop and the smaller to mobile and all that? And there are all these different solutions concentrating on reducing HTTP requests, reducing file sizes etc and that’s great.

But a colleague of mine, Josh, was working on a project where he realized that what he would do, was he would have the small image there by default, but in his stylesheet he would declare it to be really large. It might be a picture that’s only 150 pixels wide, but in the stylesheet inside a media query he’d say he want it to be 500 pixels wide.

Now, that’s gonna look really pixelated and gross, but, he then uses JavaScript *after* the page is loaded to swap out the larger image. On the face of it, if just looking at the numbers that’s bad, because there’s two HTTP requests and you downloaded two images when you all you needed was the large image.

But… The user experience of it is actually really that the user gets something straight away. It’s very much like, if you remember, the low src attribute. You get something and then it’s replaced with the final image.

If you are just looking at the numbers you would say that this solution is not good because there’s too many bytes downloaded, too many HTTP requests. But if you test with people, it turns out it feels snappy! So it’s much more about the perceived performance than the numbers.

Pingdom: What about performance and user testing?

Jeremy: Well, at Clearleft we’re working hard especially on tools for performance and user testing. Whenever possible we try to do user testing. Although what we might be user testing is not necessarily the finished site and we could be using wireframes because it’s more about the flow and interaction.

But yes, as front-end developers, certainly, we do the tools to try and identify where can we shave off some time. The issue for us is that we’re handing over work to somebody else to then turn into the finished website. What we hand over we make as performant as we can, but it’s still not the same as testing the final website.

We are very much focused on the front-end optimization, things like Base64 encoding, background images directly into CSS where possible, CSS sprites. Sometimes combining the two if possible like Base64 encoded sprites. We are reducing HTTP requests, trying to reduce dependencies on libraries where possible.

Pingdom: Best practice in mobile web performance isn’t as well established as in other fields like desktop. Are we getting closer to a sort of universal agreement or understanding of performance in the mobile space as well?

Jeremy: Well, there has been a best practices document up on the W3C site for years now. It was finalized a few years ago. It’s really good, it’s nothing unexpected in there it’s all the sensible stuff; small downloads reduce HTTP requests.

What I really like about it is that everything in it applies to web development in general. You can ditch the word mobile. And I think that’s true in general, when people talk about mobile best practices usually my response is “why just mobile?”

Because even if you do have a fast connection on a desktop people still really appreciate those differences. They might be minute differences of a 10th of a second but they really do make a difference. I don’t want people to think that mobile performance is just for mobile.

There are certain things that are more or less beyond our control. I’m thinking of operators and the connection can drop. Also sometimes operators try to helpful by doing compression and often making a mess of things. Like when you get half a JavaScript file which is worse than getting no JavaScript file.

And there’s not much we can do apart from try to build your website as robust as possible. But even then, you can’t defend yourself against maybe half your JavaScript will load. And it’s really frustrating on mobile.

Pingdom: With everyone talking about cloud, it seems to be everywhere. What’s your view on cloud and web performance?

Jeremy: (Laughing) The term ‘cloud’ is not something I normally use. When most people talk about ‘the cloud’, I mentally substitute it for the word ‘moon’ and that makes the conversation so much more entertaining. But if you mean using 3rd party resources instead of hosting everything yourself, sure.

Pingdom: So do you get a final say in performance once the backend bits are implemented?

Jeremy: We always try to budget in time for a discussion and a review. I wouldn’t say we have a final say but we at least get to have that discussion. We have historically run into issues where for example the server side framework is making the decisions rather than the human beings.

While what we have handed over is as performant as possible, the site might then get implemented using a CMS that precedes to call in 10 stylesheets in the head. And it’s not too much we can do about that, it’s the client’s decision to go with that server side technology.

It kind of points to a bigger issues which is our tools. There are issues with our tools from two directions: Firstly on the design side when we use things like Photoshop and Fireworks there are no penalties in those tools for using gigantic images or for putting in design flourishes that are hard to implement or gonna be tough on performance like using 50 different fonts in your design for example.

But then also from the other end of the CMS, a lot of time CMS’s have been built with the idea that a website is something you view on a desktop browser or a desktop computer which of course isn’t true anymore. Websites can view everywhere on all sorts of devices but CMS’s aren’t adapting to that truth.

Pingdom: Would you say that one of the common bottlenecks or errors/mistakes people do in terms of JavaScript and performance has to do with libraries?

Jeremy: There’s always gonna be a balance of developer-convenience to user-convenience (or usability). There might not be a conflict in our work, like if you decide you’re going to use a server-side to help you as a developer achieve your task that’s fine, there’s no penalty for the user.

The issue is with JavaScript because it’s client-side. Anytime you do something, even if it’s for a good reason for developer-convenience often, the user is the one who is going to have to pay for that convenience.

So, if I can avoid using any kind of dependencies I will, whether that’s a JavaScript library or a font that’s being loaded in with @font-face. Do I really need it? Or could I get away without it?

Pingdom: What are we going to see happen in the next few years in terms of web performance?

Jeremy: We have been getting the message out for years (about not everyone having a broadband connection). I was hoping things was heading that way and it’s finally seems to be sinking in, again thanks to the rise of mobile, that websites do not need to look the same in every browser.

We’ve been winning small battles with little things like gradients and rounded corners, where I think most people now realize that it’s okay to make that in CSS and you don’t need background images. And it’s okay if not every browser gets that.

So there has been a good trajectory generally, slow but good trajectory, with stuff like that: the details can be much more performant using CSS. And again, the rise of mobile is making people aware they can’t really be throwing everything onto the screen but need to think about what the most important content is.

However… With the release of devices like the new iPad with the Retina display, are we gonna start seeing really large images? And are they gonna be served up to everyone and then shrink them down? I am a little concerned.

On the plus side, it will hopefully start people looking at alternate non-bitmap technologies, things like SVG, which are really useful and have been around for awhile. Browser support is good. Obviously you can’t use it for photographic imagery but for iconography and things like that. Potentially SVG could be inline and you’re reducing HTTP requests as well.

Generally I do think developers are starting to care more and more, partly thanks to the tireless efforts of people like Steve Souders who are preaching this stuff, which is great.

Although, again, I do still see people making this distinction between the mobile web and the rest of the web, which I think is a fairly artificial distinction.

Pingdom: Is there something exciting that you or your company is working on in terms of web performance that you can tell us about?

Jeremy: Nothing much that I can tell you about, but I will be at Mobilism in the Netherlands where I’ll be moderating panels. It’s a mobile focused conference and there will be representatives there from browser vendors making mobile browsers. We did the first Mobilism last year and it was really good fun. There are still tickets available.

About Jeremy Keith

Jeremy Keith is the Technical Director at Clearleft, a UX agency from Brighton, United Kingdom. He is the author of HTML5 for Web Designers, Bulletproof Ajax and DOM Scripting. In short, he make websites and is specializing in HTML, CSS and Javascript. He claims his favorite word is callipygian, it is however not used in this interview, thank goodness.

About the “10 questions about web performance” interview series

We have gathered some of the best and brightest minds in the web and IT industry to a discussion about web performance. Over the next few weeks and months, we’ll be rolling out a series of interviews, bringing together people from web design, mobile and computer hardware, web hosting, software, and other areas. You can find all the interviews in this series on the Royal Pingdom blog.

Introduction to Observability

These days, systems and applications evolve at a rapid pace. This makes analyzi [...]

Webpages Are Getting Larger Every Year, and Here’s Why it Matters

Last updated: February 29, 2024 Average size of a webpage matters because it [...]

A Beginner’s Guide to Using CDNs

Last updated: February 28, 2024 Websites have become larger and more complex [...]

The Five Most Common HTTP Errors According to Google

Last updated: February 28, 2024 Sometimes when you try to visit a web page, [...]

Page Load Time vs. Response Time – What Is the Difference?

Last updated: February 28, 2024 Page load time and response time are key met [...]

Monitor your website’s uptime and performance

With Pingdom's website monitoring you are always the first to know when your site is in trouble, and as a result you are making the Internet faster and more reliable. Nice, huh?

START YOUR FREE 30-DAY TRIAL

MONITOR YOUR WEB APPLICATION PERFORMANCE

Gain availability and performance insights with Pingdom – a comprehensive web application performance and digital experience monitoring tool.

START YOUR FREE 30-DAY TRIAL
Start monitoring for free