Nothing pisses me off faster than a slow website. By the time the page loads, my patience is gone & I don't wanna buy it anymore.
— mrs always right △⃒⃘ (@mommarazzi_) March 23, 2016
Just because no one uses your mobile site, doesn't mean you don't need to improve it. Maybe no one uses it because the experience is awful.
— Dawn Parzych (@dparzych) March 18, 2016
Our report found some big changes in the past year on how audiences access BBC News Online: pic.twitter.com/8zYSoYmP5D
— BBC Trust Info (@bbctrust) April 29, 2014
"The principles of universality of access irrespective of hardware or software platform, network infrastructure, language, culture, geographical location, or physical or mental impairment are core values in Web design"
— Tim Berners-Lee, Sept. 1998
<meta name="viewport" content="width=device-width, user-scalable=yes">
@viewport { viewport-properties }
Specifies:
Resource: A tale of 2 viewports
Tutorial: Media Queries slide deck
<meta name="viewport" content="initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no, width=device-width">
<meta name="viewport" content="width=device-width, user-scalable=yes, initial-scale=1">
I remember when 3G was primary mobile speed. It was slow but still worked, so why now when my phone says 3G it becomes completely useless.
— Stephen Gundee (@StephenGundee) March 23, 2016
Wide / Desktop | Narrow / Mobile | |
---|---|---|
Requests | 77 | 123 |
Assets | 3752kB | 3344kB |
Load | 10.62s | 34.10s |
DOMContentLoaded | 9.74s | 30.94s |
desktop stats | mobile stats |
According to the HTTP Archive, the average top 1,000 web page is 2,123 KB, compared to 626 KB in 2010.
HTTPArchive
Images: 1253 KB v. 372 KB
JS: 425 KB v. 103 KB
CSS: 64KB v. 24KB
Desktop/WiFi | Mobile/Network | |
---|---|---|
Requests | 147 | 173 |
Assets | 2.6 MB | 3.0 MB |
Load | 4.27s | 34.21s |
DOMContentLoaded | 1.66s | 6.91s |
WebPageTest | WebPageTest |
Desktop/WiFi | Mobile/Network | |
---|---|---|
Requests | 341 | 196 |
Assets | 5,208 kB | 3,023 kB |
Load | 22.7s | 34.9s |
WebPageTest | WebPageTest | |
HTTPArchive | HTTPArchive |
2014: UA sniffing / different experiences:
Desktop: 86 requests/1.9 MB
Mobile: 89 requests/2.0 MB
Youtube Feathers:
Regular: 58 requests/1200 kB
Feathers: 14 requests/100 kB
By keeping your client side code small and lightweight, you can literally open your product up to new markets.
Just because no one visits your mobile site doesn't mean you don't need to improve it. Maybe no one uses it because its too slow.
— Estelle Weyl (@estellevw) October 16, 2015
Speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it...
There is real empirical evidence that substantiates the fact that speed is more than a feature. It’s a requirement.
Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Some ways to reduce the number of components include: combine files, combine multiple scripts into one script, combine multiple CSS files into one style sheet, and use CSS Sprites and image maps.
You may expect a browser to do nothing when it encounters an empty image src. However, it is not the case in most browsers. IE makes a request to the directory in which the page is located; Safari, Chrome, Firefox 3 and earlier make a request to the actual page itself. This behavior could possibly corrupt user data, waste server computing cycles generating a page that will never be viewed, and in the worst case, cripple your servers by sending a large amount of unexpected traffic.
Compression reduces response times by reducing the size of the HTTP response. Gzip is the most popular and effective compression method currently available and generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip.
Moving style sheets to the document HEAD element helps pages appear to load quicker since this allows pages to render progressively.
JavaScript scripts block parallel downloads; that is, when a script is downloading, the browser will not start any other downloads. To help the page load faster, move scripts to the bottom of the page if they are deferrable.
The Domain Name System (DNS) maps hostnames to IP addresses, just like phonebooks map people's names to their phone numbers. When you type URL www.yahoo.com into the browser, the browser contacts a DNS resolver that returns the server's IP address. DNS has a cost; typically it takes 20 to 120 milliseconds for it to look up the IP address for a hostname. The browser cannot download anything from the host until the lookup completes.
Minification removes unnecessary characters from a file to reduce its size, thereby improving load times. When a file is minified, comments and unneeded white space characters (space, newline, and tab) are removed. This improves response time since the size of the download files is reduced.
URL redirects are made using HTTP status codes 301 and 302. They tell the browser to go to another location. Inserting a redirect between the user and the final HTML document delays everything on the page since nothing on the page can be rendered and no components can be downloaded until the HTML document arrives.
Duplicate JavaScript and CSS files hurt performance by creating unnecessary HTTP requests (IE only) and wasted JavaScript execution (IE and Firefox). In IE, if an external script is included twice and is not cacheable, it generates two HTTP requests during page loading. Even if the script is cacheable, extra HTTP requests occur when the user reloads the page. In both IE and Firefox, duplicate JavaScript scripts cause wasted time evaluating the same scripts more than once. This redundant script execution happens regardless of whether the script is cacheable.
A complex page means more bytes to download, and it also means slower DOM access in JavaScript. Reduce the number of DOM elements on the page to improve performance.
Making an HTTP request and receiving a 404 (Not Found) error is expensive and degrades the user experience. Some sites have helpful 404 messages (for example, "Did you mean ...?"), which may assist the user, but server resources are still wasted.
Web page designers sometimes set image dimensions by using the width and height attributes of the HTML image element. Avoid doing this since it can result in images being larger than needed. For example, if your page requires image myimg.jpg which has dimensions 240x720 but displays it with dimensions 120x360 using the width and height attributes, then the browser will download an image that is larger than necessary.
A favicon is an icon associated with a web page; this icon resides in the favicon.ico file in the server's root. Since the browser requests this file, it needs to be present; if it is missing, the browser returns a 404 error (see "Avoid HTTP 404 (Not Found) error" above). Since favicon.ico resides in the server's root, each time the browser requests this file, the cookies for the server's root are sent. Making the favicon small and reducing the cookie size for the server's root cookies improves performance for retrieving the favicon. Making favicon.ico cacheable avoids frequent requests for it.
CSS expressions (supported in IE beginning with Version 5) are a powerful, and dangerous, way to dynamically set CSS properties. These expressions are evaluated frequently: when the page is rendered and resized, when the page is scrolled, and even when the user moves the mouse over the page. These frequent evaluations degrade the user experience.
The IE-proprietary AlphaImageLoader filter attempts to fix a problem with semi-transparent true color PNG files in IE versions less than Version 7. However, this filter blocks rendering and freezes the browser while the image is being downloaded. Additionally, it increases memory consumption. The problem is further multiplied because it is applied per element, not per image.
It's more than just making them squishy!
display: none;
on parent of background image<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 300 329" preserveAspectRatio="xMidYMid meet"> <title>Clown Car</title> <style> svg { background-size: 100%; background-repeat: no-repeat; } @media screen and (max-width: 300px) { svg {background-image: url(images/small.png); } } @media screen and (min-width: 301px) and (max-width: 600px) { svg {background-image: url(images/medium.png); } } @media screen and (min-width: 601px) and (max-width: 900px) { svg {background-image: url(images/big.png); } } @media screen and (min-width: 901px) { svg {background-image: url(images/huge.png); } } </style> </svg>
Resource: Clown Car Technique
<picture>, <source> & srcset
<picture> <source srcset="large.jpg" media="(min-width: 1000px)"> <source srcset="small.jpg" media="(min-width: 500px)"> <img src="default.jpg" srcset="highresolution.jpg 2x" alt="do not forget the alt"> </picture>
Scaled: 1,850 milliseconds
Right-sized: 625 milliseconds
auto | cover | contain |
---|---|---|
44ms | 182ms | 203ms |
240 x 240 = 57,600 200 x 200 = 40,000 17,600
440 x 440 = 193,600 400 x 400 = 160,000 33,600
640 x 640 = 409,600 600 x 600 = 360,000 49,000
840 x 840 = 705,600 800 x 800 = 640,000 65,600
Scaled: 1,850 milliseconds
Right-sized: 625 milliseconds
Is your battery draining too fast? Turn off everything that makes your smart phone smart. That'll fix it.
— Scott Hanselman (@shanselman) May 4, 2014
If your web app makes your laptop fan go crazy, imagine what your app is doing to the batteries and CPU of your mobile visitors.
— Estelle Weyl (@estellevw) October 18, 2015
CPU Drains the battery. Avoid using it!
requestAnimationFrame
(not setInterval
or setTimeout
)Device | Memory | |
---|---|---|
iPhone 3G | 128MB | |
iPhone 3GS | 256 MB | |
iPhone 5/5S/6 | 1 GB | |
HTC Inspire | 768 MB | |
iPad 1 | 256 MB | |
iPad 3/4 | 1 GB | |
iPod Touch (4) | 256 MB | |
Samsung Galaxy Note Edge | 3GB | |
Intex Cloud FX | 128 MB | |
MacBook Pro | 16 GB |
Running Services | ||
Other | 73MB Avail: 255MB + 182MB in 21 | |
Calendar | 8.4MB | |
Process:com.htc.bgp | ||
ObexService | 31:52:14 | |
Started by application: Touch to stop | ||
AT&T Navigator | 8.4MB | |
Process: com.telnav.app.android.congular | ||
ResoucePreLoader | Restarting | |
Started by application: Touch to stop | ||
AT&T Spots | 2.4MB | |
Process: com.matchboxmobile.wasp | ||
WispService | 31:52:14 | |
Started by application: Touch to stop | ||
Media | 4.1MB | |
Process: android.process.media | ||
DownloadService | 31:52:14 | |
Started by application: Touch to stop | ||
PVWmdrmService | 2.2MB | |
Process: com.pv.wmdrmservice | ||
PVWmdrmService | 31:52:14 | |
Started by application: Touch to stop |
More nodes = more expensive!
Load times on mobile have improved drastically by moving from client-side to server-side JavaScript logic for injecting content. #nodejs ❤
— Web Platform Daily (@openwebdaily) April 21, 2014
el.addEventListener('click', myFunction); el.addEventListener('touchend', myFunction);*
<meta name="viewport" content="width=device-width; initial-scale=1; maximum-scale=1;">
Good design is not about making something pretty. It is about making something usable and intuitive – the beauty of the product will be a result of these things.
-- Luke Jones