What’s the web performance situation on your main project? For simplicity, but also wide coverage, I broke it down into five choices ranging from a nobody caring to everybody caring. This isn’t about how well you’re doing at performance, but how much it’s a part of the culture of your project.
To vote, the poll is in the sidebar (large screens) or down-there-somewhere (small screens).
It will be interesting to know, right? Performance is such a hot topic these days, is it making an impact such that most teams are wholeheartedly into it? Or is it still a fight? Perhaps most people don’t care still? We’ll find out.
If you ask designers and management if they want great performance, they say yes.
But then the web designer specifies the entire site using web fonts, and then another designer does an infographic using a different font with 10 variants – then they buy the web version so they can make the infographic responsive and accessible.
And then the developer finds out about it.
So basically the designers and management want what they want and it doesn’t occur to them that it impacts performance.
It’s not that they don’t care, they just don’t understand the trade-offs.
This.
It’s rare in an industry for someone to say performance doesn’t matter. But most people only give it lip service.
At least 7 out of 10 times, aesthetics wins out over performance. Loading retina images, custom fonts, HD video is viewed as more important than being quick. (And I realize that performance vs aesthetics isn’t a binary decision, but implementations on a deadline with people who don’t really value performance means the result often is.)
I’ve done some work to decrease load times, often with very good results, by just grabbing low hanging fruit. I once showed the research behind it, did the work, improved the numbers, and even did a small company presentation for it; I was applauded and everyone talked about how performance really matters. Two weeks later it was back to the standard flow.
(I accidentally applied to bob below, with a case of the dumbs. Should have been posted here. Sorry.)
You’re making it seem like developers are the rose petals of performance and designers plain suck.
Blind biased comment.
I’ve worked with an S-load of developers that have no interest, clue or solid knowledge about performance. I give them clean HTML and CSS, and next thing I see: empty tags all over the site in the final output because the content creator didn’t add any content in the CMS for that section. Instead of not injecting the tag because there’s no content, they inject an empty tag because there’s no content.
And then you see the ones in love with Bootstrap. The whole framework.
And then you see the ones that haven’t heard about SVG, let alone worked with it. Asking for PNGs instead… and no, not even as sprite, as separate files.
It’s not that they don’t care, they just don’t understand the trade-offs.
@Ricardo,
Speak for yourself.
I’m merely talking about my situation, not generalizing about all designers or all developers.
Most of the designers here are still print-oriented and consider the web an afterthought. The fact that they even considered buying a web font to make infographics responsive and accessible is actually a pretty large step forward for them.
I never said the devs are blameless. Heck – we use Foundation. But we do what we can – including trying to educate others about those trade-offs.
Trust me – I’ve been doing this since the 90’s. The technology changes but the tug of war between aesthetics and performance never changes.
RioBrewster and Bradley make some excellent points.
“It’s not that they don’t care, they just don’t understand the trade-offs.” nails it.
I’ve been involved in web since the mid ’90s as well. As the web has evolved, people need to evolve along with it. We’re still seeing a lot of print people treating the web as if it’s just another print piece where form rules over function. Clients still want ultimate control over their wysiwyg editors and people are still putting up websites with lorem ipsum text because they care more about the design then content.
A lot of it is simply awareness and understanding. We can have it both ways but there’s going to be compromises along the way; the difference that makes the difference is what compromises are the right ones, for that particular site, at that particular time.
Some designers simply don’t realize/care their tightly kerned mockup and color rendition aren’t going to be perfect… and that’s OK. You can tell right away who cares and who doesn’t—anyone who puts “pixel perfect” in their description of good web design is part of the problem.
Don’t know how to format a document? Just do it in Photoshop and save it out to a JPEG. Problem solved! IMO that’s why those rotating hero banners are still so popular—it’s the last refugee of desktop and print oriented design. Here’s the size of the banner, can you fill it up? Blah…The web has never, ever been a perfect rendition of the Photoshop canvas and how can it be?
As Bradley alluded to, other people are just treating web performance kind of like some clients treat SEO… can’t you just sprinkle some one-time, magic fairy dust over the code, put some keywords and meta tags in, and now our performance problem is solved?
Sorry, guys it doesn’t work that way. Yet there’s plenty of folks who will tell the client “sure, we can do whatever you want” or maybe the race to the bottom happens and you get people simply unqualified to do it right.
Just like branding, if there’s nobody watching over the performance of a site on a continual basis to make sure things are on par, it’s going to go to hell. Just like designers who hand over their site to the client and 2 months later, the colors and brand are all off; it’s no different.
There’s only one right answer. If you didn’t choose “Everybody cares and actively works to maintain and improve” the web performance situation of your main project, then you are losing money. If your boss isn’t on board for performance improvements, there’s plenty of research online you could present to your boss explaining why not going performance first is losing money. If you don’t care about money, do you care about: readers? visitors? bragging rights? You lose all of that if you don’t put performance first.
Pretty much the only situations I can think of where performance doesn’t need to be first is for a personal project that you don’t necessarily want other people to see, and government websites that people are forced to use if they want to get something done.
I’ve long hated the “captive audience” argument with regards to performance, aesthetics, and accessibility. I once worked for a call center, shaving 1 second average off of calls saved 140k a year, yet we were often asked to deliver a product that could be made 10-15 seconds faster by simply setting primary keys on a table or optimizing the sql a little, not to mention the optimizations in the UI. Money left on the table. The other argument we would get is that we didn’t want to pitch labor savings to the client because they don’t want to get rid of staff. Often times it’s all political nonsense that drives development to do the things they do versus reasoned and measured strategy.
At my main gig, the Ninja Forms WordPress plugin, performance is a team thing. But it kind of has to be, being that we maintain a wide spread plugin. It isn’t perfect on all 200,000+ installs, but it is definitely a major team focus.
However, I have worked on other projects that want performance, but can quickly give preference to on other design aesthetics.
Performance is easy to forget about until it slaps you in the face. It is a slow slap, but it still hurts.
It’s not posted yet but The Web Ahead #106 is a #MustListen prior to any discussion of “performance” as it relates to website technology.
http://thewebahead.net/
Speaking as an engineer, I am with my heart and soul FOR performance. Clients also want it (if it ever becomes a topic of discussion), but they often don’t realize that some of their design decisions and wishes might take a heavy toll on performance. Even when they know of the impact, they still might stay with their original design idea unless it is a big bottleneck.
What happens most often is that I “silently” put some more time into optimization in order to keep everyone happy.
Performance is of the essence for our company. We have a team dedicated to only improve client side performance. That is from time to first byte, improving perceived page load times, render optimization, etc. All the other teams working on the front-end code are also into this obviously :-)
I think it’s design of perfomance and at this point can’t agree with RioBrewster and Bradly. If Aestetics and Perfomance being absolutely separated things, one of these parameters could look unnecessary.
Whether you agree or not, that’s the reality for many shops.
If one person is doing both design and code, or if both functions happen on the same team, then you really have no excuse.
But in many situations – ours included – the functions are not integrated and devs don’t have veto power over design decisions.
So as Zoki said, we do what we can to make the design that has been chosen load as quickly as possible.
At the end of the day, it all comes down to people and personalities – regardless of what we tech-geeks like to think.
General comment – I’m not sure if this is considered performance optimization or not, but I’m surprised how many websites out there (every size company) that are still serving up multi-meg home/child pages (4MB+) for mobile devices. Do you lump bandwidth considerations into performance or is that a separate issue? TTFB is critical, but I think so is being considerate of the end user’s data plan.
I feel like a lot of the performance issues we run into exist because there is a still a brick wall between design and development. At least where I have worked, the designers know every little of what goes in to making a website, and even some of the developers didn’t think too much about performance. Like others are saying, aesthetics are winning out because you can see what they look like vs the actual impact of using large images and not factoring in real use conditions.
We get too comfortable with our fast work internet connections, it is important we use our 4G connections and throttle our desktop devices to see what really happens in the real world.
I think having a way to quantify the impact is important because most people while at work never see how the average user will use their product. Etsy does a great job of this, they have a dashboard that shows their load times across devices/locations.
I think you would find you save a lot more performance by custom coding your site every time versus relying on a framework.
Every environment is different.
Given the size of our site, the large number of contributors, the number of updates per day, the size and wide range of skill of our development team, the fast turnaround required and the variety of platforms and browsers we have to support, a framework makes sense for us.
That said, we do everything we can to mitigate the overhead.
I agree with the first commenter. Performance awareness starts with the business, then comes visual design, and only then comes the developer. Assuming a best case scenario where the developer is performance-minded, he/she still faces an uphill battle in fighting business and design decisions.
Actually, awareness isn’t enough. Making decisions and acting in the interest of performance is what is needed, and this is very hard to accomplish at all such levels. Even in the face of rational data and a business case, it is a hard thing to do.
Boosting web performance has been a pretty exciting thing for me over the last few months. I used to think that using gzip for css, javascript and html was enough. Which it was for the smaller scale sites I maintained in my last job.
Now that I’m working for just the one company I’ve been able to spend time to speed our website up by adding more advanced features including custom caching of various site features, pre-loading pages when applicable and generally reducing the number of elements served where possible.
I’ve been using gtmetrix.com for confirmation that our load times have been dropping as well as some home-made RUM, because, y’know, using other servers, that’s another DNS lookup a nd another .1-.3seconds of load time ;P
It’s changed how I write my code and integrate external APIs also. By employing a cache where I can policy I’ve been able to reduce the number of round trips and elements loaded per page, also, if heaven forbid, an external service drops out, we still have a data cache which we can serve up quickly.