How to make your mobile website faster

Performance testing

The first step in optimizing mobile performance is to perform performance testing. Currently, there are a lot of free and paid resources available in the industry to complete this step. However, my favorite is Google Chrome built-in developer tools and webpagetest. For the sake of simplicity, I'll use Chrome's developer tools directly in this article.

You're not a developer? It doesn't matter, this developer tool is easy to get started with:

1. Open Chrome (Of course I've already assumed you've installed Chrome)
2. Click the three-line button in the top right corner of the burger, which is a menu key
3. Select 更多工具 , Last Select开发者工具

If you're not familiar with developer tools, or just a little bit more. If you want to know more, you can read "DevTools learning". This article collects a lot of learning materials about developer tools.

Now you should already be able to see a lot of interesting information on the grid-type screen. One of the most important is the top drop-down menu, which contains many different phone and tablet emulation modes. It's so cool.

Next, choose a device of interest, such as IPhone 6. Enter the site address in the browser's address bar, enter! You can see that the site is rendered to the IPhone 6 simulator. Scroll to the bottom of the page to see a series of performance information, such as page load time, page size, and total number of requests. Click on the Network InfoBar to see the page load dynamics in the form of waterfall streams, as shown below:

Optimize mobile Images

According to this HTTP statistic, the picture probably occupies more than 60% of the total page volume. Intuitively, the picture informs the Web page. If you use Google Developer tools to check your page, I believe it will also produce similar results. When you load a picture with a slow mobile network, a large picture can seriously affect how quickly the page responds.

While solving this problem can use both lossy and lossless image optimizations, there are other considerations for mobile: Should we download images at the beginning of page loading? That desktop-side resolution up to a 1600px fine picture, if used directly on the tablet and mobile phones, even if the tablet and mobile phone is a high percentage, still seems a bit wasteful.

How to solve? Load smaller volumes of pictures for mobile users. Note: Here are 正确 the 错误 two ways to optimize.

Tip: In this example, make sure that you use viewport meta tags at the head of the page. This tag is used to inform the mobile browser that the current page is a responsive page and avoids being scaled as a desktop site to the size of the mobile screen, which is too ugly. In addition, if the label does not exist, it will get different rendering results.

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

Wrong way

Responsive design is used extensively to CSS 媒体查询 beautify the rendering results under different screen sizes, so the easiest way to switch images is as follows:

<!--DON ' T do this--<Style> @Media (min-width:376PX) {. mobile_image{Display:None } . desktop_image{Display:Inline }}@Media (max-width:375px) {. mobile_image{Display:Inline } . desktop_image{Display:None }}</ style> < IMG src= "Mobile.png" span class= "attribute" >class= "Mobile_image"/ ><img src= "Desktop.png" class= "Desktop_image"/>  

The function of this code is to display a picture of a size when the page is wide, and a picture of another size when the page is narrower.

It looks good, but it has a fatal drawback: both images will be loaded! To verify this conclusion, you can use Google Developer tools to monitor the entire loading process:

It's really bad. In fact, this is worse than before optimization! You've wasted a lot of time loading a picture that might never be used!

The right way

Conversely, when we use div the background-image Properties, we can achieve the desired optimization effect, on the code:

<!--do--<Style> @Media (min-width:376PX) {. myimage{Background-image: Url"Desktop.png"); Width: 700px; Height: 550px; }}@Media (max-width:375px) {. myimage{Background-image: Url"Mobile.png"); Width: 350px; span class= "rule" >height:  130px; span class= "rule" >}}</ style><< Span class= "title" >div class=  "myimage" ></ DIV>               

Monitor the loading process in the developer tools as follows:

From the only can be seen, only the corresponding size of the picture is loaded ... That's great! Of course, there is a point to note: for div use background-img , you need to give a definite size and height. If you face a large number of pictures, or the size of these pictures often change, then this approach is too cumbersome. But if you just apply it to a large size main diagram, you can dramatically improve responsiveness while reducing complexity.

Tip: Although this is the way to optimize the motion response speed, it is only for those with high resolution large images.

It's time to consider abandoning jQuery.

What the? You're not taking the wrong pills, are you? JQuery is a god-like existence, how dare you ignore its existence?

JQuery is really useful, and its original purpose is to provide a unified interface for many browsers that do not implement the standards of the World Wide Web, and to avoid writing various conditional statements to judge the current environment.

However, JQuery's unified interface is a bit redundant on mobile devices. The mobile side has been ruled by the WebKit kernel browser like Safari and Chrome, so there is no need to abstract the unified interface. It is a huge volume, even if it is called by the cache, you should consider abandoning it. Even after the compression and merging of JQuery, there are 30KB of the giant.

Of course, you might also want to use a simple interface like jQuery, so I suggest you use Zeptojs instead. Although it is not exactly the same as jquery, but only 5KB after compression, is one-sixth of jquery. Because Zeptojs has many interfaces with JQuery, you can also write high-quality logic operations with less code. For most of the base sites, Zepto is obviously more efficient.

Summary: Compress third-party libraries while using ZEPTOJS as the alternative to JQuery.

Review cache Configuration

Good Web Developers minimize page resource size and thus less page load times. Even better developers will try to minimize the size of the page resource at the time of the first load. This plays a major role in the browser mix. If your images, CSS, or JavaScript resources rarely change, then you should consider caching them. After caching, your users only need to load the resources once, and the cache resources will be used directly the next time they are clicked.

Here's an introductory article on page caching on Mobify: Beginners Guide to Http cache Headers. In addition, there are plenty of free tools to test cache configurations, such as cool Redbot, Woorank, and our own Zoompf. If you are using Apache or Nginx server, it is recommended mod_pagespeed to turn on to thin cache configuration. If you use WordPress, it is recommended that you use W3 total Cache as a good plugin.

Tip: Caching resources is one of the most effective performance optimization scenarios and is especially important for the mobile side. Review your cache policies and cache them for large, infrequently changed libraries and images.

Like dynamic graphs? Browsers don't think so.

Dynamic graphs have recently been revived, but this does not disguise their aging posture. Back to 30 years ago, the dynamic graph is bloated and difficult to download, especially from the movie clip of the kind of dynamic graph, it is really hard years. It is highly recommended to use HTML5 's video tags instead of the animated graphs cropped by these movies. All modern browsers support this tag, and it is only one-tenth or less of the size of a dynamic graph.

Another option is to use Imgur. When you load a dynamic diagram in Imgur, it converts it to GIFV. GIFV is essentially a HTML5 video, but is highly optimized. Imgur hosts your video and provides GIFV or GIF based on specific browser compatibility.

Tip: Try to avoid the use of dynamic graphs and complex dynamic effects. Use modern video protocols provided by HTML5 Vedio and GIFV to help boost performance and reduce load times.

Future: HTTP/2

The network transmission finally slowly developed to the HTTP/2. http/1.1 is 15 years old, and it's really a resonant old man, especially when it comes to the unreliability and instability of connecting mobile devices. HTTP/2 has been supported by many browsers and servers. While I do not recommend using HTTP/2 for mobile friendly and aggressive use on April 21, the future use of this agreement clearly deserves to be included in your roadmap. For more information, please refer to earlier articles.

Tip: Prepare for the future use of HTTP/2, this is its era!

Summarize

Creating a responsive, mobile-friendly site is more popular with Google crawlers than modifying the details of a style or label. These are the details that need to be considered by the mobile side, and if they are ignored, it can obviously seriously slow down your site response and even lose the user experience you deserve. Fortunately, we have a number of free tools available to evaluate the responsiveness of mobile sites.

Now, get started and go deep into optimization!

How to make your mobile website faster