Web Performance: 20+ Experts Share Their Advice and Mistakes

We had a lot of great feedback from the community on our previous post, web performance experts to follow online. We thought we would take it a step further and ask those experts to share their advice and common mistakes that they see people making when it comes to web performance and which optimizations you should spend time prioritizing.

Web performance questions

We asked each expert to answer the following two questions.

If there was only one web performance optimization you could focus on, what would it be? What are some common mistakes you see people making when it comes to web performance?

Experts answers

The people on this list were selected in no particular order.

Tim Evko

@Tevko / timevko.website

Lead Frontend Engineer at BaubleBar. Podcaster. Creator of RICG-responsive-images. Writer on CSS-Tricks, Smashing Magazine, SitePoint.

Answer 1 - Advice

Over engineering applications. Specifically the overuse of frameworks and libraries to perform menial tasks. This most commonly leads to decreased speed, mobile support, and heavy web pages.

Answer 2 - Mistakes

Lack of progressive enhancement, failure to properly manage dependencies, not implementing a responsive image solution, and ignoring third party content sizes.

Matt Shull

@TheMattShull / mattshull.com

Producer & Performance Geek for Aristotle where he manages projects and helps shape web performance best practices.

Answer 1 - Advice

A big focus for our performance team is (and will continue to be) optimizing images. The naverage page is around 2200 KB and around 1440 KB are images which means that's a good target for the biggest performance wins. There are a number of file types out there that can help in image compression (*cough* WebP *cough*) and they are underutilized. Yes browser support is a bit hit or miss but browser makes won't implement them if they don't see interest in the community. So do some research and utilize to start using these new image types!

Another optimization that our team is focused on is perceived performance. How fast the user perceives the page to load can impact many things. On the flip side, perceived performance can be affected by many things. Particularly our performance team at Aristotle is looking at how to decrease the perceived performance on mobile networks and we've looked into a number of ways to do this: reducing content, image formats to reduce image size, lazy loading. It seems to be a dance from what we can tell. What works for one site/client doesn't always work for another.

Answer 2 - Mistakes

One of the most common mistakes is not limiting render blocking content. Many sites aren't taking advantage of minification, the defer attribute on <script>'s , or reducing the number of requests. Although I've seen a number of times where people want to but are afraid of how something like deferring the JavaScript might affect the site as a whole.

Una Kravets

@Una / una.im

Frontend Developer at IBMDesign.

Answer 1 - Advice

Images! Developers often focus on improving scripting performance, but they need to realize that the bulk of their performance woes come from media content. The most dramatic performance improvements can come from optimizing content, using proper file formats, and leveraging progressive rendering.

Answer 2 - Mistakes

Mindlessly adding frameworks to websites for small features is unfortunately a trend that we keep seeing and that keeps driving up web page sizes. Performance needs to be thought about in the beginning of a product's lifecycle, not at the end.

Aaron Gustafson

Web standards advocate at Microsoft. Author of Adaptive Web Design.

Answer 1 - Advice

First and foremost, I focus on the content that matters. Every part of a page should be viewed through the lens of whether it supports the primary purpose of the page. Images? Social media share links? Related content? Maintaining focus in this way is the first step toward optimizing the performance of your website.

Answer 2 - Mistakes

On occasion I see people focusing on web optimization techniques that offer only modest gains backend script execution time, for instance, while ignoring low-hanging fruit like image optimization or even choosing the best image format.

Jeff Atwood

@codinghorror / blog.codinghorror.com

Co-founder of Stack Exchange and Discourse.

Answer 1 - Advice

HTTP/2 adoption across the board - huge improvements for everyone.

Answer 2 - Mistakes

Failing to run basic web performance checks using freely available web performance tools like Google PageSpeed.

Dean Hume

@DeanoHume / deanhume.com

Software developer. Author of Fast ASP.NET Websites, a book aimed at improving the performance of high transaction websites.

Answer 1 - Advice

If there was only one optimization to focus on it would be images! According to the HTTP archive they make up over 60% of the weight of a web page, so it makes sense to focus there.

Answer 2 - Mistakes

Some of the most common mistakes are really simple ones to make. They include not optimizing images and not turning Gzip on, these are such quick wins everyone should do them!

Harry Roberts

@csswizardry / csswizardry.com

Consultant Frontend Architect: Google, UN, BBC, Kickstarter.

Answer 1 - Advice

For me personally, I'd like to cast a wide net and say CSS. I'd love to get people more clued on CSS' impact on performance, because it's an enormous bottleneck-getting it along the Critical Path as quickly as possible in order to begin rendering sooner; not serving it from an asset domain/CDN; removing unused rules; inlining critical CSS; avoiding @imports and Base64; animating 'cheaper' properties (e.g. opacity over rgba() ); avoiding repaints; even the selectors themselves.

There is so much in CSS that can drastically harm or improve performance depending on how you tackle it, and it's all pretty fascinating stuff. I'd love to be able to focus solely on the performance impact of CSS-there is so much to be done there, and it's my favorite kind of work.

Answer 2 - Mistakes

Wow. There are so many! Probably the pursuit of purely number-based metrics (page weight, number of requests, etc.) and not on the perceived performance of your apps. All that matters, really, is how fast the site feels, and how quickly a user can begin to interact with it. A site with 100 requests that is usable within 1.5s is vastly superior to a site that has 32 requests and isn't usable for 7s. Less focus on developer metrics, more focus on user metrics.

Sergey Chernyshev

@sergeyche / sergeychernyshev.com

Web technologist with passion for web performance and open source. Organizer of Meetup: NY Web Performance and WebPerfDays NY.

Answer 1 - Advice

Try to not load any JavaScript on the page, at least until you're done developing the layout and CSS for the page - it will help you code it better and properly load code asynchronously.

Answer 2 - Mistakes

The most common mistake is oversize images - it's a simple matter of ensuring small file size for static assets, but pages these days are just bloated. There are many others like many JS and CSS calls on the page which causes late rendering and my favorite, huge carousel above the fold which loads after everything else.

Patrick Meenan

@patmeenan / webpagetest.org

Creator of WebPageTest, Chrome Engineer at Google.

Answer 1 - Advice

Deliver the minimum bits needed for the user experience first. This may be cheating a bit since it technically includes image optimization, compression, async js, lazy loading images and most of the typical optimizations but I think it works as a useful lens when looking at a site and to guide the optimization work. As you look through a waterfall (preferably aligned with the filmstrip of the page loading), look at each request and see if it is necessary yet or if it is competing with something later that is needed for the experience (and if it is as optimized as it could be).That will help keep the focus on the user experience and will lead to a much better result than tracking something like the on load time.

Answer 2 - Mistakes

For the most part, all of the issues I see are still classic optimization 101 issues (even on larger sites).

Horrible performance on cheap hosting. This isn't usually a problem for medium/large sites but the long tail of the web is usually hosted on really cheap shared hosting plans where the servers are horribly oversubscribed. It's not unusual to see backend times well over 5 seconds. For everything that isn't just a hobby site it's worth investing the few dollars that even a low-end VPS will provide (though at times that takes more technical skill than the site owners have).- Poor image compression. This spans everything from serving 24-bit PNG's for photos to high-resolution, high quality JPEGs instead of a reasonable quality level. Browser-specific formats would be nice but even getting regular image compression working consistently is a challenge, particularly for content sites where editors can upload article photos.

Explosion of third party dependencies. Chat bots, analytics, retargeting, ads, social widgets, etc. The number of domains that are relied on for assembling pages these days is exploding and is going to eliminate a lot of the optimizations and benefit that HTTP/2 provides.

Lots of external scripts and CSS, loaded in the head, synchronously. Tag managers loaded synchronously. They completely obscure the content from the browser's preload scanner and cause huge blocking delays as they document.write more blocking third party scripts.

Sara Soueidan

@SaraSoueidan / sarasoueidan.com

Frontend developer and SVG advocate.

Answer 1 - Advice

Image optimization. Optimize and use responsive images ( <image> and the srcset attribute). I'm almost always on a slow connection and the amount of time it takes images to load on most websites is just horrid.

Answer 2 - Mistakes

Not optimizing images, and loading too many unused font faces/variations of a font. I find that these two are the most common causes of long page loading times in the vast majority of websites I browse on the web.

Anselm Hannemann

@helloanselm / helloanselm.com

Frontend developer creating solid, scalable code architectures. Curator of the WDRL Newsletter.

Answer 1 - Advice

The most important thing about web performance is to have a proper technical concept before starting a project. If you keep the principles of the web and browsers in mind, like, the fetching, parsing and loading order of resources, it's the biggest improvement to performance you can get and way more effective than micro-optimizations like minification. Invest into delivering your resources as fast as possible to the browser, and, for example, don't serve styles via JavaScript unless you have a strong reason to do this as a performance improvement.

Answer 2 - Mistakes

People tend to rather do a lot of micro-optimizations but then, because we have too many things we can optimize these days, miss out on the really important performance improvements and make the whole application more complex due to the micro-optimizations.

Patrick Sexton

@PatrickSexton / varvy.com

Creator of GetListed.org and now runs Varvy, free SEO and web perf tools.

Answer 1 - Advice

Images. Optimizing and deferring images will speed up any web page with very little pain.

Answer 2 - Mistakes

I think the most common mistake is when frameworks are used for things that can be done without them. I have seen people add jQuery for some crazy reasons, like just to move an image up a couple pixels or some other simple task. Frameworks for CSS are also all too common. We seem to forget that we are making web pages for the user, not the convenience of the designer or coder. The "convenience" of frameworks is why web pages are getting larger and larger. By far the most common problem in web performance today.

Christian Heilmann

@codepo8 / christianheilmann.com

Developer Evangelist - Works at Microsoft on Edge.

Answer 1 - Advice

Images. Images are by far the biggest problem we have on the web. Learn about optimization, using different image formats, set up your CMS to allow for responsive images, stop using an image for everything.

Answer 2 - Mistakes

A lot of people do a good job optimizing their main product, but then they clog it up with third party scripts, includes and services that aren't performance optimized. You don't need a button for each social network - stop using those. It is still fashionable to have scrolling pages (parallax) but people forget to tell the browser with will change or transforms to create an own layer for the fixed part. This is incredibly important. Most importantly, people test their product on high-end hardware with fast connections. Spend some money buying mid to low range devices and test on those. Throttle your connections in developer tools. Your setup is very much not what your end users have.

Peter Cooper

@peterc / peterc.org

Publisher-in-chief at CooperPress which publishes Web Operations Weekly. Software developer and code experimenter.

Answer 1 - Advice

The user experience. While numbers provide an important way to measure the effects of optimizations, ultimately it's (usually) real people who use our sites and the most important thing is their perception and experience. If including an extra element helps them perceive the site as loading faster, even if it's not, by the numbers, that element is welcome IMHO.

Answer 2 - Mistakes

As an industry, we have a tendency to swing too far one way or another when different trends become popular. I'm starting to get the feeling a focus on web performance is coming, temporarily, at the expense of thinking about Web architecture and overall design of sites. A page may load quickly, but if it's not working in the context of a cohesive site that does what the end user wants, all that speed is a waste of time.

Another possible issue is when people focus on making their homepages load as quickly as possible, but don't invest as much effort elsewhere. Thanks to social media, the importance of the homepage is falling, and users are increasingly being driven directly to content or product pages. Focus where the users are coming into your site, not on the "headline" locations that the CXO types might be worried about.

Kent Alstad

@kentalstad / cloud.army

VP of Acceleration at Radware. Tech innovator & performance researcher with a (seemingly) simple goal: to make the Internet faster.

Answer 1 - Advice

It is hard for me to narrow the focus to a single optimization. I think there are some key areas to focus on: Images are a large part of most applications so delivering the best image for each user context and caching the images at the right locations for reuse usually results in big wins. Fixing or decoupling third party component performance from your application user experience keeps application SLAs in your control. And lastly think HTTP/2 related optimizations that move many traditionally HTML transformation optimizations to the network layer where the optimizations are less intrusive for developers and often more effective.

Answer 2 - Mistakes

Failing to realize that measuring performance, and the related optimization improvements, is often just as difficult (both technically and conceptually) as making the improvements themselves. Sort of a twist on, you can't manage what you can't measure. For example you may make a change and see that RUM stats take a turn for the worse when you are 40% confident that you are 5% slower with your new optimized code. It turns out that measurement and education around what is required for sound statistical decision making are not simple things to communicate and not everyone understands the results and measurements at a level required to make good decisions.

To address this problem you can communicate an agreed upon measurement criteria so you can work effectively through the cycles of making improvements and then measuring the improvements. Another common mistake is letting developers react to performance problems with their old familiar tool, namely, writing or rewriting code. The first response should always be to measure and isolate the problem. Most of the time the problems are in the frontend code and are unrelated to server side code performance and yet I see a lot of server code rewritten in the name of performance.

I see third party resources confusing a lot of performance teams. Often marketing and other non-dev-ops departments control the addition of new third party beacon or dependencies and when the third parties fail or get slow the developers are not prepared or informed enough to fix the problems. Sites that are concerned with performance and rely on third parties need to have a strategy for managing how third party slow-down or failure will be handled.

Maximiliano Firtman

@firt / firt.mobi

Mobile+web development & consulting. Author of Programming the Mobile Web & jQuery Mobile, from O'Reilly.

Answer 1 - Advice

To extreme techniques for mobile, including delivering ATF content in 1 second, whatever it takes.

Answer 2 - Mistakes

Not measuring on cellular networks and real mobile devices.

Thinking that responsive web design is a goal to achieve losing focus of the real goal: performance.

Underestimating mobile browsers and web views.

and web views. Overusing web fonts.

Andreas Grabner

@grabnerandi / apmblog.dynatrace.com

Andreas Grabner is a software geek and blogs about at Dynatrace.

Answer 1 - Advice

On every page/feature think about "what's the bare minimum we need for this to be functional and usable" -> then get rid of the rest!

Answer 2 - Mistakes

"Works in my browser" attitude -> just because you use Chrome or Safari doesn't mean that the whole world uses these browsers!

Give the app to your mom and see if she can work with it without asking you what to do next to complete the task

Never tested with low bandwidth or different devices -> that would reveal too large (size and dimension) images

Devs often don't think about the Total Cost of a Feature for a single user and the main use cases in their app: how much data do we ask them to download through their mobile connection, how much do we need to pay the CDN for that? how much CPU & Storage do we need that we need to pay our Cloud provider?

Dependency with too many third party services/components

No proper cache layers (browser, CDN, web server and app server)

Wrong sizing of connection pools on web server, app servers, DB servers

Lack of load & performance testing before putting it live!

Functional Green Doesn't Mean Ready To Deploy. Extend your test horizon from "Browser Only" to include the whole delivery chain.

Jason Grigsby

@grigs / cloudfour.com

Co-Founder of Cloud Four. Passionate about the mobile web.

Answer 1 - Advice

Gzip. It has a huge impact on transfer size and is insanely simple to enable on most web servers. Yet, there are still a shocking number of web sites that don't use Gzip. (2nd src) There is no excuse for the large number of sites that don't use Gzip. So while it may not be glamorous, Gzip is the first thing people should do.

Answer 2 - Mistakes

The biggest mistakes come from not working on a culture of performance and instead assigning one or two individuals. Lara Hogan has done a great job of describing the difference between having a janitor cleaning up messes versus having an organization focused on performance. You want the latter, but most companies do the former.

Denys Mishunov

@mishunov / mishunov.me

Frontend developer at FastName and author at Smashing Magazine.

Answer 1 - Advice

Definitely, it would be not performance optimization itself, but *perception* of performance. More often than not, developers overlook the benefits that psychology provides them with. Psychology can give simple yet effective tools for managing user's perception of performance. This is not to say that we should ignore performance optimization in code, assets and so on; we definitely should do that as well in order to save server time, loading time, bandwidth and follow other attributes of "responsible web". But optimizing it all takes time. Psychology gives precious time for developers to do all of that while keeping your users satisfied right here right now.

Answer 2 - Mistakes

Developers concentrate too much on milliseconds, bytes, number of requests. While being an essential part of what we call "performance" these days, they do not constitute a performance site on their own. First of all we should think about how users perceive our sites, not on how many bytes we can save. Only after users' perception is under control can we talk about milliseconds, bytes and number of requests.

Stefan Judis

@stefanjudis / perf-tooling.today

Frontend developer and curator of perf-tooling.today.

Answer 1 - Advice

I'd focus on one which is easy to implement and can have a very big impact. Keeping assets as small as possible can reduce page weight drastically and brings a real benefit for the visitors of a page. This includes minifying text-based files (and also serving them Gzipped), but more importantly using the right type of images ( jpeg, png, SVG - depending on the use case ) with proper compression. Taking care of this will lead to an enormous reduction of page weight.

Answer 2 - Mistakes

The belief that server response times are the only thing that matters in terms of web performance. This is not the case: having the fastest server doesn't mean having a fast website in return. That said, constant monitoring of the frontend is also mandatory task. This includes checking asset file sizes, looking for render blocking requests and controlling network waterfalls.

Stephan Max

@stephanmaxToGo / stephanmax.is

Technical Cloud Specialist for IBMBluemix, frontend developer, author for Sitepoint.

Answer 1 - Advice

Images, definitely. Although "the web is 95% typography" (and I wholeheartedly agree), images still account for roughly 64% of the average bytes per page in January 2016, according to HTTP Archive. The Responsive Images Community Group is doing a tremendous job on standardizing new ways of including responsive images into your web pages. With modern browsers taking more and more metrics into account (CPU, network coverage, screen, etc.), this is something to watch out for in 2016.

Answer 2 - Mistakes

A lot of my clients and even major corporate websites still struggle with the basics, like copy 'n' pasting scripts without thinking about where to put them, whether to load them asynchronously, or whether they need them at all. Every web developer should know what the critical rendering path is all about and how to deal with parser/render/script blocking resources.

Philip Tellis

@bluesmoon / tech.bluesmoon.info

Chief Architect at SOASTA and Co-Founder of LogNormal.

Answer 1 - Advice

Make UIs smooth.

Answer 2 - Mistakes

Not measuring. Too often people fix what they think is a problem based on a bunch of rules without first measuring to set a baseline and then quantify any improvements or regressions.

Summary

As you can see above there is a lot of great advice from people that deal with web performance optimization on a daily basis. A few things to make note of is the importance of image optimization! Almost 50% of all the responses included an emphasis on images and how they relate to page weight. Another factor that a couple mentioned is "perceived performance." Sometimes we over analyze the data and speed tests and we need step back and actually look at it from a user perspective.

You can also subscribe to our web performance experts list on Twitter.