Mobile

2017: Boost Firefox Mobile Browsers

by  on  in Browser, Mobile, Performance

As a product manager for mobile browsers, besides being the voice of the users, it’s my ultimate mission to look ahead, collect, detect and predict mobile trends, and validate them as they fit with our users and markets. Finally, as a team, we decide what our team should focus on.

The beginning of a new year always seems to be a good time to reset, reflect, and set goals for the brand new year to come.

Mobile web is an exciting space to be in, even more so now, because last year marked an important milestone; for the first time, StatsCounter reported more people are browsing the web on their mobile devices as opposed to their desktop computers.

This write-up covers some of my reflections and aspirations to build a strong and useful Firefox browser on mobile.

Web Compatibility and Video

If a website doesn’t render content properly, the user is frustrated and will probably switch to a different browser. That, of course, applies to video as well.

“By 2020 over 75% of global mobile data traffic will be video content.”

My goal for 2017 is to make sure every video on the mobile web works on every Firefox Mobile browser. Mozilla’s platform & web compat team will be eager to help us get there. If you see a video not working on your mobile Firefox browser, let us know.

Most cat videos live on the web, and not in apps.

“Mobile web is a mile wide and an inch deep, the app is a mile deep and an inch wide.”

One of the biggest advantages of the (mobile) web is that the user doesn’t need to install an app to get their content or particular service they require. No need to sacrifice more storage on your device for yet another app that isn’t used very often. We can make use of one of the fine advantages of the web; discoverability. We have the entire web at our disposal to help users pioneer new media content.

Some questions I’d like to discuss with our UR & UX team:

👋 Welcome New Users in Emerging Markets

I’m not the first one to tell you this; anybody who has an interest in the mobile space knows by now to pay attention to India’s massive mobile growth in 2017 and the years to follow.

“In order to create value in India in the coming decade, companies must have a mobile-first strategy”.

What does that mean for us? Although our data shows that more people in India use an English version of our browser app, a lot of people in India consume mobile web content in Hindi (5x more). Can we localize and customize our app (even more) to accommodate non-English users?

How diverse are our users within different markets and cultures? Do they use features differently and how? For example, we’ve noticed that people in India (and Indonesia) save significantly more media content from the web to their device than in the US (almost double). Let’s investigate and help our users, no matter where they are, by finding solutions to their specific problem and needs.

India already surpassed the US smartphone market, and there will be an additional 330 million unique subscribers in India by 2020.

How can we best welcome these new smartphone users to the world of mobile browsing? Can we learn from their inexperienced and brand-new encounter with the web? What are the things that work well or don’t work at all for them? It’s a fresh new chance for us to give these 330 million new users a safe home and entry point to a safe web.

Partnerships, Cross-App Usage & Diversification

I strongly hold the belief that we should not force users to stay in our apps, rather come back more frequently; we need to foster cross-app usage, well, we actually must encourage cross-app usage. Especially on iOs where there is no concept of intents nor users are able to decide themselves their preferred default apps, we need to strengthen our partnership with other apps by forming an alliance to let users decide (rather than the OS to dictate) what apps they prefer to default to.

Stay tuned for our upcoming Firefox iOS update that will be the start of a series of cross-app pollination efforts to help with mentioned issue above.

My personal goal is to establish more cross-app partnerships this year.

Check out our “Open in Firefox” SDK for iOS if you are interested in giving users a choice when opening web content from within your iOS app.

This year will also be a year for our mobile team to experiment with single purpose apps (e.g. Focus – simple private browser), and validate if diversifying our mobile presence into multiple apps will reveal to be a successful move.

I can’t wait to experiment with some of the great ideas the team has in mind.

Artificial Intelligence

There will soon be no more mobile app, nor browser that doesn’t include some sort of AI or machine learning nuances. My colleagues from the Context Graph team currently optimize and experiment with the concept of a recommendation engine for our users. Stay tuned for more to come this year, carried out in products like Activity Stream for our mobile browsers.

Support for Diverse Input Formats

Personal home assistants like Google Home and Alexa are being operated primarily by our voices to perform tasks.

I’d like to explore and think more about voice as another input format to browse the web, be it via mentioned home assistants or be it via (other) apps on the mobile device.

And let’s not forget about the 2-in-1 devices. As a core mobile product manager, I want to make sure that our users, on these devices, can easily switch between touch, mouse or other input formats to consume any web content they want.

(Mobile) Web Performance

There can’t be a post of mine without mentioning mobile web performance.

First off, I’m so excited about Mozilla’s Quantum project. The team has already committed to deliver a fast web engine by end of 2017. In addition, our team in Taipei is knee deep in building HASAL, a framework for testing web performance between different browsers.

As for the user-facing part, we will continue to include features that will help our users browse the web faster. Obstacles such as slow loading ads, data usage and bandwidth constraints (especially in emerging markets) force us to find solutions for our users.

I want to continue to fight for fast(er) mobile websites and give users choices to understand performance and bandwidth impacts (list of mobile data related bugs)

This was a (small) selection of topics the core mobile browser team at Mozilla will work on in 2017 and the years to come.

Happy New Year, everyone! It’s going to be yet another exciting one.

Advocacy for a Faster Web: A Setting in Your Browser

by  on  in Browser, Mobile, Performance

I’ve talked about Third Party Footprint and Web Performance many times to help designers, developers and publishers understand the importance of web performance.

Now, I’m excited to share with you a solution that I hope, will encourage third party providers to fix their performance issues by sending another strong signal, this time by the actual consumers of tracking providers; the website visitors themselves.

As part of my mission as Fennec’s Product Manager, I don’t only want the web and the browser app to win but also want to provide choices for users to experience their journey online, every day to accomplish their tasks, always (a little) faster.

Mozilla wants to give control back to the user, and help users understand why we’ve added an important feature in our 42 release (Desktop and Android): Tracking Protection in Private Browsing.

Besides the privacy spin and the main reason for this feature to not let advertisers track you without your knowledge, there is one other important side effect that this feature brings with it; Improved performance by disabling third party scripts on the pages you visit.

Not only will it lead to faster loading pages, it will also help users save battery life and data. This is especially important in countries such as India, or countries like China where one of the top reasons users pick their browsers is based on offered data saving features. Chrome and Opera on Android have both explored this idea already as well.

In addition to protecting users’ privacy, I hope by providing users the choice to browse the web without third party scripts, we can send out a message to tracking providers in order to improve the performance of their service.  Don’t get me wrong, I don’t want people to lose their advertising jobs, rather do I see it as another layer of advocacy and strong(er) messaging going out to providers that not only publishers and their developers care about (mobile) performance but also users can now show their opinion by concrete actions. Who knows, it might even encourage publishers to think outside the box and provide their own solutions.

Screen Shot 2016-01-07 at 7.37.05 AMIt’s not new that users don’t like ads, the most popular add-ons on Android Firefox are Ad Blockers.

However, not everyone knows, feels comfortable or wants to install Add-Ons or additional Ad blocker apps. We can’t make it difficult for users to take back control, and offer them speedy web experiences.

Allowing users to disable third party trackers directly from within the browser app, seems convenient for the user, and just makes sense (to me).

Performance Test

Let’s see how turning tracking protection (in private browsing) benefits the user beyond protecting their privacy. The following test shows how much data and HTTP requests can be avoided by turning on Tracking Protection.

Test Scenario

I’ve tested it myself with remote debugging on several websites (e.g. people.com, espn.go.com etc.). I connected my Android device with my laptop and used a real LTE connection (tethered with my other phone) to reproduce real mobile speed.

I tried out 2 scenarios on people.com, and collected remote debugger information, and stored them in HAR files (a convenient file format to analyze for performance).

  1. Private browsing mode with Tracking Protection enabled
  2. Private browsing mode with Tracking Protection disabled

The two graphs below, created by http://onlinecurl.com/har-diff, show how the two different modes loaded people.com. The bars on the left are shorter, indicating that the page could be loaded faster. The bars on the right, without tracking protection enabled, show longer bars which represent longer loading times.

Screen Shot 2016-01-07 at 8.09.08 AM

Left: Tracking protection enabled. Right: Tracking protection disabled

Screen Shot 2016-01-07 at 8.09.50 AM

Results

Test Private Browsing Private Browsing
with Tracking
Protection		 %
Data 2.1MB 1.4MB 33
HTTP Requests 182 69 62

The actual HAR files can be found here.

Both metrics (data and HTTP requests) show clear differences between tracking protection enabled and disabled, hinting to an improved user experience for people.com with tracking protection enabled.

Try it out yourself. Download the latest Firefox Android app on your phone, open a private browsing tab, tracking protection is enabled by default in private browsing mode. No extra setup required.

Screen Shot 2016-01-08 at 8.01.16 AM

 

Tracking Protection outside of Private Browsing (Experimental)

We are currently experimenting with options to enable tracking protection in normal mode.

I encourage everyone to try it out, share their opinion, and even experimentally enjoy this feature even when browsing in non-private mode (download Nightly).

Screen Shot 2016-01-08 at 8.04.31 AM

To a healthier and faster web, everyone.

Disclaimer

  • It is to note that by removing parts of the website when enabling tracking protection, some websites might break.
  • The article describes my personal opinion.

 

Avoiding Temptations that Harm Website Performance

by  on  in Learning, Mobile, Performance

The following post is a cross-post to Sitepoint’s blog to promote my book Lean Websites.

Web performance matters. Studies have shown that improvements in website performance—such as page load times—can dramatically increase user engagement and profits.

However, life’s short, and time is money. As web developers, we’re paid to get the job done—by clients, bosses and colleagues who may not appreciate the importance of site performance. So the temptation is to cut corners to get the job done—to find the quickest solution, without regard for performance. In these times of rising mobile usage and search engine preference for lean websites, average page weights continue to soar. It’s not a good situation.

Temptation: the pressure to give in to a desire for easy or immediate pleasure

The consequences of giving in to temptation are often not felt until afterwards.

This article describes some of the temptations you’ve probably faced in your web development journey, and why it’s better not to give in to them.

Using Ready-made Scripts

It’s a typical scenario: you need to add something to a web page—such as a slideshow. So you google “web slideshow” and get hundreds of results. There are so many to choose from, all ready to go, and free. Why not just use one as is, save time, and get paid? Doesn’t everyone else?

We often forget to consider the performance of the scripts we choose. Is the code well written? Is it optimized? Do we need all the functionality it contains?

In Chapter 4 of Lean Websites, I examine how to differentiate between copy and paste and copy and waste.

Pretty Images and Designs

A picture is worth a thousands words; and when it comes to web performance, a picture might be worth more that a thousand lines of code in terms of page weight! Poorly optimized images are by far the the biggest cause of bloated websites.

There are some image considerations that can make a huge difference to web page performance.

Not Every Device Needs a High Resolution

There’s no need to show everybody the high resolution version of the image if not needed. Be context sensitive, considerate and respectful. Don’t fill your page with unnecessary heavy assets like images just because you don’t know what else to put there. Trust me, none of your users on their mobile device while roaming wants to download a 2MB retina image.

Images Cost Bandwidth

Images remain the biggest performance culprits. They currently take up most of the file sizes and usage on the internet, as shown in the chart below:

Bandwidth usage of various content typesBandwidth usage of various content types

The temptation web developers face, especially when working under a lot of time pressure, is to just plug in big images, without considering whether to convert them into a more efficient image dimension or format.

In my book Lean Websites, I look in depth at ways to optimize your images and other site assets to ensure that your site is as performant as possible—especially on devices connected to mobile networks.

Performance Optimization as a Part of Development

When time is money, there’s always a temptation to cut corners. One way to cut corners is to put things off and never end up doing them. Performance testing and optimizing are critical, but it’s tempting to put them off till later and then forget all about them.

Performance optimization is often not mentioned as part of the common software development life cycle at all. But as Ilya Grigorik says, “performance is a feature“, and shouldn’t be relegated to an afterthought.

Lean Websites discusses how you can automate optimization, and make it part of your deployment process, with some easy-to-use and free tools.

Libraries and Frameworks

Christian Heilmann, a web evangelist at Microsoft, calls it “death by a thousand plugins“. It’s so easy to attempt to use modern web development trends by including yet another plugin or library. We sometimes forget that anything you put on your page will cost you and your visitor when it comes to performance. Don’t let too many plugins bloat your website. Heilmann also encourages us to remember that “it is not about what you can add—it is about what we can’t take away”. Something to remember next time when you want to paste another plugin into your site.

Libraries like jQuery, Dojo, and YUI are popular tools that help developers kick-start JavaScript projects, making access to JavaScript objects and methods faster and easier. They simplify the coding experience—but at what cost?

Big Query queryMost popular libraries

The file size of these libraries may vary a lot, especially if they are not minified, gzipped and compressed. jQuery minified and compressed is almost eight times smaller than sending it over the wire without optimization (252 KB uncompressed, 32 KB minified and gzipped).

It’s important to decide what framework or library to use early on in a project. It normally doesn’t make sense to use more than one library or more than one MVC JavaScript framework with a project, as different libraries tend to achieve the same goal. And of course, a library should only be loaded once, though it’s not uncommon to see multiple instances of jQuery on a single page:

Website Count Different jQuery version loaded
www.reddit.com 2 1.7.2,1.7.1
www.washingtontimes.com 2 1.4.2,1.4.4
www.tudoseo.com 10 1.6.2,1.7.2,1.7.1,1.6.4,1.8.2,
1.4.2,1.10.1,1.4.4,1.9.0,1.8.3

Duplicate loading of jQuery, source: example Google Big Query on HTTP Archive for the month of July 2014

Why would you want to load more than one version of jQuery? Isn’t this screaming for a good clean-up? There is definitely some legacy code in there that might require an older version of jQuery. Hence, the temptation is pretty big to just add a new version in addition to use newer functionality in jQuery. That seems like a lot of maintenance and legacy trouble. Instead, take some time, go through the functionality of your site and determine which version to convert to.

While sometimes there might be a good reason to include several JavaScript frameworks, there could also be other reasons that should be verified. The overlapping and duplication of plugins can stem from different reasons:

  • The team building the site didn’t agree on a common framework or library to use.
  • Tangled code that developers have to work with. Sometimes they are only being provided with isolated include files, with very little visibility to the parent code. They could be tempted to just plug in their preferred library and version if needed, to continue their work.
  • Missing enforcement techniques.
  • Carelessness or laziness of developers.
  • Use of other web components including the same frameworks.

Lean Websites looks in detail at the consequences of using libraries and frameworks, and how to make the best use of them without negatively impacting on site performance.

Social Media, Ads and Tracking

If you work for a company with a business intelligence, analytics or marketing department, the chances are high that you are being asked to include anything that could help measure the company’s success.

Social media, ads and tracking scripts are big temptations for marketers and companies to better understand their customers and to add or find other revenue streams, such as selling ads. But any foreign content you add on top of your own content—especially if it’s JavaScript-based—will add weight and load time to your page.

There’s not one social media or tracking tool out there that marketing wouldn’t like to try out.

Lean Websites looks in detail at how to properly and securely include third-party scripts and plugins.

A handy rule of thumb is that the value you get from using a third party script has to be greater than its performance hit.

Conclusion

Performance optimization is often an exercise in compromise, and there are always competing interests to be considered.

This article has raised just a few of the issues involved in site optimization—a topic that is finally coming of age in a big way.

Lean Websites provides a detailed, in-depth overview of the many factors involved in creating efficient, performant websites—from understanding user experience and expectations to monitoring performance, automating tasks, and optimizing server requests, site assets, and the networks our sites run on.

Hopefully this this brief introduction has whetted your appetite to find out more! I’d love to field any questions or comments you may have.

Good-Bye OANDA / Hello Mozilla!

by  on  in About me, Learning, Mobile, Toronto

I gave notice last week.

This was the hardest resignation day I’ve ever had to go through. Not only because I noticed that people care about me and my work but more importantly to leave something so great behind.

I truly enjoyed working with, and learning from my amazing manager about product management, leadership, respect, opportunities, metrics, strategy and customers.

He defined product management as 3 main parts: customer, data, strategy.
I’ve always found those such great pillars to follow, and core ideas on how to tackle product management.


First product launch: OANDA API with API cupcakes!

But that’s not all. I’ve never worked at a company where leadership and management were so approachable, caring and listening. I already miss all the great conversations and insights I got from my manager, the CTO and CEO, well basically anybody there. I will forever cherish this, and do not ever want to cut my connections to them – Graeme and Ed, you promised me coffee time! I never had the feeling that anybody’s opinion is not valued or not considered, I never had to deal with any egos or had the feeling I couldn’t tell anyone (especially in senior management) if I felt their idea was not something we should pursue.

It’s actually pretty easy, everybody wants to be happy and productive at work, and the best way to achieve that is to work and have fun, together.

I’ve learned what constructive criticism, respect and loyalty mean. I’ve learned to build and form an opinion at work, discuss, feel different and be proud of it, and more importantly stand behind it, something that has not always been easy for me in the past.

I’ve learned so much here. This place is encouraging and positive and that’s what has always kept me there.

Thank you OANDA.

<obvious-shout-out>If you ever get a chance to work for OANDA, go for it, and apply, it’s a great bunch of people.</obvious-shout-out>

And, although I didn’t plan to move on so quickly after my enjoyable and productive 1 1/2 years at OANDA, there is a reason why I had to do it. It’s about growing and taking opportunities, and sometimes they come faster than you had planned.

Throughout my entire life, the web and its openness have always been a passion of mine. I’ve always been fascinated by the web and its possibilities; I’ve built many websites, have cursed about browser compatibilities so many times, built mobile websites for the CBC, lead a mobile/hybrid web app project at the CBC, have hosted many webperf meetups, haven spoken at conferences about the web, and last but not least I’ve written a book about web performance.

This is not to brag about my stuff, it’s more to explain my passion, and by now, I assume you’ve noticed a pattern: I believe in the (mobile) web and I am so passionate about it.

So, in a couple of weeks, I will start as a senior product manager at Mozilla. I can’t wait to bring Firefox on all mobile devices. I’m so thankful and grateful that I can finally put all my passion for the (mobile) web into an organization that truly cares for, and believes in the openness of the web.

My first week at work will be in Whistler, BC, where I will meet all my team members, well all Mozillians. After that, I’ll have my desk in the Toronto office.

I can’t wait!

I believe in the web, and I believe in mobile.

Let’s get started.

 

 

Follow-up on my talk “Embracing Performance in Today’s Multi-Platform Macrocosm”

by  on  in Mobile, Performance, Speaking, Talk Follow-ups

Hello everyone, this is a follow-up blog post on my talk presented at BDConf in San Diego and WebExpo in Prague.

If you landed here because you’ve typed in the URL after attending my talk, great! Thanks for making it all the way here. I hope you enjoyed my talk.

If you landed here via Google, Twitter or any other sites, I welcome you too, of course! You might want to first have a look at my slides (see link below) before clicking on any of the other links below.

Either way, feel free to leave a comment or contact me via twitter with my handle @bbinto.

Enjoy!

Slides

Slides available on SlideShare

Links and articles, recommended content

Maven Tools

Continuos Integration Tools (<3)

General Links

Image Credits

The Power of a Private HTTP Archive Instance: Finding a Representative Performance Baseline

by  on  in Mobile, Performance, Speaking

(Note: cross-posted at programming.oreilly.com)

Be honest, have you ever wanted to play Steve Souders for a day and pull some revealing stats or trends about some web sites of your choice? Or maybe dig around the HTTP archive? You can do that and more by setting up your own HTTP Archive.

httparchive.org is a fantastic tool to track, monitor, and review how the web is built. You can dig into trends around page size, page load time, content delivery network (CDN) usage, distribution of different mimetypes, and many other stats. With the integration of WebPagetest, it’s a great tool for synthetic testing as well.

You can download an HTTP Archive MySQL dump (warning: it’s quite large) and the source code from the download page and dissect a snapshot of the data yourself.  Once you’ve set up the database, you can easily query anything you want.

Setup

You need MySQL, PHP, and your own webserver running. As I mentioned above, HTTP Archive relies on WebPagetest—if you choose to run your own private instance of WebPagetest, you won’t have to request an API key. I decided to ask Patrick Meenan for an API key with limited query access. That was sufficient for me at the time. If I ever wanted to use more than 200 page loads per day, I would probably want to set up a private instance of WebPagetest.

To find more details on how to set up an HTTP Archive instance yourself and any further advice, please check out my blog post.

Benefits

Going back to the scenario I described above: the real motivation is that often you don’t want to throw your website(s) in a pile of other websites (e.g. not related to your business) to compare or define trends. Our digital property at the Canadian Broadcasting Corporation’s (CBC) spans over dozens of URLs that have different purposes and audiences. For example, CBC Radio covers most of the Canadian radio landscape, CBC News offers the latest breaking news, CBC Hockey Night in Canada offers great insights on anything related to hockey, and CBC Video is the home for any video available on CBC. It’s valuable for us to not only compare cbc.ca to the top 100K Alexa sites but also to verify stats and data against our own pool of web sites.

In this case, we want to use a set of predefined URLs that we can collect HTTP Archive stats for. Hence a private instance can come in handy—we can run tests every day, or every week, or just every month to gather information about the performance of the sites we’ve selected. From there, it’s easy to not only compare trends from httparchive.org to our own instance as a performance baseline, but also have a great amount of data in our local database to run queries against and to do proper performance monitoring and investigation.

Visualizing Data

The beautiful thing about having your own instance is that you can be your own master of data visualization: you can now create more charts in addition to the ones that came out of the box with the default HTTP Archive setup. And if you don’t like Google chart tools, you may even want to check out D3.js or Highcharts instead.

The image below shows all mime types used by CBC web properties that are captured in our HTTP archive database, using D3.js bubble charts for visualization.

Mime types distribution for CBC web properties using D3.js bubble visualization. The data were taken from the requests table of our private HTTP Archive database.

Mime types distribution for CBC web properties using D3.js bubble visualization. The data were taken from the requests table of our private HTTP Archive database.

Querying the Database

Sometimes, you want to get some questions answered without creating a chart. That’s when you can query the MySQL tables directly. Let’s run a simple query on the requests table.

For example, some of the CBC sites use YUI, some use jQuery—but we would really like to avoid having pages serve both. A simple sample query like the one below could help identify those sites:

SELECT req_referer
FROM requests
WHERE url LIKE "%/jquery_.js%" OR url LIKE "%/i/l/yui/%"
GROUP BY req_referer

And More …

We will share more of the queries and insights we’ve gathered from our HTTP Archive instance that helped us identify bottlenecks. In addition, we will also discuss how this setup came in very handy to discover problems with some unnecessary page weight that we thought we didn’t have.

Join our talk at the Velocity conference in Santa Clara in June titled “The Canadian Public Broadcaster on A Diet: Slimming Down for A Whole Nation.” The talk will not only cover the private HTTP Archive instance but furthermore cover many other aspects of how to focus on (mobile) web fitness and how to “slim down.”

Related Posts to our Talk

Warming up for Velocity 2013 in Santa Clara

by  on  in About me, Mobile, Performance

I have attended several conferences in the last few years. The first one that really changed my “developer life” was the Velocity 2011 conference in Santa Clara. I have always been interested in optimizing and being diligent about the web, however, my learning during those three days in Santa Clara has influenced my every day life and the way I see performance.

I truly admire each and every speaker and attendee at the conference because they all share the same passion: Optimizing the web and making performance count. I am honoured to announce that it is my turn this year to give back to that same community of people and share what I have learned over the last few years and what I have been applying at Canada’s public broadcaster, the CBC.

Our talk “The Canadian Public Broadcaster On A Diet: Slimming Down For A Whole Nation“ will focus on (mobile) web fitness and how to “slim down”. Tips and tricks will be shared about how to stay in shape when developing (mobile) sites for millions of people.

My talented co-worker Blake and I will be talking about how we apply performance optimization at the CBC, one of Canada’s largest web properties with over 5 million pages. As a publicly funded organization, all Canadian eyes are on us making sure we stay on budget and deliver quality and optimized content to users.

While Blake will be talking more about the backend, server and CDN aspects of performance optimization and tips, I will be sharing information about how we optimize and tweak performance from a frontend development and automated deployment perspective, basically – how to get and stay in shape.

Don’t worry; this definitely will not be your typical boring and horrifying boot-camp experience! Our talk will utilize fun and catchy analogies to explain the weight and performance of pages. I will be your honest CBC “fitness trainer”, telling the audience about the page weight of our sites on multiple platforms, how we measure performance and set budgets. However, putting our content on a scale will tell the truth: a content breakdown of our pages will help the audience understand how content is structured and where we can “slim down”, but also where a fitness routine cannot help.

Keep us company while we share some insights about setting up our own HTTP Archive instance as a tool – or how I would describe it: the BMI of web sites – to compare our own weight to the public HTTP Archive instance. We will share some queries from our HTTP Archive database to help identify bottlenecks, and we will tell you about how we discovered problems with some unnecessary weight that we thought we didn’t have.

Additionally, sweet and dangerous temptations will be placed in front of your eyes, the kinds that we all have to deal with when creating high traffic sites, including, 3rd party scripts that could significantly harm the performance of our sites when not properly implemented. We compare client-side versus server-side 3rd party implementation. We will also reveal the amount of improvement we saw in load time once we turned off all ads on our mobile touch site for a weekend.

During our talk, you will also hear about our fitness stack regarding how we monitor our fitness level, and why it is so important to stay on a strict exercise schedule and avoid gaining too much unwanted weight, which can happen without even knowing it. If you want to exercise and stay in shape, there are tons of great tools out there to help you achieve that. We will cover how we organize and optimize our sites, our releases and deployment and how easily you can include tools in your deployment process to automate performance optimization.

If you want to know how we use RUM in combination with synthetic testing, and what our RUM numbers reveal, then you shouldn’t miss out on our talk.

Lastly, we will explain the challenges that we have faced, as the national news broadcaster in a world of ever changing news, with the potential for a breaking news story at any moment, that could drive our traffic to the roof, and how we need to respond to that.

Come join our talk and if you like, wear your favorite running shoes because you never know, you might want to start exercising right after.

We look forward to meeting you all!

More details to our scheduled talk and location: http://velocityconf.com/velocity2013/public/schedule/detail/27973

Performance check: CBC’s logo as pure CSS, Data URI and simple PNG on the scale

by  on  in asp.net, Learning, Mobile, Performance

There is always room for improvement. Period.

Think about the 100 meter men’s sprint. I am  amazed how it continues to be possible for human beings to still become faster and improve their performance.

I’m not Usain Bolt – I can’t run 100 meters in 9.58 seconds but I might be able to run (mobile) websites under 10 seconds.

Today, I want to focus on a technique I first heard about at the Velocity Conference in 2011 in Santa Clara and how to compare it with other ways to serve images in HTML pages.

Data URI is based on base64 encoding and basically encodes data (e.g. images) into bites. It can be used to improve performance.

Data URI as “Performance Enhancer”

Instead of requesting for example a PNG image, you could encode it as base64 and serve it inline with your HTML code. That way, you reduce one HTTP request – right there – 200ms saved. Instead putting it inline, you could also put it encoded in an external stylesheet.

Watch out for caching limitations though. Data URIs can’t be cached as they don’t have a standalone cache policy, they are part of the file that includes them. So they can only piggy-bag on other cacheable assets, e.g CSS or HTML files.

As Nicholas explains, if you put data URI images inline with HTML, they can only be cached as part of the HTML cache control header. If the HTML is not cached, the entire content of the HTML markup, including the inline data URI will be re-downloaded every single time. That approach, if the image is big in size, can slow down and weight down your page. Hence, one option is to to put it in stylesheets because they can have an aggressive cache while the HTML page can have no cache or a very limited cache.

Limitations and Browser Support

Think about the browser audience of the site you want to leverage data URIs for. If you target modern browsers, including new mobile devices because that’s where you really want to focus on performance the most, you might be able to ignore the following limitations and accept the little restricted list (thanks to Fire) of supported browsers.

  • Firefox 2+
  • Opera 7.2+ – data URIs must not be longer than 4100 characters
  • Chrome (all versions)
  • Safari (all versions)
  • Internet Explorer 8+ (data URIs must be smaller than 32KB)

Motivation for Comparison

I’ve been reading a lot about web performance techniques and for some reason the data URI practice got stuck with me. I started off by creating the CBC gem (logo) in CSS to verify if CSS performs better than serving images. While I was playing around with that, I thought why not adding another dimension to the test and check the performance of the CBC logo as data URI. Voilà, I had my basic scenario for the test:

Check the performance of the CBC logo as

  1. An image in pure css
  2. A plain PNG image as background image
  3. A data URI (in CSS and inline with HTML)

Setting up the Test

The purpose of the test was to figure out what kind of presentation for the CBC gem would be the fastest and slimmest.

Prerequisites and Conditions

  • All HTML and CSS files were minified and use the same markup (despite the logo in pure CSS which needed to have a few more div classes to render the circles)
  • Each HTML version was tested with empty cache
  • Performance results were performed with WebPagetest (10 runs on an 3G simulated browser) to find the Median.

1. Logo in pure CSS (30px x 30px)

Pure CSS 30x30purecss Screen Shot 2013-05-01 at 5.40.46 PM
Description: Thankfully, the CBC gem consists of circles, 1/2 and 1/4 circles, those shapes can easily be created with CSS. I used this page to help me get started. Instead of setting up a fixed size and color, I decided to use SASS to help me be more flexible with my settings for the logo. The scss file lets me define color and size of the gem.
Note: Maybe the pure CSS logo has a bit of issues with some of the 1/4 circles but that’s probably due to some math formulas I didn’t do right in the SASS, I believe this can be ignored. Hence, This version cannot be used as the official CBC gem.

2. Plain PNG Image (30px x 30px)

PNG Image 30x30
png		 Screen Shot 2013-05-01 at 5.40.59 PM
Description: Simple PNG file  included in the CSS as a background image. CSS included in main HTML.

3. Data URI in CSS (30px x 30px )

30x30 data URI

datauri		 Screen Shot 2013-05-01 at 5.41.04 PM
Description: I used Nicholas’ tool to create my CSS files including data URI. However there are many tools to help you create your own data URI encoded files.

You can see from the browser screenshots above that all logos look pretty much the same to the user.

Test Results

Screen shot 2013-07-23 at 2.33.49 PM

The results show that the median load times serving the logo as pure CSS in comparison to the Data URI solution are being almost the same whereas the logo as a background image in CSS took the longest.

I looked at the base64 string and thought how big it would be if I had used a bigger image. So I googled and found the following “It’s not worth to use data URIs for large images. A large image has a very long data URI string (base64 encoded string) which can increase the size of CSS file.” (source). I decided to test it out myself. So, my next question was “How would the test above turn out if I used a bigger CBC gem logo”. I picked a width and height of 300px. While I was preparing the 300px x 300px pages, I also decided to create another version of the Data URI, not part of the CSS but inline within the HTML.

1. Logo in pure CSS (300px x 300px )

There was not much of a different in terms of markup and setup for the pure CSS and PNG in CSS version. I updated the SASS for the cbcgem.scss to accomodate a logo of 300px x 300px instead of 30px x 30px. The file size didn’t change much because it is all based on math calculations

2. Plain PNG Image (300px x 300px )

Instead of loading gem-30.png, I created a version gem-300.png and updated the CSS.

3a. Data URI in CSS (300px x 300px)

Screen shot 2013-05-01 at 9.09.15 PMI noticed that the size of the Data URI encoding as expected increased dramatically from a 30px x 30px encoded image to a 300px x 300px image (almost 10 times, see full view of screenshot on the left).

3b. Data URI inline within HTML (300px x 300px)

Screen shot 2013-05-01 at 9.31.58 PMInstead of pasting the long base64 string into the CSS, I added it as an img src to the HTML page (see full view of screenshot on the left)

I used WebPagetest again to run 10 tests to find the Median.

Screen shot 2013-07-23 at 2.33.57 PMThe links to the WebPagetest results can be found at the bottom of this post.

Observations & Take-Aways

  • Creating simple shapes in CSS (via SASS) is highly scalable because it doesn’t influence the size of the CSS file significantly. The size of the CSS file won’t change much if I choose to produce a 300px x 300px logo or a 10px x 10px logo. For all tests performed this solution seems to be the most efficient and fastest one.  
  • I didn’t  find the observation true that if the encoded image is bigger than 1-2kB it wouldn’t be worth using Data URI to improve performance. When looking at the last test round (300px x 300px), we can see in the results that the page with the encoded image is still faster than the page with a 300px x 300px PNG image.
  • It is interesting to note that the inline data URI version is faster than the data URI CSS version (and almost as fast as the pure CSS version).  Having to serve 2 HTTP requests with a total size of 4kB, the median load time was faster than the one serving the data URI via CSS.

Further Readings and References

WebPagetest Results

CBC Gem 30px x 30px

CBC Gem 300px x 300px

“One Web” in a Multi-Platform World – Contradiction or Challenge, You Choose!

by  on  in (Web) Design, internet, Mobile, Performance, Web apps

I read “mobile is not different” and I childishly take it personal – Why? – I dig deeper as if I was my own therapist – Why does it affect me the way it does – It feels like hopeful idealism and the need to generalize complicated things. Not a bad idea, but only if I could take that 2MB desktop site and serve it to all mobile users and think they would be happy…my job would be done! It’s not that easy, when developing web sites, you need to overcome many more obstacles for mobile than for desktop sites that are served on a high-speed, crazy powerful CPU device, a.k.a. desktop computer able to present any kind of content (text, image, audio or video). I wish I didn’t have to worry so much about performance, formats or codecs, I wish I didn’t have to think about latency and bandwidth issues, packet loss, data usage or energy consumption when delivering pages to small battery-driven devices, a.k.a. smart phones. I wish the performance budget we manifest for page size and load times would be the same for desktop and mobile, well on “one web”.

I am a big fan of consolidating so if we want to consolidate “everything web” into “one web” let’s consolidate the “proper” way then, make the “desktop” or call it “one” web follow the same strict rules that mobile or any other platform has to follow. Let’s clean up this mess (but my only wish), let’s do it properly this time please….!

What does “one web” mean to us? Deliver content to all devices, make it accessible and working for all platforms – Check, yes!

In order to get there, can we just pick one platform, develop for it and assume all the other ones will just magically start working? – Check? Unfortunately no.

Technically and realistically, I have a problem wrapping my head around this term of “there is only one web”, “mobile is not that different” or “there is no mobile web”. It is though, unless I am misunderstanding what “one” means.

I think we all perceive the notion of “one web” differently, depending on what issues we want to solve and what job title we own at present time. For example, a performance advocate would say “One web – I wish one common web to develop for, no screen real estate issues, load time or page sizes issues when developing for mobile devices! Yah!” But that’s not the case. You have way more flexibility and allowance on browser with an high-speed home internet connection. Let’s continue, if you ask the sponsor of the site or a content strategist, they’d say “yeah, one web, I want e v e r y t h i n g and I want it e v e r y w h e r e” – Is that what people mean by “one web”?

I’m not sure if we can generalize so much. Think about it, how often do we use a 3G connection on our desktop browser? Or for example, data plans for cell phones (in Canada at least) cost a lot, and going over the usage allowance by e.g 100MB costs you way more on your mobile data plan than going over 100MB on your high-speed home internet package. Also, we can’t make use of touch gestures on a desktop computer (yet) the way they come in handy e.g when swiping through photos on a mobile device.

Also, what about context aware strategies and sites. While your big iMac might want to show you all 35000 clothing items served as high-resolution photos, as a data plan payer, I would appreciate if the smart developers would not send those to my mobile device because all I want to do at the bus stop is to see where the nearest stores is and their opening hours.

One web?

Stephanie Rieger has talked about the trouble with context before. And how does “Mobile First” fit in here? Does that mean that Luke wrote a whole book for nothing if mobile is not different or should be a platform to value anymore?

It’s about adaption, no?

Let the experts comment, the W3C Mobile Web Best Practices talk about “one web” as follows:

One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation.

Hands down – I totally agree with that.

I would love to not make an iWatch (?) or iPhone or a SmartTV “different” when it comes to designing and developing web experiences for them but unfortunately they come with different challenges to deliver the same web content. When developing for touch devices you might want to use gestures, maybe you don’t want to load those gestures for your non-touch SmartTV. Your UX might break because your web site design and screen reale state rely on gestures. Your iMac might not need to know where you’re physcially at right now unless you’re taking it with you (it’s so pretty I know) while passing a Starbucks store that has free “grande iced half caf triple mocha latte macchiato” today. Do you think you would want to know about this offer while sitting with a glass of red wine, at night, at home?

May I take a stab at this and rephrase this a bit. There is the web and it is accessible and part of more and more devices (toaster, I look at you, yes I am waitin’ ….), all different in their setups, browsers, their connection limitations, their size, their CPU. Of course you need to adapt and adjust the web to each and every platform because they are different but sometimes also share characteristics. The user experience of viewing a website on a 320px wide screen in contrast to an 50inch screen is different. I believe you still have to meet different requirements at least from a design perspective.

Or even see it the other way around. Value the differences and benefit from them. Mobile devices are smarter than desktop devices. Use their advantages to your own advantages, why wouldn’t you?

I am not saying that anybody I’ve mentioned or cited in this post is wrong, we all have different perspectives and problems to solve. On that note, I’d appreciate constructive criticism because in my opinion, that only shows that we actually end up caring and worrying about the same issue, don’t you think? It’s a good thing.

In an ideal world, the web just works everywhere and serves everything but I fear we are not there yet. We sure can work towards that by creating solid back-end systems with solid and structured content and media sources that each and every platform can pull from whenever and however they want.

It’s not that “mobile is not different”, it is that “platforms are different” or “mobile is just another platform”.

Sources:

  • http://venturebeat.com/2013/03/27/heroku-mobile-lead-mobile-is-not-different/
  • http://www.w3.org/TR/mobile-bp/#OneWeb
  • http://www.the-haystack.com/2011/01/07/there-is-no-mobile-web/
  • http://www.forbes.com/sites/anthonykosner/2012/05/03/seven-deadly-mobile-myths-josh-clark-debunks-the-desktop-paradigm-and-more/
  • http://www.lukew.com/ff/entry.asp?933
  • http://www.lukew.com/ff/entry.asp?1393
  • http://www.slideshare.net/yiibu/the-trouble-with-context

Applying weight loss paradigms to web performance – the page weight points system

by  on  in Mobile, Performance

I like to compare web performance and page weight challenges to real world scenarios. I continue to enjoy John Allspaw and Steve Souders’ performance about a stronger and faster web  at the Velocity Conference 2012. Those things stick, don’t you think? It’s fun to apply web performance considerations to real world weight and fitness rules.

I agree with John & Steve; I strongly feel that there are many similarities that body weight loss and page weight loss have in common. Non-fatty diet complements healthy life. Non-heavy pages complement fast websites and more visitors. Exercising makes people stay healthy and happy. Practicing web performance rules result in faster websites. Keep watching your weight, don’t slip, keep up with the training, and then working out becomes easier with time.

Lately, I’ve been thinking about how to engage people in the organization I work at to get excited about web performance and to make it part of the product development cycle.

Hands down, this is not new stuff that I am proposing here, many smart people in the web performance community have been talking about this for a while. Some great must-read articles below.

All of those articles share the same thought: Come up with concepts and ideas to engage people to buy into web performance.

The idea here is that you make performance part of the process instead of something that may or may not get tacked on at the end. (Tim Kadlec)

You need  to get the people who make the decisions about your products excited about performance and the value of making things fast(er) and perform well. This needs to happen early on in the process. Everybody needs to be on board, including the IAs and designers.

I’ve noticed that if you show people numbers, graphs, % (percentages) and A/B testing results to emphasize on web performance, they start to pay attention and show interest, sometimes they even are so taken away by the results that they share them with other departments and colleagues. That’s what you want, that’s great, however I keep wondering what else they’d like to see to keep them motivated and engaged in the value and importance of web performance.

While Mark talks about “budget” and Christian about the “Vanilla Web Diet“, or tools like YSlow or PageSpeed aim to give marks, I’d like to suggest another possible engaging way to keep performance on a constant radar during product development and not only after (when it’s often too late).

The Weight Watchers Points System

Background

Everybody knows about Weight Watchers, right? This thing seems to work. Ask Jennifer Hudson or ask people you know who’ve tried it. It really seems to work. So, why is that?

  • You don’t have to starve yourself while dieting
  • Social support & support groups help you to not give up
  • The points system: Calculated based on body size, activity level and desired weight loss, you are assigned a certain number of points for each day, e.g vegetables and fruits tend to have few or no points whereas – you guess – sweets, bread and potatoes are higher points assigned to.

Page Weight Points System

How about we promote a page weight points system to the team we work with (and the client who asks for a “heavy” product) to emphasize the necessity of web performance. Wouldn’t it be fun if you came up with a points system for elements on a page or within an app that outlines what and how they impact performance. Each of those elements can then be assessed if they are needed and if so could also undergo a diet if needed.

The points system could help to make performance more tangible.

May I present a rather light (and not so serious) analogy on how you could get started with assigning points to the elements of your product.

  • Ads: That in my world could be compared to that chocolate cake that only tricks you and teases you, takes away needed space but doesn’t really make you look better but brings in money.
  • Tracking: It’s like essential oils and fats that one needs to continue the business in order to grow and make decisions.
  • Social plugins: That could be the beer or cocktail you’d want to drink at the bar so you feel more comfortable chatting up that cute girl next to you.
  • Images: Depending on the purpose of the page/app, images could be beneficial or even required to engage visitors to your product , so you could compare it with Vitamine C from an orange, for example.
  • Text: Text is very light but is needed to represent the product, that could be compared to water. I doubt the points for that would be high.

Once broken down in elements, you could now assign points to them.

The points system could be accompanied by blacklisted temptations that stakeholders might want to throw in the product.

If you were to decide to introduce a points system like Weight Watchers does, please remember the danger with any diet or weight loss program: avoid the yo-yo effect once the product is out.