Who’s really to blame for CMS performance challenges?

22 Jan 2014

7 Comments

Despite the title, this post isn’t about finger-pointing. Rather, I want to take some time to address the fact that performance is a widely recognized issue for sites that use a content management system. And I want to scratch the surface of these questions: to what degree is this a vendor problem versus a user problem, and what can site owners do to fix it?

A couple of weeks back, I made this prediction for 2014:

From WordPress to enterprise CMSes, we all know that content management systems cause performance hits that are hard — or downright impossible — to mitigate. This year, I think we’re going to see more CMS vendors realize that offering a product that enables better performance is a serious competitive differentiator.

Dan Jackson replied with a good question on Twitter:

Twitter post regarding CMS performance

The answer is: a bit of both. But the good news is that these problems are fixable.

First, some back story…

Roughly 33% of the top 10 million websites in the world use some kind of CMS. WordPress is by far the dominant player in the CMS space, with 60% market share. (I’ll spare you the math: this means that roughly 21% of websites use WordPress.) Lagging far behind are the other market leaders, including Joomla, Drupal, Blogger, and Magento, which collectively have about 6% market share. And then there are a few dozen more vendors bringing up the rear. [source]

There are three main reasons why CMSes were created and why they’re so popular:

  1. To segregate content from design and code, so anyone can make site updates.
  2. To create approval-based publishing processes for managers.
  3. To create audit trails for corporate lawyers.

Reason #1 is the real issue up for discussion today: non-technical people creating and adding content, AKA “when good content creators go bad”.

These well-intentioned folks don’t know about performance, and have no idea that their oversized graphics, animated gifs, and blinking rainbow-coloured headers can easily exceed 1 or 2 MB each. And they don’t understand that the text they copied and pasted directly from a Word doc is full of useless, bloated markup. And the CMSes themselves don’t warn users about these performance issues, because nobody has ever asked them to develop this as a feature. And of course no one asks CMSes to develop this feature because, as I pointed out at the top of this paragraph, the average content creator doesn’t understand performance. It’s a cycle perpetuated by lack of information.

(Note: The paragraph above might sound a bit critical, which isn’t my intent. We can’t expect the average person to care about something they don’t know about. This is why it’s the job of people inside the performance community to keep evangelizing performance outside our community.)

1. What kinds of performance problems do CMSes cause?

At the front end, a CMS by itself doesn’t really cause any problems. Almost all  of the “problems” are caused by content editors (who use rich text editors and have no idea what the content they are copying and pasting from another website contains) and by designers (who make nice-looking design elements with no lens for performance).

At the back end, however, some CMSes do create performance challenges. In this post for the 2011 Performance Calendar, Pat Meenan talked about the fact that, while the back end is only responsible for 10-20% of response time, when it goes wrong, it can really go wrong. Among other things, Pat shared his finding that “It is not uncommon to see 8-20s back-end times from virtually all of the different CMS systems.” Ouch. This problem is largely attributed to the fact that hosting for these (admittedly not top-tier) sites can vary hugely — with shared hosting being the most common environment — giving site owners zero visibility into the performance of the system they’re running on.

2. What kinds of performance fixes do CMSes prevent?

CMSes do make some optimizations difficult, depending on how extensible and open they are. Many CMS vendors make it very difficult to manipulate core objects such as images. Some make it difficult to edit and access JavaScript and CSS files, but this is changing. Many don’t have extensible editors or frameworks to look at the wildly unoptimized resources that editors and designers are putting in and warning people that, from a performance perspective, these resources suck.

3. Is this a problem with the CMS itself, or with how the CMS is implemented?

Both. Some CMSes are, frankly, not good. But most, to use a favorite analogy from my Strangeloop roots, are like trusty old firearms. Guns don’t kill people — people kill people. As we’ve already discussed here, the users of the system are a major challenge.

Another challenge is the fact that most in-house developers don’t want to touch a third-party CMS to make it more performance-friendly. There’s a perceived cultural bias that any developer with real chops shouldn’t be caught dead working on a CMS because it’s not serious coding.

4. So what’s the solution?

In an ideal world, a CMS would warn content creators about performance-hurting practices. To be fair to CMS vendors, this is difficult to codify; however, I feel that, given the increasing emergence of performance as a feature, vendors should attempt to aim for low-hanging fruit such as grossly unoptimized images and hidden markup.

It would also be great if vendors could give site owners overall visibility into the performance of their pages, specifically at the back end. I know so many owners of smaller sites who know that their pages are slow but, because they have no visibility, don’t know where to begin to tackle the problem. And hey, so long as we’re blue-skying, how about addressing the back-end response-time issue that Pat identified a couple of years ago?

My prediction/dream is that CMS vendors will step up to make performance a feature. Until then, if you’re using a content management system, you need to have a good team dedicated to looking at your site metrics on a regular basis (e.g. using a tool like WebPagetest). And you know what? An excellent FEO solution would be great, too. ;)

By: Tammy Everts Category: Best Practices Tags: , ,

Nine web performance predictions for 2014

7 Jan 2014

7 Comments

It wouldn’t be January without a crop of predictions for the new year, would it? I wouldn’t call these predictions, exactly. I’m not a prophet. No crystal ball here. I’m just looking at trends, and perhaps applying a little hopeful thinking. :)

1. We’re going to finally nail the m.site versus RWD question.

Last month, I wrote a post calling for the demise of m.sites in 2014, which provoked some really excellent discussion in the comments. I stand by that call. You may disagree, but I’m sure we both agree that it would be great to nail down this issue and move on.

2. Performance will stop being the sole domain of developers.

If I keep saying this, it’ll happen, right? When I was at Velocity Europe in November, I had a great conversation with O’Reilly publisher Laurie Petrycki. Among other things, we talked about the fact that performance optimization, up till now, has been primarily the domain of developers — and to be blunt, why this is unfair. Essentially, what’s happening is that IT is inheriting pages with performance problems caused by lack of foresight during the UX design phase, and now IT is forced to go backwards to identify and fix the problems, rather than taking a planning-first, forward-looking approach. Not only is this unfair, it’s also inefficient. Performance shouldn’t be kept in an IT silo or treated as an afterthought. It needs to be considered as an integral part of user experience design from stage one.

On the conference front, I’m hoping to see performance take the stage at events other than Velocity. While Velocity will always be the lodestone for our community, it’s essential to get out and speak to other communities. (On a personal note, I’m super excited about being invited to speak at IRCE’s Forward Mobility conference in February, and at eMetrics in June.)

3. Site owners will begin using more sophisticated techniques to measure page load and engagement.

It’s a well-discussed fact within the performance community that load time is a crude, imperfect method for measuring performance success or failure. Finding a more meaningful metric that can be measured easily is a huge challenge. At Radware, we’ve been looking at time to interact (TTI) in our quarterly performance state of the union reports. We define TTI as the moment that a page’s primary content — in the case of ecommerce sites, this is usually some sort of feature banner or carousel — renders in the browser and becomes interactive, i.e. has a usable call-to-action button or link. This is helpful, because it forces us to first prioritize the value of a page’s content, and then focus on measuring how long it takes that content to render. It’s a good first step, but it’s still just a first step.

I believe that savvy site owners are going to start making inroads into more refined ways of looking at how pages render and how this affects the user experience. After I presented the findings from our mobile engagement research at Velocity, I talked with a few site owners who were intrigued to learn more about how we conducted our EEG and eyetracking research. Applying eyetracking technology to measuring performance isn’t new — Jakob Nielsen did some interesting work in this arena back in 2010 — but it hasn’t been widely adopted. It’s a shame, because Nielsen’s findings were significant: Users who had to endure an 8-second download delay spent only 1% of their total viewing time in the feature slideshow space. In contrast, users who received instantaneous page rendering spent 20% of viewing time within the slideshow space.

While eyetracking technology has been around for a while, it’s only very recently that EEG technology has been lightweight, affordable, and relatively easy to use. While I won’t go so far as to say that it’s going to become a standard tool in your performance toolbox, I do believe we’re going to see it emerge occasionally during the application development process.

4. Pages will grow even bigger and more complex.

No surprise here. The HTTP Archive shows that the average top 1000 web page was 1607 KB at the end of 2013. Using a conservative estimate of 44% year-over-year growth (based on growth trends over the past three years), we can expect pages to exceed 2300 KB by the end of 2014.

2014 web performance predictions: Page growth

Don’t you wish you could travel back to 1995 and blow your own mind with this graph?

5. Embedded mobile browser performance will start getting attention.

This is a fascinating — and mostly overlooked — aspect of performance, but I believe this is going to change soon. Luke Wroblewski wrote a great post about this back in September, and I was surprised to see how few people jumped on it. He wrote, “When you consider Facebook users consume Web content inside a web view within the Facebook app, then Facebook is the second most popular Web browser on iOS and Android.”

Facebook isn’t the only embedded mobile browser. Twitter and Pinterest also embed web content. Just by way of illustrating this point, and not to single out any one app, here’s what it looks like when you’re waiting for a page to load within the Pinterest app. Yes, there’s a progress bar. No, it doesn’t move very quickly.

Web Performance predictions for 2014: Embedded mobile browser use

As a regular user of all three of these mobile apps, I’m very aware of the varying performance penalties they incur when they serve as a browser. The kicker, of course, is that as a site owner, you have no control over this performance obstacle. It’ll be interesting to see if and how these apps rise to the challenge of delivering a faster browser experience.

6. Third-party and fourth-party scripts will return to the main stage as a performance challenge.

It feels like this topic fell off the table in 2013, but it’s every bit as relevant — if not more so — than ever. Third-party scripts are continuing to proliferate, and the general public is slowly getting wind of the existence of forth-party scripts (which, in addition to posing performance challenges, also pose security challenges).

7. CMS vendors will step up to the plate.

From WordPress to enterprise CMSes, we all know that content management systems cause performance hits that are hard — or downright impossible — to mitigate. This year, I think we’re going to see more CMS vendors realize that offering a product that enables better performance is a serious competitive differentiator.

8. Enterprise performance will become a hot-button issue.

Ecommerce is sexy, public-facing, and relatively easy to measure, which is why a lot of the performance conversation revolves around it. Personally, I think the enterprise is pretty sexy, too, but it’s a walled garden. My goal for the year ahead is to get further inside this garden and tell more sexy enterprise stories.

9. Site owners will gain a better understanding of what a CDN can and can’t do for performance.

Content delivery is now available as a service at every price point. Today, more site owners than ever are taking advantage of a CDN’s ability to reduce latency by caching page resources closer to users. Yay. However, too many site owners now believe that they’ve done all they can do to fix performance. Boo. Between 80 to 90% of response time happens at the front end — at the browser. This is where site owners can find opportunities to make major performance gains by leveraging front-end optimization (FEO) techniques, such as resource consolidation, prefetching, preloading, advanced resource compression, and more aggressive browser-side caching (to name just a few). By combining a good CDN with a good FEO solution (*cough*), site owners can make pages up to four times faster and reduce total payload by up to 70%. This is huge. I’m calling this the year when companies that rely exclusively on their CDN to fix their performance woes will realize they can still get much faster.

What do you think? (Disclosure: In the past, I’ve been accused of being an optimist.) Am I way off the mark with any of these? What are your predictions/hopes/wishes/dreams for 2014? Let me know in the comments.

Related posts:

By: Tammy Everts Category: Best Practices, Mobile, Third-party content Tags: , , , , , , , , ,

Mobile stress: Slow pages undermine your entire brand

19 Dec 2013

0 Comment

This week, I’m posting over on the annual Performance Calendar, a kind of advent calendar for geeks — now in its fifth year! In my post, I shared some more findings from Radware’s recently released study into mobile “web stress”.

I don’t want to give it all away here, but I will tell you we learned that even seemingly minor page delays have a major effect on brand perception. I’ll tease you with a couple of before-and-after word clouds and then send you over to the post to get the full story.

Perception of a site that loads at normal speed:

Tesco.com: Word cloud (regular speed)

Perception of the same site after introducing a 500ms network delay:

Tesco.com: Word cloud (500ms delay)

DOWNLOAD: Mobile Web Stress: The impact of network speed on emotional engagement and brand perception

Related posts:

By: Tammy Everts Category: Ecommerce, Mobile, Research Tags:

Mobile stress: Slower web pages lead to increased user frustration and lower engagement

11 Dec 2013

1 Comment

I’ve been dying to write a post that takes a deeper dive into the research I presented at Velocity Europe last month, but wanted to wait until we had everything neatly packaged in a report for you to download. It’s here! So now I can write about it! WIN.

With just 40 minutes in my session, I wasn’t able to share all the findings from our three-part study, which blended electroencephalography (EEG) and eyetracking technologies with implicit response testing to track things like frustration, emotional engagement, and various aspects of brand perception on a moment-by-moment basis throughout a series of online transactions via smartphone.

Mobile EEG study

Background: Why we engaged in this research

No one has ever engaged in this kind of testing. Why do it now? (I mean, other than the fact that it sounds cool and looks like a scene from The Matrix.)

When we were weighing our research options at the beginning of this year, we knew that we wanted to study people’s expectations and assumptions about using the mobile web. Our hypothesis was that shopping on smartphones comes with inherent stress, and that this stress worsens when pages hang. The question was how to explore this hypothesis in a way that could yield fresh new insights.

We considered commissioning a survey about mobile user expectations. We ended up scratching that idea for a number of reasons, the main one being that there are already numerous surveys in this area. I know this because I cite them all the time. Without discounting survey-based research, which I do believe has merit, there’s a problem with surveys: they can all too easily be dismissed simply by pointing out the (admittedly true) fact that what people say doesn’t always match how they feel or behave.

People also have a tendency to misremember past experiences, so after-the-fact reporting needs to be taken with a large grain of salt. I see this regularly with surveys about user expectations and performance. For every survey stating that users expect pages to load at least as fast on their phones as they do on their desktops, there are countless naysayers who claim that mobile users are realists who accept that mobile pages are, by their very nature, slower.

We decided that we wanted a study that cuts through the noise of opinion. EEG research is important and exciting because it imposes unprecedented rigor on testing our assumptions. It’s also valuable in that it allows us to measure people’s moment-by-moment reactions as they move through a site in real time.

Our approach

With this project, we knew we were pioneering new territory, and we knew we’d need outside expertise to help us do it. We assembled a team of global specialists from Seren (leaders in customer experience and service design), Neurosense (a global leader in implicit methodologies) and NeuroStrata (expert consultants in blending neuromarketing applications). Together, we developed an approach we dubbed the Emotional Engagement Measurement Process, which I described at the top of this post.

Participants were given standardized shopping tasks on four sites — John Lewis, Tesco, EasyJet, and Ryanair — using an iPhone. We studied participants on these tasks, both at the normal speed over Wifi and also at a consistently slowed-down speed (using software that allowed us to create a 500ms network delay). The participants did not know that speed was a factor in the tests; rather, they believed that they were participating in a generic usability/brand perception study.

Mobile EEG test: Brands we tested

From the EEG data, we were able to extract measures of frustration and emotional engagement for the browsing and checkout stages of both the normal and slowed-down versions of all four sites.

Key findings

Over the course of our study, we had five “aha” moments. We learned that:

  1. Mobile users are significantly affected by slow performance. A 500ms connection speed delay resulted in up to a 26% increase in peak frustration and up to an 8% decrease in engagement.
  2. Slow sites can seriously undermine overall brand health – across both desktop and mobile platforms.
  3. The nature and scale of the impact varies, depending on a number of factors (e.g., inherent strength/weakness of brand).
  4. Brands with already fragile consumer affinity are at higher risk.
  5. The greatest risk of page delays is to purchase intent — people’s desire to actually spend.

Today I want to focus on finding #1: Slow pages result in increased user frustration and decreased engagement.

At the outset of our testing, we established baseline readings of participants using the test sites at normal speed. We then introduced the 500ms network delay. Looking at our EEG data, we noticed two metrics that were affected the most by performance degradation: frustration and engagement.

First, let’s look at peak frustration levels:

Mobile web stress: Frustration levels (normal and slow)

Three out of the four sites saw increased frustration peaks when the site was slowed down. In general, John Lewis and EasyJet had higher frustration peaks during browsing when the site was slowed down, with John Lewis experiencing the highest peak, at 26%, during the browsing phase. Ryanair experienced its highest frustration peak, at 22.8%, during the checkout phase.

There are two primary tasks users perform on an ecommerce site:

  • Decision-making (browsing)
  • Form-filling (checkout)

Decision-making is the more cognitively demanding, and therefore leaves users more vulnerable to becoming frustrated if other elements (such as page rendering) slow them down. The browsing stage is where most of the decision-making occurs, therefore it is not surprising that this was where we were most likely to see increases in frustration. (The exception was Ryanair, which saw a higher increase in frustration at the checkout. But that’s a subject for another post, which I’m planning to publish next week.)

Next, let’s look at emotional engagement:

Mobile web stress: Emotional engagement (normal and slow)

Emotional engagement is a positive metric. Three out of the four sites saw a decrease in average engagement when the site was slowed down. John Lewis customers were slightly less likely to engage with the browsing experience while the Tesco site was more affected during the checkout phase. Both browsing and checkout were affected on the EasyJet site.

Conclusion and takeaways

It would be great if there were a grand unified theory of performance and user perceptions. There isn’t. Every site is different, and performance issues affect every site differently. Depending on the page being looked it, the neurological impact of slower load times can be either heightened or offset by other aspects of the page, including layout, visual design, content, and the order in which page resources render.

What we can take away from this research:

  1. Performance has a clear and measurable impact on users at a pre-cognitive level.
  2. This early research validates the premise of neuroscientific testing.
  3. Given the accessibility and affordability of the technology used in this study, I predict that more and more companies will look to neuromarketing to help identify performance and usability issues in their own websites and applications.

DOWNLOAD: Mobile Web Stress: The impact of network speed on emotional engagement and brand perception

Related posts:

By: Tammy Everts Category: Human factors, Mobile, Research Tags: ,

Six reasons to ditch your m.site in 2014

4 Dec 2013

12 Comments

In just a couple of short years, m.sites have gone from must-have to must-not-have. Here’s a short history of the m.site and why, if you haven’t ditched yours already, you should make it a priority to retire it in 2014.

The history of the m.site in 64 words

Waaaaay back in 2010, when smartphone users suddenly surged online, site owners realized their pages were brutally slow — or completely non-functional — on mobile devices. Panic ensued. Serving a pared-down version seemed like a logical stopgap solution.So, for a while, if you used a smartphone, the internet looked like this:

Which wasn’t great, but it was a lot better than this:

Or this:

Today, there’s no excuse for m.sites.

After a couple of years, the votes are in, and most mobile users are vehemently against m.sites. Fortunately, responsive web design and mobile-specific front-end optimization techniques have emerged as solutions for the problems of poor layout/usability and slow performance (though, admittedly, manual implementation of these techniques isn’t necessarily easy).

Before we get into the problems with m.sites, first let’s de-obfuscate a few key terms…

M.site, mobile-optimized, mobile-friendly… wut?

If you’ve ever found yourself stymied by these terms, you’re not alone. Let’s bring some clarity to the conversation.

M.site –  Also known as a mobile site, m-dot site, m(dot) site, and various permutations thereof. This is a separate entity from the full site (aka “desktop site” and “main site”), and is usually a stripped-down version of the full site, with simpler navigation, less content per page, and/or fewer pages. When a user attempts to visit a full site via a mobile device, they are automatically redirected to the m.site.

Mobile-optimized site — This term is used nebulously to cover a variety of scenarios — from m.sites to full sites that have been optimized to load faster and/or responsively. My opinion is that this term should be applied only to full sites that have been optimized to perform better on mobile devices.

Mobile-friendly site – I hear this phrase a lot, and it’s even more nebulous than “mobile-optimized”. The problem with “mobile-friendly” is that it sounds great, but it’s so vague as to be almost meaningless. For example, mobile user surveys that ask people if they’re more likely to shop at sites that are “mobile-friendly” or “not mobile-friendly”. Of course people are going to answer “mobile-friendly”. I would, too! But this leaves site owners completely open to interpret “mobile-friendly” in whatever way is most convenient to them. M.site? Yeah! Responsive site? Sure! Simply capable of loading in a mobile browser? Works for me!

So, to summarize:

  • M.site = not good
  • Mobile-optimized = good (so long as we’re talking about an optimized version of the main site)
  • Mobile-friendly = great as a philosophical goal, but not as a specific descriptor for a type of site

What? You’re still not convinced that m.sites aren’t the answer to your mobile performance problems? Read on…

1. Up to one-third of your visitors are going to go to your full site anyway.

That’s right. According to research we conducted a while back, analyzing millions of ecommerce transactions on our customers’ sites, 35% of mobile users will choose to view the full site when given the option.

2. Mobile shoppers spend up to 5.5 times more on the full site than they do on the m.site.

In the same study, we found that mobile users who shop the full site spend much more than those who shop the m.site. We found that, for every $7.00 of mobile-generated revenue, $5.50 (79%) was generated by mobile shoppers using the full site. Only $1.00 (14%) came via m.site, and $0.50 (7%) via the mobile app.

Mcommerce spending breakdown

3. When it comes to making pages faster, m.sites don’t help as much as you’d think.

In Radware’s 2013 State of the Union for Mobile Performance, we found that the median full-site load time on the iPhone 4s was 7.84 seconds, and the median m.site load time was 4.33 seconds. While the m.site was 44% faster than the full site, it still didn’t meet users’ wait-time threshold of 4 seconds or less. Why? Two reasons: Redirects and latency.

Let’s talk about redirects first. Unless users are specifically typing in your m.site’s URL, they’re being redirected from your full site to your m.site. Redirecting takes time. (As Google performance guru Ilya Grigorik says, “The optimal number of redirects for mobile is exactly zero.”)

Now let’s talk about latency. The median m.site page we tested contained 27 resources (e.g. images, CSS, etc.) – in other words, approximately one-third the number contained in the median full-site page. Given this, you might expect the m.site to be three times faster than the full site; however, other factors, such as latency and download speed – both of which can be very inconsistent on mobile devices – contribute to performance. For people using 3G networks, Ilya Grigorik states that you should assume 2 seconds of latency right out of the gate.

The takeaway is that site owners need to know that that simply stripping down their sites into pages with fewer resources is not a performance cure-all.

4. Google doesn’t like m.sites.

Speaking of Google… yeah, Google doesn’t like redirects, hence Google doesn’t like m.sites. If you care about SEO, then you should ensure that each page of your site has only one URL.

5. M.sites make cross-platform sharing ugly.

Ever click on a link that one of your Facebook friends posts to their feed from their phone? And then discovered that it was a link to an m.dot page? But you’re on a PC or tablet? Uh-huh.

Or let’s look at this problem from the other end… have you ever been using Facebook on your phone, clicked on a link that one of your friends posted from their desktop, and then seen something like this?

This is what happens when we build websites in silos. Put it another way: Back when laptops arrived on the scene and site owners suddenly had to change their understanding of the range of specs they had to accommodate, did you ever hear anyone say, “I know! Let’s build a laptop-only version of our site!” (I hope you didn’t, but if you did, I sincerely want to hear that story.)

6. Managing multiple sites, each with unique content requirements, is a pain.

This practice — called “forking” — isn’t just difficult, it also makes you more susceptible to mistakes. Most CMSes aren’t cut out to handle the complexity of populating different design templates with different content, so maintaining an m.site means that you’re managing two distinct entities. This means that you need to apply all the same considerations — including identifying content requirements; writing and editing copy; sourcing, sizing, and formatting images; conducting usability tests; engineering performance, etc. — for every page of TWO separate sites. I don’t know of any site owner who is fully doing this. More often than not, the m.site is either an afterthought or a side project, when in fact mobile deserves its own share of focus.

Resolution for 2014: One web to rule them all

As I’ve said elsewhere, we live in a mobile-first world. But equally important, we live in a multi-screen world. 90% of people move between devices to accomplish a goal, and these devices are increasingly fragmented. Device fragmentation isn’t going to disappear. The line between phone, tablet, and laptop is only going to get blurrier. Siloed websites are not the solution, and as more time passes, siloed websites are poised to create more and more problems — from a usability perspective, from a back-end perspective, and from all points in between.

Over the past twenty-odd years, we’ve been spoiled as technology has evolved to give us unparalleled processing power, networks, and browsers. We’ve luxuriated in this… reveling in video, massive high-res image files, JavaScript out the yin-yang, and hundreds of resource calls across dozens of hosts. Page bloat is real, and it’s out of control.

Here’s a scary and exciting thought: Mobile is going to force us to radically rethink how we build websites and web-based apps. Let’s embrace it. Even if mobile devices and networks get ten times faster, people don’t want to — or can’t — digest the amount of content we’re currently throwing onto desktop screens. Screen size won’t allow it, and if you’re actually, you know, out there being mobile, you don’t want to sit down and read it all. (And my personal theory: I don’t think people want all this out-of-control content on their desktop, either.)

Let’s make 2014 the year that we desegregrate the web. No more mobile web. No more desktop web. Just one web — and let’s make it as fast, efficient, and beautiful as we can.

Related posts:

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