dna42 response time graph

How to optimize your mobile site speed: Testing for issues


The right picture is very useful on mobile and responsive websites. But images that are too large, too numerous and unnecessary simply slow down page load times and get in the way of the users reading and doing what they need to do.

The problem: the size of webpages sent to mobile phones has quadrupled in just five years. The main cause: images, which account for 68% of total page weight.

With mobile page speed a confirmed ranking factor in Google’s last mobile-friendly update, and Google’s mobile-first index looming large on the horizon, it’s in the interests of developers and SEOs to optimize their mobile site speed as much as possible. That means figuring out how to trim the fat from all those huge, cumbersome images.

This column will explore the issue and causes of delays in mobile page speed (i.e. how quickly pages load on a mobile device) and how to test webpages for problems with speed.

The next column will look at methods to reduce the impact of images on the performance of your mobile pages. This includes only using images that add value and making the images you do use work harder, with an excellent case study from Unilever.

This data was sourced from the incredibly useful httpArchive, which tests the top 1 million sites several times every month:

  • The average transfer size (i.e. bites sent from server to device) of a webpage is 4.2 times larger than it was five years ago, rising from 521 Kilobyte (KB) in December 2011 to 2197KB or 2.197 megabyte (MB) in December 2016. N.B.: this measures compressed rather than original file sizes.
  • Images are a massive amount of that bloat. Total size of images sent to mobile devices has increased 4.2 times from 352KB in 2011 to 1490KB in 2016.
  • Image requests have grown from 38 to 50. JPEGs are most common, accounting for 46% of image requests.
  • By comparison, the other major contributor to page bloat is JavaScript, which has risen from 98KB to 381KB with requests rising from 8 to 21 requests. That’s 17% of total page size compared to images’ 68%.
  • The one to watch is video, which was nonexistent in 2011 websites, but now averages 110KB or 5% of total page size and takes up a gigantic 542KB per request vs 43KB for a JPEG.

Screenshot from httpArchive shows what content types account for the most bytes and the average response size of each content type.

The most shocking discovery here is that the average size of a mobile webpage, 2197KB (2.2MB) is almost as large as the average desktop webpage at 2469 KB (2.5MB) in November 2016. We can only surmise why this might be:

  • Are responsive design websites… or to be more precise inefficiently built/implemented responsive design sites to blame (because the true responsive design website is one site reformatted for different devices)?
  • Has the adoption of lazy and deferred loading techniques encouraged companies to be less efficient with total page size?

Putting things right

A note before we begin:

Web/mobile images are an imprecise science. There are no hard and fast rules – different practitioners and scenarios dictate differing course of action.

There is no best format, size, content type, design, shape, placement or number of images, but there are best practices to help you make those decisions. The rule of thumb is as small, as few, as big an impact as necessary.

“Images” are not just illustrative pictures or graphs. They also include logos and icons – but these do not necessarily need to be traditional images, such as JPEGs.

Action plan:

  1. Review your policy on images, or create one, if you don’t have one. Issue guidelines for all web content creators as well as developers.
  2. Audit the images you are using on the site. Are they adding or taking away from user experience? Can they be improved, optimized, reduced in size (on page), pushed below the fold or removed?
  3. Test how effective your images are with the users. Research/test before you make any changes, test as you pilot changes and monitor results after changing.
  4. Work out how you will balance page speed with attractiveness, quality, impact, page speed, efficiency and accessibility.

The need for speed

Robert Gaines, a Kansas, US-based, web and app developer:

Graphics are attractive and allow users to quickly grasp concepts without reading large amounts of text, however they also slow load times. Excessive use of images or the use of especially large images will slow down webpages. Slow load times annoy both readers and search engines.

The need for graphics has to be balanced against page speed. When images are used, they should be compressed and scaled so that they load more quickly. In cases where compression and scaling aren’t enough, other advanced techniques may be needed.

There is no rule for perfect speeds that a page should download to a mobile device, how could there be – mobile connections vary massively. The rule of thumb is as fast as possible. Benchmark your performance against competitors and sector leaders.

Various studies and reports, see WPO Stats for examples, have shown that improving page speed improves conversions. For example, an FT.com study found that reducing page load by 3 second on mobile led to a 9% reduction in articles read over the month.

Google warns on its TestMySite tool that “Nearly half of all visitors will leave a mobile site if the pages don’t load within 3 seconds.” But the source of this stats is unclear.

Test, test, test

Testing is critical improving to website performance and usability.

1. Test how quickly pages download

Regularly test your mobile webpages (all new ones and all the main ones). Use different services and at different times, because tests results will differ… a lot.

WebPageTest is one of the better ones, it measures speed, page size and shows what proportion of the data and requests belong to images, JavaScript etc. Some of it is a bit techie, but the excellent filmstrip showing how the site loads second by second can be understood by everyone. WebPageTest used to offer remedies also, but sadly these have disappeared.

For something less techie, use Google’s PageSpeed Insights (also try the simplified version: TestMySite – it sometimes surprises by offering a different results to its brother). N.B. Google doesn’t actually test page speed, it estimates page speed based on key criteria, but it is excellent at pointing out problems with the page.

Top issues identified by Google include problems with image size and JavaScript codes, which we know from the httpArchive’s data are the two largest contributors to data bloat.

httpArchive is different. It tests the home pages of the top 1 million websites, at regular times each month. It is based on WebPageTest. It’s brilliant for showing the breakdown of content types e.g. images and shows historical trends. Even if you are not in the top 1 million you can use it to benchmark against the big boys: individuals, top 100, top 1000, top 1 million.

For this random test, let’s pretend we are the biggest retailer in the world, and compare against the biggest online retailer:

Mobile speed test performance test for Walmart.com:

  • httpArchive – mobile page speed (January 15, 2017): 20.6 seconds. Page weight: 1941KB. 95 requests. Images: 962KB. Image requests 53.
  • WebPageTest (tested on a US-based iPhone6, cable connection, (9.00 GMT, 29-01-17) – mobile page speed: 14.3 seconds; fully loaded 17.9 seconds.
  • PageSpeed Insights – mobile speed score: 45/100 (poor).
  • Google should fix list: Optimize images. Eliminate render-blocking JavaScript and CSS in above-the-fold content.

It is important to benchmark your performance against your competitors’ sites, so let’s try Amazon.com:

  • httpArchive – speed (January 15, 2017): 6.9 seconds. Weight: 554KB. 89 requests. Images: 259KB. Image requests 49.
  • WebPageTest – speed (9.00 GMT, 29-01-17): 2.4 seconds; fully loaded 4.8 seconds.
  • PageSpeed Insights – mobile speed score: 55/100 (poor).
  • Google should fix list: Eliminate render-blocking JavaScript and CSS in above-the-fold content.

Google PageSpeed, pictured in the image below, estimates that Walmart could save 478KB (almost 0.5MB) simply by compressing the images on the page. As can be seen from the httpActive chart, this could save as much as half the image weight or one quarter of total page size.

See Google’s Guidelines for optimizing images and fixing JavaScript issues.

Screenshot from Google PageSpeed Insights showing issues with Walmart.com. Second graph from httpArchive shows what content types account for the most bytes with Walmart.com.

2. Conduct user testing

As with all aspects of web development, user testing is critical to improving site performance and usability.

  • Conduct surveys and interviews with users to discover how they use your site and any pain points with the experience.
  • Test and watch users as they interact with the website. Use eye tracking to see what catches their attention and which images work.
  • Use heatmaps and web analytics to track how users interact with webpages and where they look.

3. A/B test webpages with different images, numbers, placement, formats and sizes of images

A/B testing shows two different versions of the webpage to different groups of visitors. Compare the results to see which types of image work best.

As we will see in the next column when we look at Unilever’s work with mobile images, user testing your mobile website is hugely important, and small changes to images can deliver big differences.

 

This article is Part 1 of a three-part series on how to optimize your mobile site speed. Check back next week for Part 2, which looks at reducing the impact of images on your website’s performance.

This column was originally published on our sister site, ClickZ, and has been reproduced here for the enjoyment of our audience on SEW.

 

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedIn or Twitter at Andy_Favell.



Source link

?
WP Twitter Auto Publish Powered By : XYZScripts.com