Viewing entries posted in 2012

Web Performance Digest: August 2012 - Facebook's big iOS update, SPDY vs. HTTP, and how to use WebPagetest

29 August 2012

Contributed by Tammy Everts. 

At the end of each month, we update our Web Performance Hub with a collection of the most compelling articles, posts, videos and presentations from around the web performance community.  

This month's Web Performance Digest features 10 new links. Get the latest on Facebook’s big update to their iPhone and iPad application, find out if SPDY outperforms HTTP, and learn how to use WebPagetest to measure site performance.  

New links include:

First Annual State of the Union for Mobile Ecommerce Performance [announcement]
Velocityconf.com – August 23, 2012
Summary: At this October’s Velocity Europe conference, Strangeloop’s Joshua Bixby will unveil findings from the first-ever study of mobile performance over 3G networks. What will his presentation include? Check out this post to find out. 

Facebook Doubles Speed of iPhone and iPad App with Update [article]
BusinessWeek.com – August 23, 2012
Summary: Facebook is launching a major update of its iPhone and iPad application, aimed at doubling start-up and page scroll speeds on Apple devices. How important is this update? Considering how a lack of mobile monetization has affected their freefalling stock price, we'd say pretty important.

Visualizing SPDY vs HTTP [diagram]
Belshe.com - August 21, 2012
Summary: As this chart illustrates, SPDY is (almost) always faster than HTTP. Using a copy of Alexa’s Top-300 websites for the test, Google’s Mike Belshe shows us how SPDY outperforms across a number of KPIs.

SaaS APM For the Win - A Gartner APM Leader [article] 
NewRelic.com – August 21, 2012
Summary: Gartner’s 2012 edition of its “Magic Quadrant for Application Performance Monitoring” report has placed New Relic in its coveted “Leaders” quadrant. Read on to find out why this SaaS vendor is gaining such praise. 

Mobile consumers expect speed greater than what many retailers are providing [article] 
InternetRetailer.com – August 20, 2012
Summary: A new poll by Keynote Systems makes it clear that mobile site owners ignore user expectations at their own peril. Mobile users cite slow pages and improper page rendering as their top two concerns. Check out this article to see how much the mobile ‘expectation gap’ has tightened.

Performance: See a Bigger Picture [blog post]
SpeedAwarenessMonth.com – August 20, 2012
Summary: Strong web performance comes from a comprehensive approach encompassing a range of design and implementation details, not a focus on one specific facet. This post details how looking at the ‘big picture’ is the best way to ensure success.

Images. Can we have less? [blog post]
Yoav Weiss – August 16, 2012
Summary: It’s no secret that the proliferation of images online adds to latency and hinders performance. Using ‘lossless compression’ and WebP, Yoav Weiss shows us how much we can reduce image sizes and load times to improve performance.

New findings: How does browser usage vary throughout the week? [blog post]
Web Performance Today – August 8, 2012
Summary: Web users are quite particular about their browsers. We know the overall usage statistics for each browser, but how much do these rates vary throughout the day and week? Check out this post to see if your assumptions hold true.

A History of Web Performance @ Lonely Planet [blog post]
LonelyPlanet.com – August 7, 2012
Summary: Lonely Planet’s web performance journey began at Velocity 2010, and continues today as they document the effectiveness of their optimization efforts. Just how valuable has performance optimization been to their online presence? Check out this post to find out.

Getting started with WebPagetest [blog post]
SpeedAwarenessMonth.com - August 2, 2012
Summary: Measure, analyze, adjust…repeat. Performance optimization is a test of patience, but online tools like WebPagetest makes the process much easier. This post is the perfect beginners guide for performance novices.

Check out the rest of the Hub for hundreds more links to the best selection of performance-related resources on the web.

We tend to all hold pre-conceived notions as to which browsers people use at work versus what they use at home. As very little data is available on the subject, these semi-educated guesses are mostly based on anecdotal evidence.
There’s plenty of aggregate data on overall browser usage, but we at Strangeloop wanted to delve further in hopes of answering a few lingering questions: How does usage vary throughout the day? Does everyone switch to Chrome or Safari at night? Do users actually like Internet Explorer?  
Methodology
1. Gathered monthly traffic data from two large North America-based ecommerce sites.
2. Isolated traffic for the four major browsers: Chrome, Firefox, Internet Explorer, and Safari.
3. Aggregated data for each day of the week and plotted it on a graph for each site.
4. Aggregated data for each hour of the day and plotted it on a graph for each site.
By the numbers…
Browser usage throughout the week
(pic 1)
(pic 2)
Observations
The vast majority of visitors used Internet Explorer
Safari traffic increased dramatically over the weekend
Weekend traffic flatlined or decreased for every browser except Safari
Friday is a big browsing/shopping day across all browsers
Browser usage throughout the day
(pic 3)
(pic 4)
Our main observation from these graphs is that Internet Explorer, Firefox, and Chrome use decreases towards the end of the day, just as Safari is trending upwards.  
Takeaways
Though this data represents only two websites, we can comfortably draw two conclusions:
1. Internet Explorer should remain the default browser for testing North American ecommerce sites. Though usage dips at night, the majority of browsing/shopping is still done on this browser.
2. The good times are rolling on Safari. By day’s end, users are flocking to this browser. We don’t know for sure, but some here in the office have theorized that this is due to skyrocketing growth in the iPad market. Either way, the trend is quite prominent. 
Once again, this data represents a very small sample size. We’re still in the early stages of the browser wars, so it remains to be seen if these trends stay consistent. 
For more on the browser wars, check out last month’s post “Has IE8 run its course as a default test browser

For SaaS providers, faster applications lead to higher adoption rates and improved developer productivity

28 August 2012

Contributed by Tammy Everts. 

For software as a service (SaaS) providers, application speed now stands as a huge competitive differentiator. Once focused on gaining advantage through features, vendors are now concentrating on performance, and for good reason: test data consistently shows that faster applications boast significantly higher conversion rates than their sluggish counterparts.

The SaaS market continues to grow

The push to gain a competitive advantage through performance has gained momentum due to consistent growth in the industry. Worldwide SaaS revenue is forecast to reach $14.5 billion in 2012 – up 17.9% from 2011 – with long-term projections topping $22 billion by 2015.

This strong market growth coincides with greater understanding amongst companies as to the true impact of application performance. Companies increasingly realize that performance metrics have huge effects on productivity, employee morale, and customer satisfaction. 

Slow web applications can quickly escalate to a serious productivity loss

As SaaS applications predominantly serve business-related functions such as customer relationship management (CRM), accounting, collaboration, and resource planning – all highly time-sensitive tasks – a slow web application can quickly escalate to a serious productivity loss. A recent survey by Kaminario cited poor application performance as a cause of reduced employee productivity in 25% of respondents. With this in mind, it’s easy to see why poor performance can take a SaaS vendor out of the running early when customers consider their options.

"The function of SaaS applications is to increase efficiency, to streamline inter-departmental functions,” says David Madison of equaTEK, an enterprise web solution developer. “When prospects have a free option, there’s no room for performance drawbacks. Our customers are very sophisticated, and they feel high performance should be inherent to any application they use. As such, applying front-end-optimization to our products became a matter of how, not if."

How does front-end optimization boost application speed?

Front-end optimization (FEO) optimizes HTML to speed up page rendering by using techniques such as rewriting object names, re-ordering when/how objects are rendered, re-ordering when scripts are executed, and optimizing content based on the requesting browser. 

To accelerate their applications, SaaS vendors such as equaTEK have two main options: optimize pages manually in-house, or seek an automated third-party solution. Justifying the latter is difficult for many vendors, as they usually have some of the technical chops needed to optimize in-house. What they don’t have is the time.

equaTEK faced just such a dilemma. After recognizing the importance of front-end optimization, they began hand-coding pages in an effort to do their own optimization. They soon realized that performance tuning was time-consuming, complex, and demanded the skills of their best developers. The company began exploring third-party solutions, eventually settling on a trial of the Strangeloop Site Optimizer.

"You can spend a lot of hourly rates and weeks trying to enhance the performance of software functionality, whereas a matter of installing Site Optimizer accomplishes a milestone leap forward that is just amazing," says Madison. "I’d much rather engage an application that’s going to take me from 0 to 50 right now, guaranteed, than spend a whole lot of time working out how to tweak this line of code versus that line of code in an unknown time period. Not only does this take a lot of an engineer’s time, there’s also the risk that you get very little improvement."

Automating front-end performance leads to six-month ROI

After implementing Site Optimizer, equaTEK's productivity gains had a quick, measurable impact, leading to a six-month return on investment.

"Using our average billing rate, we probably had a rate of return of 250 to 300 man hours," says Madison. "I would say that we probably shaved six months off our internal production work. So our return was six months. That’s part of the reason that, for us, buying Site Optimizer was a no-brainer. It’s not often that you get to see that type of a turnaround."

Developer productivity is one key benefit of automated performance optimization. Increased conversions is another. Internal testing of client SaaS applications accelerated by Strangeloop shows that a 50% increase in response time boosts conversions and page views by 5% and 26% respectively, while decreasing bounce rates by up to 14%.

Accelerate the performance of your SaaS products

Find out how we can make your SaaS applications up to twice as fast for desktop and mobile users.


New findings from the browser war front lines: Internet Explorer rules by day, Safari by night

21 August 2012

Contributed by Joshua Bixby. 

Most of us tend to hold preconceived notions as to which browsers people use at work versus what they use at home. These semi-educated guesses are based on anecdotal evidence, as very little data is available on the subject.

There’s plenty of aggregate data on overall browser usage, but we at Strangeloop wanted to delve further in hopes of answering a few lingering questions:

  • How does usage vary throughout the day?
  • Does everyone switch to Chrome or Safari at night?
  • Do people actually like Internet Explorer?  


So we ran a few tests...

Methodology

1. Gathered monthly traffic data from two large North America-based ecommerce sites.

2. Isolated traffic for the four major browsers: Chrome, Firefox, Internet Explorer, and Safari.

3. Aggregated data for each day of the week and plotted it on a graph for each site.

4. Aggregated data for each hour of the day and plotted it on a graph for each site.

The numbers

Browser usage throughout the week

Observations

The vast majority of visitors used Internet Explorer.

Safari traffic increased dramatically over the weekend.

Weekend traffic flatlined or decreased for every browser except Safari.

Friday is a big browsing/shopping day across all browsers.


Browser usage throughout the day


Our main observation is that Internet Explorer, Firefox, and Chrome usage decreases towards the end of the day, just as Safari is trending upwards.  

Takeaways

Though this data represents only two websites, we can comfortably draw two conclusions:

1. Internet Explorer should remain the default browser for testing North American ecommerce sites. Though usage dips at night, the majority of browsing/shopping is still done on this browser.

2. The good times are rolling on Safari. By day’s end, users are flocking to this browser. We don’t know for sure, but we're theorizing that this is due to the iPad market's skyrocketing growth. Either way, the trend is prominent and persistent. 

For more on browser usage, check out our recent post: Has IE8 run its course as a default test browser?

Learn how to make your site faster across all browsers

To learn how Strangeloop can help accelerate your page load times across all major browsers, visit our Site Optimizer or Mobile Optimizer product pages.

We tend to all hold pre-conceived notions as to which browsers people use at work versus what they use at home. As very little data is available on the subject, these semi-educated guesses are mostly based on anecdotal evidence.
There’s plenty of aggregate data on overall browser usage, but we at Strangeloop wanted to delve further in hopes of answering a few lingering questions: How does usage vary throughout the day? Does everyone switch to Chrome or Safari at night? Do users actually like Internet Explorer?  
Methodology
1. Gathered monthly traffic data from two large North America-based ecommerce sites.
2. Isolated traffic for the four major browsers: Chrome, Firefox, Internet Explorer, and Safari.
3. Aggregated data for each day of the week and plotted it on a graph for each site.
4. Aggregated data for each hour of the day and plotted it on a graph for each site.
By the numbers…
Browser usage throughout the week
(pic 1)
(pic 2)
Observations
The vast majority of visitors used Internet Explorer
Safari traffic increased dramatically over the weekend
Weekend traffic flatlined or decreased for every browser except Safari
Friday is a big browsing/shopping day across all browsers
Browser usage throughout the day
(pic 3)
(pic 4)
Our main observation from these graphs is that Internet Explorer, Firefox, and Chrome use decreases towards the end of the day, just as Safari is trending upwards.  
Takeaways
Though this data represents only two websites, we can comfortably draw two conclusions:
1. Internet Explorer should remain the default browser for testing North American ecommerce sites. Though usage dips at night, the majority of browsing/shopping is still done on this browser.
2. The good times are rolling on Safari. By day’s end, users are flocking to this browser. We don’t know for sure, but some here in the office have theorized that this is due to skyrocketing growth in the iPad market. Either way, the trend is quite prominent. 
Once again, this data represents a very small sample size. We’re still in the early stages of the browser wars, so it remains to be seen if these trends stay consistent. 
For more on the browser wars, check out last month’s post “Has IE8 run its course as a default test browser

What you don't know about "fourth-party calls" could be hurting your users

13 August 2012

Contributed by Grant Ellis. 

In recent months, site owners have grown increasingly aware of the negative impact that poorly optimized third-party scripts have on site performance. 

Our research has led us to uncover a layer of performance interference one step beyond the third-party, which we'll dub "fourth-party calls" for the time being. But before delving further, let’s back up.

The job of an ecommerce marketer is not easy. As this graphic illustrates, a complicated web of technologies and intermediaries separates advertisers and publishers, and it’s the marketers to make sense of it all:

The job of an ecommerce marketer is not easy. As this graphic illustrates, a dizzying web of technologies and intermediaries separates advertisers from publishers, and it’s the marketer's job to make sense of it all:


What does this mean for the web performance landscape?


With this in mind, we can forgive marketers for sometimes not fully considering the technical ramifications of their decisions. Nevertheless, third-party scripts proliferate the number of "single line of code" requests, hampering ecommerce site performance and causing untold headaches for IT and development teams.

Here at Strangeloop, we deal with the challenge third-party interference every day, so we're keen to dig as much as possible on the subject. From our research, we've determined that fourth-party calls not only cause further disruption to the user experience, but also compromise end-user security. Let's look at two examples:


Example 1: Single third-party call ---> fourth-party calls you never authorized ---> slower page load

  1. A site owner is approached by a third-party company to add a single line of code; the site developer is asked to paste in a simple code fragment.
  2. The code implemented - a third-party script - authorizes a whole new wave of fourth-party calls.
  3. The server calls slow down the website.


Here's a waterfall to illustrate
:




(If you're new to waterfalls, here's a quick rundown of how they work)


A breakdown of the waterfall:

  • The third-party tag triggered 49 unauthorized server calls to fourth-party servers.
  • Of the 49 calls, 21 are redirects (red dots), which set off ping-ponging redirects that waste valuable load time.
  • Every one of the fourth-party calls is over SSL, which impacts load time.
  • The result: an added 1.8 seconds to the page’s load time (a death sentence for many ecommerce sites)
But performance impact aside, the main concern here is that unauthorized companies are filling up their databases with detailed information on customers and products.


Example 2: Fourth-party call ---> data loss and privacy concerns

The biggest privacy concern with fourth-party calls is that they have unrestricted access to user data: they can see and capture everything about users without consent, and their information-gathering techniques are highly sophisticated.

Here's an example from the Skechers site:


After visiting this website, a later unrelated visit to the New York Times website yields a Skechers ad in the bottom right-hand corner of the page:

This is an example of retargeting, a.k.a. delivering ads to you based on your previous actions. Although Skechers pays a great deal of money to have The NY Times show this ad, the concern is that the data they authorized a third-party to use is made available to the other fourth-party calls.

A few other thoughts:

  • The nature of the data flowing out of the original site (to who knows where) is alarming. Site owners should not want their users’ entire browsing history, including what products they looked at, collected and sold by unauthorized parties.
  • The fourth-party calls could change any time at the request of the third party — or even another fourth party — as calls cascade from one company to the other.
  • This data makes Facebook's privacy setting adjustments look trivial by comparison, as these settings are something users can control. If users knew how much of their personal browsing history has already been captured and stored in countless databases, the outcry would drown out the Facebook-related complaints.


Takeaway: Seven questions for site owners using third-party tags

1. Are you aware of the fourth-party calls made from third-party tags on your site?

2. Have you talked about performance with your third parties and asked them what impact their tags will have on your page speed?

3. If your third-party vendor decides to change the fourth-party calls it references, are you notified?

4. Have you pushed your third-party vendor to optimize the way it handles calls or how it deals with fourth parties?

5. What data are the fourth parties collecting?

6. Does this usage comply with your corporate governance guidelines?

7. Do these fourth-party calls contravene your customer-facing privacy policy?

Learn more

Strangeloop uses groundbreaking technology to limit third and fourth-party interference, helping site owners maintain high web performance even while running third-party scripts. To learn more, visit our Site Optimizer or Mobile Optimizer product pages.


Testing your site's vulnerability to third-party failure

7 August 2012

Poorly-optimized third-party scripts not only hinder usability, but can easily take down an entire site. In web performance, these culprits are commonly referred to as SPOFs – single points of failure.

Third-party SPOFs can easily nullify significant (and expensive) CDN performance gains, leaving users staring at soon-to-be-abandoned blank screens. But despite these clear performance drawbacks, measuring their impact is often an afterthought.

Strangeloop tested the top five ecommerce sites to see how SPOF interference affected performance. For the tests, all third-party domains were blackholed except the CDN domain. A series of side-by-side videos were generated for each site, with waterfalls included for quick identification of the major culprits.

Amazon.com

Waterfalls: normal vs. broken

Observations:

  • Site still performs reasonably well
  • Site looks mostly fine, except for empty ad spaces

Staples.com

Waterfalls: normal vs. broken


Observations:

  • When Omniture dies (see line 18 in waterfall) the entire site stalls for almost 30 seconds.
  • Site is entirely dependant on Omniture.

Apple.com

Waterfalls: normal vs. broken


Observations:

  • Very few third-party calls.
  • Nothing blocks. The entire internet could go down and this site would still work.

Dell.com

Waterfalls: normal vs. broken


Observations:

  • As with Staples, Omniture blocks the page request (see line 11 of the waterfall), this time for almost 20 seconds

OfficeDepot.com

Waterfalls: normal vs. broken


Observations:

  • This waterfall is the worst of the bunch.
  • The issue here seems to be that the file is an external JavaScript file very near the top of the page, which is why the effect is so bad. The page is white until it times out trying to connect to the broken domain.
  • The same behaviour happens when testing this page with HTTPWatch in IE9, Firefox 7, and Chrome 16.

How are top ecommerce sites using third-party scripts?

Strangeloop did an audit of the top 200 Internet Retailer sites to see how they were implementing third-party scripts. here are some of the results:

Average number of third-party scripts: 


Average # of 3rd-party scripts
Top 200 sites
6.7
Top 20 sites
3.5

*6.7 is significant, but some sites use many more than that…

Top sites, in terms of the number of third-party scripts used

Site # of 3rd-party scripts
Coastal Contacts
25
Express LLC
23
American Greetings
22
Urban Outfitters
21
The Sports Authority
20
Coldwater Creek
19
American Girl
19
RealNetworks/GameHouse 18
Chico’s FAS
18
Signature Styles/Spiegel
17
Boden USA
17

*When looking at the sheer volume of widgets and third-party tools available, these numbers aren't too surprising. 

Most-used third-party scripts

3rd-party script provider
Appearance in top 200 sites
Omniture
98
Google Analytics
97
DoubleClick Floodlight
49
DoubleClick
45
Google AdWords Conversion
45
Coremetrics
44
Right Media
40
Foresee 36
Microsoft Atlas
33
LeadBack
32
DoubleClick Spotlight
29
Turn
29
Facebook
27
Acerno
26
Rubicon
25
Channel Intelligence
24
Dotomi
22
Interclick
22
Traffic Marketplace
22
Adconion
19
Channel Advisor
19
Resonance
19

*Many people would guess Facebook because of its visibility, but this is a good reminder that “invisible” scripts are actually more prevalent than obvious content like social buttons.

Test conclusions

From this data, it's clear that site owners are implementing more and more third-party scripts, sometimes improperly. The sheer volume of scripts indicates that little analysis is being conducted as to how these scripts affect performance.  

Bottom line: it doesn't matter how well you optimize a site if a single script - or one errant line of JavaScript - can throw the whole operation.

How Strangeloop addresses third-party SPOFs 

To give site owners peace of mind as to how third-party scripts affect performance, both our Site Optimizer and Mobile Optimizer minimize the impact of third-party content by deferring and/or parallelizing third-party requests so they don't block key site content. To learn more, talk to a Strangeloop performance expert.


Web Performance Digest: July 2012

6 August 2012

At the beginning of each month, we update our Web Performance Hub with a collection of the most compelling articles, posts, videos and presentations from around the web performance community.  

This month's Web Performance Digest features 10 new links. Read all about tech giant Neustar, who have flown very much under the public radar despite playing a massive role in telecom information sharing. Elsewhere WebPagetest launches an important update, and Smart Planet discusses the “incredible shrinking internet.”

New links include:

The Most Important Tech Company You've Never Heard Of [article]
BuzzFeed – July 16, 2012
Summary: Delaware-based Neustar has flown so far under the radar in their massive surveillance infrastructure business, they’ve been dubbed  the “Keyzer Söze of surveillance.” Despite holding critical data from over 400 telecommunications companies, the world is convinced they do not exist.  

IT Operations News Roundup – July 16th to 22nd [roundup]
Catchpoint – July 16, 2012
Summary: This collection of technical articles is a great roundup of what’s going down in the tech world right now. Read about data center inefficiencies, new funding for Internet2, and some copycat bickering between Samsung and Apple. Perfect for those who like the nitty-gritty of tech operations. 

WebPagetest 2.7 Now Available [announcement]
WebPagetest – July 13, 2012
Summary: WebPagetest.org – a much beloved resource amongst the nerd-squads here at Strangeloop – has released version 2.7 of its popular performance measurement tool. Read about the new improvements that have made it even more useful, especially with regards to Chrome and Firefox.

How fast are your web services? [article]
AppDynamics – July 11, 2012 
Summary: A dizzying web of third-party service providers combine to make today’s applications function. Unfortunately, this means the user experience is at the mercy of the worst service provider. Check out this post on why application providers should first check their external service providers before troubleshooting their own product.

The incredible shrinking Internet [article]
Smart Planet – July 3, 2012
Summary: A finite group of companies have the ability to power web traffic. Some are CDNs, some are larger content companies like Netflix or Rackspace. Either way, the number of entities powering the internet is shrinking. Read on to find out why some believe this consolidation is inevitable.

Check out the rest of the Hub and see hundreds more links to the best selection of performance-related resources on the web. (Have we missed something? Send us your link recommendations!)


What mobile data throttling means for site owners

1 August 2012

With the ongoing explosion of mobile-only internet users, data consumption on cell networks is a huge problem that – based on current trends – stands to get much worse. To illustrate the point, let’s look at some numbers:

  • A recent Cisco report estimates the number of mobile-only users will swell to 788 million by 2015. (There were 14 million in 2010.)

  • The same report estimated the average monthly mobile data volume in 2011 to be 597 petabytes – roughly 625 million gigabytes.

  • Customers are using mobile data for much more than just "mobile-optimized" sites.  Many customers are treating mobile just as they would desktop, downloading games and apps, streaming music, watching videos, using GPS, and playing online games.

  • Mobile video traffic exceeded 50% of mobile bandwidth in 2011, with an estimated 31 million accessing video on mobile devices.

  • 33% of Facebook’s traffic in 2011 came from mobile, as did 55% of Twitter’s traffic and 60% of Pandora’s.

What does this mean for site owners?

Data is the lifeblood of mobile commerce, and restricting it has only negative implications for site owners. A main goal of site owners is (or should be) to deliver a seamless user experience regardless of device, and this cannot be accomplished without a free flow of data.

Solutions

There’s no easy solution here, only measures that can be taken to minimize the problem. 

Solution 1: Consumers will self-educate on data usage.


Pro:
Apps like Traffic Monitor and 3G Watchdog (both for Android) show data usage for every app on your device.

Con: Some users will self-monitor their data usage, some won’t. Overall, we’re not wired to consume our media this way.

Solution 2: Consumers will use wi-fi instead of their 2G/3G/4G network.


Pro:
Using a wi-fi hot spot doesn’t count against monthly data allotments.

Con: Like data usage, the average mobile user isn’t going to put the work in to constantly monitor what mode they’re in. (Nor should they, in our opinion.)

Solution 3: Carriers will continue to impose data caps and throttle high-bandwidth users.


Pro:
From a carrier’s perspective, the numbers cited earlier in this post make a compelling argument for throttling. Some may be challenged to keep up their data usage commitments.

Con: Throttling effectively destroys the user experience. It’s also not a great long-term strategy for carriers, as given current data usage trends, the average person’s usage will soon equal that of a "power user". If everyone is a power user, does that mean everyone ultimately is throttled? It’s easy to see why this is a dead-end street for carriers.

Solution 4: Site owners will funnel users toward leaner "mobile-optimized" sites.


Pro:
Modern websites are designed for big screens. They send high-resolution images that are unnecessarily high quality for mobile phones, and these big images bloat pages. Serving leaner, stripped-down pages to mobile users is a relatively easy way to deal with this problem.

Con: We believe this solution is deeply flawed. Mobile-optimized sites don’t render properly on tablets, which are technically mobile devices. Further, users don’t want a stripped-down online experience. 

Solution 5: Site owners will explore new technologies to solve the mobile bandwidth problem.


Pro:
There's no fix-all solution to the bandwidth problem. The real solution will be a combination of new solutions — including, yes, advanced front-end optimization solutions like Strangeloop’s — as well as mobile-specific content delivery networks and infrastructure investments.

Con: Site owners must understand that bandwidth is everyone’s problem. Delivering unnecessarily huge (and unnecessarily slow) pages to mobile users will result in lost traffic and lower conversion rates, as throttled users view fewer pages and spend less money.

How Strangeloop can help reduce mobile data usage

Strangeloop’s Mobile Optimizer features a groundbreaking suite of features aimed at helping site owners make their sites more data-efficient and deliver a better user experience for mobile users. 

Learn more

These are just two of the features in Mobile Optimizer aimed at improving the end-user experience for mobile customers. To learn more, visit the official Mobile Optimizer product page.