Responsive design: now it's not about screen size
In March 2012, Guy Podjarny conducted a test that compared the productivity of hundreds of new adaptive sites on devices with four different screen resolutions. The results were quite disappointing.
After two years of the rise of adaptive design, when any designer and developer who can be imagined jumped on this train, the performance test at various resolutions shook the very foundations of adaptive theory.
Guy proved that almost all adaptive sites are overweight.
')
But, more importantly, mobile users, in the same way as desktop users, were subjected to kilobyte overload.
Representatives of the web community responded differently to this data. Some have stated that adaptive design is not a solution for all occasions and may not be sufficiently developed at the moment to cope with all the challenges that designers face today.
Fortunately, there are always people in the web community who grab the bull by the horns and turn the situation upside down.
Modern web gurus like Brad Frost, Brad Frost , Luke Wroblewski and Christian Heilmann saw opportunities where others were horrified by the crisis and were able to turn the problem around to the benefit of the community.
No offense, but performance on the web has traditionally been achieved at the expense of things that are best described by developer jargon. Terms like GZIP-ing, uglifying, minification, DNS Lookup, file-concatenation ... All these incomprehensible words take designers out of the brackets.
Smart people in the community, however, still realized that the roots of the problem lie deeper. In fact, it does not matter at all whether you are optimizing or compressing an image in ultra high resolution, if at the same time you are simply hiding it from a mobile user who must still download this image in order to view it.
To create really lightweight websites, you should not bother with performance, instead, performance should be considered as one of the design elements .
Performance is just as important as any other thing. Sites that achieve good performance results adhere to this approach from the very beginning. And those who lose sight of this, ultimately suffer from low download speeds.
There is a study, according to which, 57% of users leave your site if it loads for more than three seconds .
In the spring of 2010, Google began to consider speed when ranking sites. It does not have a big impact on the position of sites with an average download speed, but if the page does not load for a certain time, then the search algorithm applies penalties to such a site.
This proves once again that when it comes to user experience, you need to pay attention to speed.
People often talk about the rather abstract concept of Mobile Context . According to the famous theory of Google, mobile users are divided into three types:
In fact, this has nothing to do with reality. There is no "mobile context." People will use their phones while walking down the street, at home, or traveling by train. They do everything at the same time!
Telephones follow people wherever they go. Therefore, people use them absolutely everywhere.
Luke Wroblewski gives some really interesting statistics :
Where do people use mobile devices?
With the emergence of new situations, the development of new markets and the emergence of new habits in people, the mobile context will inevitably change. It is safe to assume that the concept of a mobile context will remain relevant as long as people use mobile devices.
And it makes us take a closer look at the speed of the Internet. There is only one possibility to give users a heavy website and not get problems at the same time: if the user opens it on a Macbook Pro while at home with fast internet.
However, it is necessary to provide for other situations of which there are a great many. People use to view sites an infinite number of devices appearing on the market every day.
Even in those countries where a couple of years ago there were not so many smartphones, now their number is growing at a frantic pace.
An even more important point is the places from which people will come to your site. So you will need to consider any Internet speed. It's not even that some users live in remote regions, where the quality of the coating leaves much to be desired. People will go to the site from work, where there is a 100 mb / s channel, from a house where the speed is available from 2 to 30 mb / s, via 3G and 4G and so on.
Speaking directly, responsive design is no longer a story about screen sizes , but various scenarios, solutions for which must be flexible and thought-out “from and to”.
Good thing you asked.
Above, we said that performance should not be considered as a set of automated tasks launched on the server side to save the doomed site. There are ways to overcome such problems and even turn them into competitive advantages.
Guy Podyarny identifies three main reasons for the existence of a large number of heavy adaptive sites:
There is a wealth of information on why websites do not always meet expectations in terms of performance. Most experts say something like "you need to be adaptive from the very beginning."
All the techniques that we discuss below are not new. The interesting point here is how they fit together and intertwined, smoothing the flaws and emphasizing the virtues of each other.
The meaning of this technique is to provide experience using the site on the web, which is limited only to the most important.
A couple of years ago, this theory was perceived mainly from the “browser” point of view. With the development of technologies such as HTML5, CSS3, jQuery, etc. developers seem to have forgotten about their users. Many of them created imperfect sites, relying too much on these new technologies.
Now that Webkit-based browsers, Firefox, and others have conquered more market share, another problem has emerged — a huge number of mobile devices with browsers that don’t have iPhone or Samsung capabilities. Progressive improvement is the only approach that involves, first of all, taking into account the abilities of all these forgotten players, and only then moving towards more clever devices.
In 2009, Luke Wroblewski proposed an approach to development, called Mobile First, for three reasons:
Since then, web design is constantly shifting towards this approach. Many designers and developers point out that building a mobile version of the site first gives mostly over desktop development (which illustrates the second point above very well). The progressive improvement and Mobile First approach are also well combined with each other. Developers are starting to create a site for mobile devices, gradually improving it, adding larger resolutions to the initially small screen size.
Jordan Moore has put together an excellent list of reasons for using Mobile First. He argues that due to the fact that you cannot fully rely on the connection speed, the “adaptive web designer” has to start working from the lowest entry point - the mobile version of the site, assuming a low connection speed, and moving in development in stages to a larger breakpoints for faster connection. In the future, we will be able to rely on a high connection speed, but for now it is worth taking for granted the poor quality of communication and not taking rash steps.
Develop a site with the expectation of small permissions and opportunities. Use the technique of progressive improvement from the beginning. Add extra functionality, improved visual effects and ways to interact where it makes sense.
According to many people, responsive design has one big disadvantage - it depends entirely on determining the width of the screen.
With the advent of more and more types of devices, including hybrids like notebooks with touchscreens, determining the resolution of the screen has become an extremely important thing in adaptive design. The libraries that provide this functionality (mainly Modernizr ) have literally bloomed and are now used in most projects. They help developers to understand whether the user's browser supports this or that functionality and, accordingly, to provide it. But in many cases, relying on browsers is not the best idea, because, often, they can only support some functions in part, while “declaring” full support.
To solve this problem, RESS was created. Like Mobile First, the term RESS was formed by Luke Wroblewski in 2011. It is based on determining the type of device, its evaluation and providing an associated user experience. To accomplish this task, there are heavy tools like WURFL , DeviceAtlas and lighter ones, such as Browser Gem , that read the User Agent line and act on this information.
Evaluation of the type of device has other advantages. It allows developers to use different site templates depending on the user's device. Let's say you create a very large site and want to simplify mobile navigation. You can “play with content”, showing or hiding something, move divs by JavaScript code or use different templates for mobile and desktop versions of the site, the need to display which is determined by the server.
BBC representatives talk about how RESS and progressive improvement could work separately. The approach is called Cut the Mustard! It consists in creating a basic version of the site that will work on any device. The device is then evaluated by the server to determine if it is cutting mustard. If the answer is yes, then an improved version of the site is used. If the device does not have the necessary parameters, the user still sees the main content.
Consider a couple of points of view:
1) Mobile users want content , as much as desktop users.
2) Mobile environment forces focus. There are certain limitations (such as connection speed or screen size) that designers need to accept in order to provide the same content equally well.
This technique, also called “Aggressive Improvement,” allows designers to focus on key content and progressively improve it for larger screens. It implies a basic access to certain content, which can then be added to the page when a place appears.
You can use the excellent MatchMedia tool, which emulates CSS behavior and evaluates screen size in JavaScript.
Sites that are heavy in appearance and use (Facebook, Twitter, Pinterest), when they need optimization for a mobile environment, resort to using lazy loading techniques to provide a better user experience. When you upload a page for the first time, a certain number of posts are loaded. When you scroll down the page, the designer assumes that you want to see more content, so that is inserted into the page using Ajax. This allows you to significantly speed up page loading and avoid DOM redundancy.
Tim Kadlec argues that setting the maximum page weight and controlling this indicator is the main way to reduce page load time . "Set goals and strive for them." Steve Souders offers a choice of three options if you have already exceeded your budget:
It sounds pretty radical, but this approach allows you to focus on how the overall performance of the site affects each new feature.
In addition, there are a number of methods that work at a more technical and less conceptual level.
Web sites are approximately 60% images. And if you show mobile users with an unknown connection speed of a desktop-sized picture, you doom your website to problems with download speeds.
The way to solve this problem is to show different versions of the images depending on the screen size or the type of device. Thus, you will show a small image when entering the site from a mobile phone, a high-resolution picture to the desktop user and another twice as large image in the case of a HiDPI device.
Designers and developers around the world have been struggling to include responsive images in the HTML specification. Mat 'Wilto' Marquis is one of the most prominent proponents of this idea. The battle has not yet been won , but JavaScript solutions have emerged that help to achieve the desired result.
Scott Jehl , from the Filament Group, wrote a plugin that mimics the markup suggested by the community and works great: this is PictureFill .
Dutch designer Daan Jobsis discovered a very strange phenomenon when compressing images in Photoshop. He managed to carry out the following sequence of actions: he took the image, doubled its size (200%), squeezed it to 25% or less of its original quality, then restored the size of the image in the browser to its original value (100%). As a result, the image not only became lighter, but was initially optimized for HiDPI screens, due to the duplication of pixel density.
The only problem found here is that it can be difficult for the browser to render a doubled image at its original size (especially if it needs to be done hundreds of times, in the case of sites with a large number of media content). To make sure that this solution is optimal, it is necessary to spend time on testing.
An excellent choice is SVG images. They are fully scalable, so they work well on any screen. Implementing a fallback in this case will be very easy with the help of Modernizr.
Technically, they are actually vector images, only represented in the form of a font. As Chris Coyier says, “The icon fonts are amazing” because:
Dave Bushell recently wrote a very interesting article with reflections on HiDPI images . He argues that, even though today we can show users of iPhone, iPad or other modern devices images that match the capabilities of these devices, it is still too early to assume that this will not harm the site.
Recently, Google has developed a new image format - WebP . It provides the ability to compress images without loss, which allows you to get three times smaller files, compared to PNG.
Today, there are simple and easy JavaScript libraries with which you can convert images to and from the WebP format. Considering the impact of the latest Google products, it is quite possible that now it can be a good idea to start experimenting with WebP to improve the performance of sites with a large number of images.
Load items neatly and in order. Controlling this aspect has great advantages, allowing the page to first display the basic content and then improve it.
Control loading using media query, conditional or lazy loading, and use adaptive / compressed image techniques.
Use HTML5 features like async or defer. In addition, there are some “boot helpers” such as RequireJS , which can control downloads and dependencies.
Just paste them on the page after loading .
They are known for a long time, but still work well.
Reduce the number of HTTP requests
To achieve this, developers need to make an effort, but there are a number of ways to achieve this:
Reduce the number of bytes.
Minify each script or CSS file that is called from the page. Configure GZIP-compression / expansion on the server and apply them to all elements.
Since the birth of responsive design, the importance of performance on the web has been greatly exaggerated.
Designers and developers focus on assembling an adaptive puzzle, the elements of which began to be different speeds of access to the network, many different devices, different locations of users.
To prepare for the problems of tomorrow, we need to pay a lot of attention to performance, because the desktop-oriented web disappears right before our eyes. The mobile user is fast, easy and will not overcome obstacles to accessing content, and, given that the number of sites is increasing every day, being fast means being ahead .
PS Notes on translation are accepted in lichku.
PPS We also started posting digests of interesting publications of the world of usability and UX on our blog. Suddenly, anyone interested.
After two years of the rise of adaptive design, when any designer and developer who can be imagined jumped on this train, the performance test at various resolutions shook the very foundations of adaptive theory.
Guy proved that almost all adaptive sites are overweight.
')
"We made the Internet in its own image ... hard," - Jason Grigsby.
But, more importantly, mobile users, in the same way as desktop users, were subjected to kilobyte overload.
Representatives of the web community responded differently to this data. Some have stated that adaptive design is not a solution for all occasions and may not be sufficiently developed at the moment to cope with all the challenges that designers face today.
Fortunately, there are always people in the web community who grab the bull by the horns and turn the situation upside down.
Modern web gurus like Brad Frost, Brad Frost , Luke Wroblewski and Christian Heilmann saw opportunities where others were horrified by the crisis and were able to turn the problem around to the benefit of the community.
“If your site weighs 15MB, then this is not HTML5. This is nonsense. ”- Christian Heilmann
No offense, but performance on the web has traditionally been achieved at the expense of things that are best described by developer jargon. Terms like GZIP-ing, uglifying, minification, DNS Lookup, file-concatenation ... All these incomprehensible words take designers out of the brackets.
Smart people in the community, however, still realized that the roots of the problem lie deeper. In fact, it does not matter at all whether you are optimizing or compressing an image in ultra high resolution, if at the same time you are simply hiding it from a mobile user who must still download this image in order to view it.
“Good performance is good design,” Brad Frost.
To create really lightweight websites, you should not bother with performance, instead, performance should be considered as one of the design elements .
Performance is just as important as any other thing. Sites that achieve good performance results adhere to this approach from the very beginning. And those who lose sight of this, ultimately suffer from low download speeds.
“Performance is respect. Respect your users and they will come back again, ”- Brad Frost.
Why it happens
Bounce rate
There is a study, according to which, 57% of users leave your site if it loads for more than three seconds .
Google, Page Speed ​​& SEO
In the spring of 2010, Google began to consider speed when ranking sites. It does not have a big impact on the position of sites with an average download speed, but if the page does not load for a certain time, then the search algorithm applies penalties to such a site.
This proves once again that when it comes to user experience, you need to pay attention to speed.
Speed ​​considerations
People often talk about the rather abstract concept of Mobile Context . According to the famous theory of Google, mobile users are divided into three types:
- Repetitive Now : people who use their phones to keep up to date with continuous, repetitive changes (sports results, Facebook updates, stock dynamics in the stock market).
- Bored Now : Users who access the phone while waiting for an event.
- Urgent Now
It looks like the truth, is not it?
In fact, this has nothing to do with reality. There is no "mobile context." People will use their phones while walking down the street, at home, or traveling by train. They do everything at the same time!
Telephones follow people wherever they go. Therefore, people use them absolutely everywhere.
“Mobile context is an important thing, but first you need to understand what the hell it really is,” Tim Kadlec.
Luke Wroblewski gives some really interesting statistics :
Where do people use mobile devices?
- 84% home
- 80% free time during the day
- 76% in queues and waiting
- 69% in the shopping process
- 64% at work
- 62% while watching TV programs (alternative studies give a figure of 84%)
- 47% during preparation for work
With the emergence of new situations, the development of new markets and the emergence of new habits in people, the mobile context will inevitably change. It is safe to assume that the concept of a mobile context will remain relevant as long as people use mobile devices.
And it makes us take a closer look at the speed of the Internet. There is only one possibility to give users a heavy website and not get problems at the same time: if the user opens it on a Macbook Pro while at home with fast internet.
However, it is necessary to provide for other situations of which there are a great many. People use to view sites an infinite number of devices appearing on the market every day.
“You cannot know from which devices your site will be viewed. This is decided by users ", - Karen McGrane.
Even in those countries where a couple of years ago there were not so many smartphones, now their number is growing at a frantic pace.
“If your materials, content, information, products, services are not available in a mobile environment, then for these people they do not exist at all”, - Karen McGrane.
An even more important point is the places from which people will come to your site. So you will need to consider any Internet speed. It's not even that some users live in remote regions, where the quality of the coating leaves much to be desired. People will go to the site from work, where there is a 100 mb / s channel, from a house where the speed is available from 2 to 30 mb / s, via 3G and 4G and so on.
Speaking directly, responsive design is no longer a story about screen sizes , but various scenarios, solutions for which must be flexible and thought-out “from and to”.
And How?
Good thing you asked.
Above, we said that performance should not be considered as a set of automated tasks launched on the server side to save the doomed site. There are ways to overcome such problems and even turn them into competitive advantages.
What to avoid
Guy Podyarny identifies three main reasons for the existence of a large number of heavy adaptive sites:
- Load and concealment: a large number of items are loaded, but not shown to the user.
- Download and trim: high resolution images are loaded and then trimmed to fit the custom screen
- Redundant DOM: there is no way to avoid parsing and browser processing of all DOM zones, including hidden
Proactive approach
There is a wealth of information on why websites do not always meet expectations in terms of performance. Most experts say something like "you need to be adaptive from the very beginning."
All the techniques that we discuss below are not new. The interesting point here is how they fit together and intertwined, smoothing the flaws and emphasizing the virtues of each other.
Progressive improvement
The meaning of this technique is to provide experience using the site on the web, which is limited only to the most important.
A couple of years ago, this theory was perceived mainly from the “browser” point of view. With the development of technologies such as HTML5, CSS3, jQuery, etc. developers seem to have forgotten about their users. Many of them created imperfect sites, relying too much on these new technologies.
Now that Webkit-based browsers, Firefox, and others have conquered more market share, another problem has emerged — a huge number of mobile devices with browsers that don’t have iPhone or Samsung capabilities. Progressive improvement is the only approach that involves, first of all, taking into account the abilities of all these forgotten players, and only then moving towards more clever devices.
Mobile First Development
In 2009, Luke Wroblewski proposed an approach to development, called Mobile First, for three reasons:
- The mobile market continues to grow at a frantic pace.
- The mobile environment forces you to focus (allowing you to get rid of the confusion caused by too much screen space).
- Mobile environment expands your capabilities (thanks to technologies like GPS, geolocation, multi-touch gestures, accelerometer, cameras).
Since then, web design is constantly shifting towards this approach. Many designers and developers point out that building a mobile version of the site first gives mostly over desktop development (which illustrates the second point above very well). The progressive improvement and Mobile First approach are also well combined with each other. Developers are starting to create a site for mobile devices, gradually improving it, adding larger resolutions to the initially small screen size.
Jordan Moore has put together an excellent list of reasons for using Mobile First. He argues that due to the fact that you cannot fully rely on the connection speed, the “adaptive web designer” has to start working from the lowest entry point - the mobile version of the site, assuming a low connection speed, and moving in development in stages to a larger breakpoints for faster connection. In the future, we will be able to rely on a high connection speed, but for now it is worth taking for granted the poor quality of communication and not taking rash steps.
Conclusion
Develop a site with the expectation of small permissions and opportunities. Use the technique of progressive improvement from the beginning. Add extra functionality, improved visual effects and ways to interact where it makes sense.
RESS: Responsive Web design + Server Side components
According to many people, responsive design has one big disadvantage - it depends entirely on determining the width of the screen.
With the advent of more and more types of devices, including hybrids like notebooks with touchscreens, determining the resolution of the screen has become an extremely important thing in adaptive design. The libraries that provide this functionality (mainly Modernizr ) have literally bloomed and are now used in most projects. They help developers to understand whether the user's browser supports this or that functionality and, accordingly, to provide it. But in many cases, relying on browsers is not the best idea, because, often, they can only support some functions in part, while “declaring” full support.
To solve this problem, RESS was created. Like Mobile First, the term RESS was formed by Luke Wroblewski in 2011. It is based on determining the type of device, its evaluation and providing an associated user experience. To accomplish this task, there are heavy tools like WURFL , DeviceAtlas and lighter ones, such as Browser Gem , that read the User Agent line and act on this information.
Evaluation of the type of device has other advantages. It allows developers to use different site templates depending on the user's device. Let's say you create a very large site and want to simplify mobile navigation. You can “play with content”, showing or hiding something, move divs by JavaScript code or use different templates for mobile and desktop versions of the site, the need to display which is determined by the server.
BBC representatives talk about how RESS and progressive improvement could work separately. The approach is called Cut the Mustard! It consists in creating a basic version of the site that will work on any device. The device is then evaluated by the server to determine if it is cutting mustard. If the answer is yes, then an improved version of the site is used. If the device does not have the necessary parameters, the user still sees the main content.
Conditional loading
“Mobile users want to see our menu, opening hours and phone delivery. Desktop users want to see a picture of 1 mb, on which someone laughs in a salad, ”- Mat“ Wilto ”Marquis .
Consider a couple of points of view:
1) Mobile users want content , as much as desktop users.
“If your content is accessible via a URL, then it will definitely be viewed from mobile devices,” - Brad Frost.
2) Mobile environment forces focus. There are certain limitations (such as connection speed or screen size) that designers need to accept in order to provide the same content equally well.
This technique, also called “Aggressive Improvement,” allows designers to focus on key content and progressively improve it for larger screens. It implies a basic access to certain content, which can then be added to the page when a place appears.
“Perhaps a more precise definition of conditional loading will be called its content-first approach. In this case, sidebars or numerous columns with beautiful but non-functional content is a luxury that is unavailable to you, ”- Jeremy Keith.
You can use the excellent MatchMedia tool, which emulates CSS behavior and evaluates screen size in JavaScript.
Lazy loading
Sites that are heavy in appearance and use (Facebook, Twitter, Pinterest), when they need optimization for a mobile environment, resort to using lazy loading techniques to provide a better user experience. When you upload a page for the first time, a certain number of posts are loaded. When you scroll down the page, the designer assumes that you want to see more content, so that is inserted into the page using Ajax. This allows you to significantly speed up page loading and avoid DOM redundancy.
Set performance budget
Tim Kadlec argues that setting the maximum page weight and controlling this indicator is the main way to reduce page load time . "Set goals and strive for them." Steve Souders offers a choice of three options if you have already exceeded your budget:
- Optimize an existing function or item
- Delete an existing function or item
- Avoid adding a new feature or item
It sounds pretty radical, but this approach allows you to focus on how the overall performance of the site affects each new feature.
In addition, there are a number of methods that work at a more technical and less conceptual level.
Imaging Techniques
Web sites are approximately 60% images. And if you show mobile users with an unknown connection speed of a desktop-sized picture, you doom your website to problems with download speeds.
The way to solve this problem is to show different versions of the images depending on the screen size or the type of device. Thus, you will show a small image when entering the site from a mobile phone, a high-resolution picture to the desktop user and another twice as large image in the case of a HiDPI device.
Adaptive Images
Designers and developers around the world have been struggling to include responsive images in the HTML specification. Mat 'Wilto' Marquis is one of the most prominent proponents of this idea. The battle has not yet been won , but JavaScript solutions have emerged that help to achieve the desired result.
Scott Jehl , from the Filament Group, wrote a plugin that mimics the markup suggested by the community and works great: this is PictureFill .
Image compression
Dutch designer Daan Jobsis discovered a very strange phenomenon when compressing images in Photoshop. He managed to carry out the following sequence of actions: he took the image, doubled its size (200%), squeezed it to 25% or less of its original quality, then restored the size of the image in the browser to its original value (100%). As a result, the image not only became lighter, but was initially optimized for HiDPI screens, due to the duplication of pixel density.
The only problem found here is that it can be difficult for the browser to render a doubled image at its original size (especially if it needs to be done hundreds of times, in the case of sites with a large number of media content). To make sure that this solution is optimal, it is necessary to spend time on testing.
Vector vs raster images
An excellent choice is SVG images. They are fully scalable, so they work well on any screen. Implementing a fallback in this case will be very easy with the help of Modernizr.
Icon Fonts
Technically, they are actually vector images, only represented in the form of a font. As Chris Coyier says, “The icon fonts are amazing” because:
- Easy to resize them
- Easy to change their color.
- Easy to shade the shape of the font
- They work in IE6, in contrast to transparent PNGs.
- You can do the same with them as with the images.
- They provide unlimited room for typography.
HiDPI images
Dave Bushell recently wrote a very interesting article with reflections on HiDPI images . He argues that, even though today we can show users of iPhone, iPad or other modern devices images that match the capabilities of these devices, it is still too early to assume that this will not harm the site.
“Does high speed and high pixel density mean that users want better quality images? In the case of a packet tariff with a limit on the number of gigabytes, it is unlikely, "- Dave Bushell.
What's next?
Recently, Google has developed a new image format - WebP . It provides the ability to compress images without loss, which allows you to get three times smaller files, compared to PNG.
Today, there are simple and easy JavaScript libraries with which you can convert images to and from the WebP format. Considering the impact of the latest Google products, it is quite possible that now it can be a good idea to start experimenting with WebP to improve the performance of sites with a large number of images.
Loading items
Load items neatly and in order. Controlling this aspect has great advantages, allowing the page to first display the basic content and then improve it.
CSS, images
Control loading using media query, conditional or lazy loading, and use adaptive / compressed image techniques.
Javascript
Use HTML5 features like async or defer. In addition, there are some “boot helpers” such as RequireJS , which can control downloads and dependencies.
Advertising, social widgets and third-party items
Just paste them on the page after loading .
Old School Performance Techniques
They are known for a long time, but still work well.
Reduce the number of HTTP requests
To achieve this, developers need to make an effort, but there are a number of ways to achieve this:
- Use concatenation for all CSS files or use CSS Preprocessors to compile them into one file.
- Combine JS plugins in the same file and always load them in the footer, unless they really need to block rendering of the page (if you download Typekit fonts in the footer, you will get the famous FOUT effect or “ Explosion of non-stylized text ”).
- If you need to work with PNG-images, use sprites. They combine all the images into one and use CSS to cut it into pieces.
- If possible, use the URL data scheme ( rus , eng ), which will allow you to include images as line data and further reduce the number of HTTP headers.
Reduce the number of bytes.
Minify each script or CSS file that is called from the page. Configure GZIP-compression / expansion on the server and apply them to all elements.
Conclusion
Since the birth of responsive design, the importance of performance on the web has been greatly exaggerated.
Designers and developers focus on assembling an adaptive puzzle, the elements of which began to be different speeds of access to the network, many different devices, different locations of users.
To prepare for the problems of tomorrow, we need to pay a lot of attention to performance, because the desktop-oriented web disappears right before our eyes. The mobile user is fast, easy and will not overcome obstacles to accessing content, and, given that the number of sites is increasing every day, being fast means being ahead .
You might also like [en] ...
- 20 jQuery plugins for images and multimedia .
- 20 lessons on plug-in replacement, tips, snippets and WordPress solutions .
- 50 free tools and applications for web designers and developers .
- 3 0 fantastic new jQuery plugins .
- What license do you choose for your code ?
- 20 CSS3 tutorial and button creation techniques.
PS Notes on translation are accepted in lichku.
PPS We also started posting digests of interesting publications of the world of usability and UX on our blog. Suddenly, anyone interested.
Source: https://habr.com/ru/post/196204/
All Articles