Google

Mike Belshe (Twist): “Time is fixed. It’s precious. We all wish we had more of it.” [PODCAST]

22 Mar 2013

2 Comments

I’m always being asked why I got into the web performance business. My standard response is that I got here via the content management systems I used to develop many years ago. We saw that there was a business problem, in that the companies that bought our CMS would then ask us if we could do anything to speed up page rendering, and so we started down the performance path.

But really, I got into this business for the same reason that many people — including you, perhaps — did: because I consider time the most valuable thing we have.

It sounds trite, but so do a lot of true things. As my most recent podcast guest, Mike Belshe, says, “Time is fixed. It’s precious. We all wish we had more of it.”

This attitude is what prompted Mike to create Google’s groundbreaking SPDY protocol, which has the potential to fulfil Google’s stated mandate: make the web universally faster.

And even though Mike left Google a year and a half ago, this attitude remains a driver behind his latest experiment, Twist — an online service that could radically reduce the amount of time you waste waiting for your chronically late friends to show up (or a myriad of other waiting-game scenarios). I’ve tried it, and it actually is kind of miraculous how well it works.

In this podcast, Mike and I had a far-reaching discussion about time, SPDY, Twist, mobile, native apps, and HTML5 versus Java. I enjoyed it immensely. I hope you do, too.

Listen to the podcast: Mike Belshe

Related posts:

By: Tammy Everts Category: Tags: , , ,

Joshua Marantz (Google): Why erring on the conservative side is a good thing [PODCAST]

28 Feb 2013

0 Comment

One of the greatest perks of my job is that I get to talk to geniuses on a daily basis. I was extremely privileged to be able to chat recently with yet another genius: Joshua Marantz, leader of mod_pagespeed at Google.

We covered a lot of ground, from philosophical to pragmatic topics. You’re going to enjoy this podcast if you’ve ever wondered:

  • What the heck is the difference between PageSpeed and mod_pagespeed?
  • Where does front-end optimization belong in order to deliver the best possible results: near the edge, near the server, or some point in between?
  • Will FEO someday be completely taken care of at the browser and server level?

We also talked quite a bit about images, which has been a recurring theme here lately. While Josh and I agree that what’s unambiguously good for the speed of a page is aggressive lossless image compression, he explains why that feature is not turned on by default in mod_pagespeed (though he says that he always tells people that it’s the first feature they should try to turn on).

Enjoy. And as always, if you have any questions, feedback, or suggestions for future guests or topics, drop me a line at joshua[[at]]webperformancetoday[[dot]]com.

Listen to the podcast: Joshua Marantz

Related posts:

By: Tammy Everts Category: Tags: , , , , ,

Are we optimizing our images like cavemen?

20 Feb 2013

15 Comments

Years from now, developers will look back on how we use images today and have a good laugh at our expense. How we handle images now is the equivalent of caveman drilling holes in skulls to release demons.

The problem: Images are getting fatter, which is hurting performance.

The web is obese. This isn’t news. Images are the biggest culprit. This isn’t news, either. Pages are, by many accounts, getting slower. Again, not news.

According to the HTTP Archive, the average web page is 1292 KB, with 801 KB of that page weight — more than 60% — being taken up by images. The proliferation of images on the web isn’t going to change and will likely continue to increase. People like high-quality pictures, and that’s not going to change, either, especially in light of the advent of retina displays.

The solution: We need to get a lot smarter about how we treat images online.

There are some obvious things you should be doing to optimize images — choose the right format, make sure they’re progressive — but in my opinion, these are primitive first-gen approaches. Today, inspired by my recent podcast chat with Ilya Grigorik, I want to explore some big-picture ideas. (No pun intended… okay, pun sort of intended.) I chatted with some of the great minds here at Strangeloop, notably Shawn Bissell, one of our senior software architects.

We might not have all the answers, but let’s start by asking the right questions.

Why not just automate how images are formatted, so that they’re always in the optimal format?

Inappropriate image formatting is a common performance culprit. We see this literally all the time. You could spend a lot of time educating every single person in your company about the best way to optimize every image type, or you could do what Ilya proposes: somehow automate how images are formatted, so that they’re always saved in the optimal format (PNG, GIF, JPEG, etc.).

At Strangeloop, we’ve built this feature into our products with a treatment called Image Compression. We recompress the image into either a JPEG and a PNG based on a set of default settings (which are user-configurable, as well as automatic), and then we use the smallest version. The smallest version is almost always a JPEG, except for small PNGs or GIFs, which are usually smaller in PNG-8 format.

There are also a bunch of tools — several of which are reviewed in this roundup on Smashing Magazine — that you can use to optimize your image formats.

The challenge, of course, is that the definition of “optimal” is, of course, highly subjective. Using a quality setting that is too low can produce artifacts (blurriness or “jaggies”). Shawn tells me that he recently discovered a cool new algorithm for determining the structural similarity (SSIM) index, which mathematically computes the difference between the original and compressed images. This is something we are currently considering adding to our products.

If we could add/popularize more image formats, what should they be?

What we’re currently using:

  • Photos – JPEG, PNG-24
  • Low complexity (few colors) – GIF, PNG-8
  • Low complexity with transparency – GIF, PNG-8
  • High complexity with transparency – PNG-24
  • Line art – SVG

What we should also be using, but aren’t:

  • JPEG 2000 – This is a great format for variable compression for different regions of interest
  • WebP – Offers better compression for high-resolution images

What we need to develop:

  • A format similar to WebP that can produce even smaller image sizes for images with a extremely high PPI (pixels per inch). This would help a lot with the huge image quality/performance challenges that we’re going to start hearing a lot more about now that the new retina displays are hitting the market.

Why is it so hard to add brand-new, better image formats?

This is a big, hairy, complicated beast. People have been working to improve image formats for years, with mixed success. One of the problems with new formats is that they’re often proprietary and require a license. Another is that they’re sometimes subject to legal issues because of unclear intellectual property rights. Browser vendors understandably don’t want to pay for the license or get caught in a legal battle.

JPEF 2000 and WebP, which I mentioned above, are classic examples of useful-yet-neglected formats:

JPEG 2000 (introduced in the year 2000) is a good example of a format that is actually superior to JPEG. Compared with the regular JPEG format, JPEG 2000 offers advantages such as support for higher bit depths, more advanced compression, and a lossless compression option.The problem: nobody uses it. This is at least partially due to the fact that, while the JPEG 2000 license is royalty free, there may be “submarine patents” on the actual IP, which are problematic.

By the somewhat opposite token, WebP (introduced in 2010) is an open standard that gets great results (according to Google, WebP can reduce filesizes by up to 45%, which is phenomenal), yet it’s still only supported by Chrome and Opera — no doubt due to the fact that it was developed by Google.

The lesson to be learned here is that if you want to create the next great image format, you need to make it free, open, and totally vendor neutral.

Why is the HTTP Vary header a problem for CDNs?

Ilya and I touched on this very briefly in our chat, and a few people have since asked me to explain this further, so I want to take a minute to elaborate here. The Vary header is a problem for CDNs or caching proxies because they are required to keep a different version of the resource for each different value of the header specified in the Vary header.

The classic usage of the Vary header is to vary by Accept-Encoding so that the CDN would keep different copies of the webpage in its cache for different compression encodings (gzip, deflate, plain). This case isn’t a problem, but in order to serve a different image to different browsers, the Vary header needs to vary based on something browser specific. “Browser specific” usually means varying by the User-Agent header, but there are so many different versions of User-Agent headers (even for the same browser!) that CDNs are afraid that varying by User-Agent will cause severe cache fragmentation. So they only like varying by Accept-Encoding, and not by anything else. And some CDNs have even done away with that by implementing their own compression engines.

(At Strangeloop, we avoid this problem by having our product use the User-Agent header on the HTML request — typically not cached in the CDN — to rewrite all the URLs to the images to point at different versions of the images. This way the CDN cache only has one copy per version (which is optimal), and the correct version is controlled by the URL in the HTML, so the browser always downloads this correct version.)

Takeaways

This post just grazes the surface of this topic. How we handle images on the web is a massive, complex issue, but our main challenges can be pared down to this:

  1. We need to get a lot smarter about how we handle images on the web, because they’re only going to keep getting fatter.
  2. We need to embrace existing formats, such as WebP, that will make our images leaner.
  3. We need to develop a new format that can handle the emerging demands of retina displays.

Related posts:

By: Tammy Everts Category: Tags: ,

Ilya Grigorik (Google): When it comes to tackling web performance, we all still have a lot to learn [PODCAST]

24 Jan 2013

0 Comment

It doesn’t matter what area of web performance you specialize in, if you’re anywhere in the performance space, this week’s podcast has something for you:

  • social analytics
  • RUM
  • SPDY
  • HTTP 2.0
  • CDNs
  • mobile performance
  • scuttlebutt about sharing an office with Steve Souders

The guy who’s delivering the goods on all these facets of performance is Ilya Grigorik, one of the smartest people I’ve ever talked to, inside or outside our industry. Ilya has a fascinating breadth of experience. He’s deep in the weeds on a few sides of the performance equation: from protocols to analytics to how pages are actually put together. As developer advocate at Google, he’s not only chin deep in Google Analytics and SPDY, but also walking the DOM and fiddling with CSS. And he gets to share an office with Steve, which you’ll hear me grill him mercilessly about. :)

What makes talking with Ilya really refreshing is that he doesn’t just have a lot to share about what he knows — he’s also really candid about what we don’t know and what we could be doing better. And he’s remarkably upbeat about the Sisyphean task of making the entire web faster. Enjoy.

Listen to the podcast: Ilya Grigorik

Related posts:

By: Tammy Everts Category: Tags: , , , , , ,

2013 predictions: The average web page will hit 2MB, Android will pull ahead of iOS for good, and your smartphone will get infected with a virus

11 Dec 2012

6 Comments

It wouldn’t be December without a batch of audacious predictions for the new year. Assuming we all survive past December 21st, here’s what I think 2013 will hold for site owners, mobile users, CIOs/CTOs, RUM vendors, and the browser wars.

1. The average web page is going to hit 2MB.

A year ago, I predicted that the average web page would hit 1MB in 2012, which it did in May. Today, the average page is 1280KB. In a post I wrote last month, I predicted that, at the current rate of growth, typical page size would hit 2MB in early 2014. I’m upgrading that prediction to the end of 2013. Call it a hunch. This has massive implications for site owners in terms of bandwidth, but mobile users will be hardest hit, from both a usability perspective and a throttling/data cap perspective.

2. By the end of 2013, at least half of all North Americans will own a tablet.

Currently, 29% of North Americans own some kind of tablet. With the proliferation of new inexpensive tablets, with the emergence of kids as a mostly untapped tablet market, and with Christmas just around the corner, I’m predicting that more than 50% of North Americans will own a tablet by year end.

3. Global mobile traffic will hit 25% of total internet traffic.

Right now this number is 13%, but numbers are surging in China and India.

4. 25% of online shopping will be via mobile.

With the explosive adoption of tablets, we’re going to see a major jump in mobile shopping. Mobile phones and tablets represented 24% of online shopping on Black Friday, up from 6% just two years ago. We’re going to see that Black Friday stat become the norm.

5. 2013 will be the year your smartphone gets infected with a virus.

You know it’s coming. Cue the dark lords of anti-virus software to the rescue.

6. Android will pull ahead of iOS smartphone adoption. For good.

In five years, we’re all going to look back on 2013 as the year Android pulled ahead for good on smart phones. When it comes to this kind of call, I use the Strangeloop team as the canary in the coal mine. My dev team is moving to Android en masse. I haven’t seen this type of shift since 2009 when the mass exodus from Blackberry began.

7. Mobile performance will continue to be a major problem.

Mobile sites will remain too slow. Too many people still believe that their simplified mobile site is the answer (which it’s not, because it’s often too simple), or that responsive web design is the answer (which it’s not, because RWD pages can actually be even bigger and slower than a typical page). There’s no single magic bullet for mobile performance. Companies are going to have to really apply themselves to finding solutions that work for their unique situations.

8. This will be a great year for Chrome, an okay year for Internet Explorer, and a bad year for Firefox.

Internet Explorer will halt the bleeding and stabilize, but not grow, its market share. Chrome will hit 45% of worldwide browser market share by the end of the year — almost entirely at the expense of Firefox.

9. Two of the four largest CDNs will be acquired and integrated into larger companies.

I’m not naming names, and I have no inside information. This is just my hunch that we’re going to see big changes in this market.

10. Netflix will continue its decline, while Amazon video delivery will ascend.

Amazon’s rise in video delivery to the home will become evident in 2013. Amazon can outspend almost anyone for content — and when it comes to video, content trumps all.

11. DDOS attack mitigation will dominate the enterprise.

There’s nothing CIOs/CTOs hate more than visible failure. Sixty-five percent of the top ecommerce sites will have a mitigation strategy in place by the end of 2013.

12. RUM vendors will finally start to make money.

Real user monitoring will move from the sideshow to the main stage for half of analytics vendors. We’ll even see the first example of actionable RUM, which operations can use to trigger alarms that matter. Operations will start to trust RUM. By year end, RUM will be found on 35% of ecommerce sites.

Related posts:

By: Tammy Everts Category: Tags: , , , , , , , , , , , , ,
1 2 3 4 5 6 7 8 »