What's the difference between a fast and slow website?
Is there a correct answer?
No, unfortunately, not yet. The reason for this is that there are many factors on the site, and each of these factors can slow down the site. Therefore, this article will not give you a list of what needs to be done, but rather to explain how some factors slow down the site and what you can do accordingly.
As the proverb says:
To give a
man a fish is better to give it to a fish than a man to save a moment, and to give a man a fishing can solve his life's need.
In addition to allowing you to add "async" tags to your scripts, or to layout pages in a specific order, I'm going to explain the differences that these changes bring. This way, you will be able to toss your application and confirm which modifications are useful.
650) this.width=650; "Src=" http://mmbiz.qpic.cn/mmbiz/ vqlbvfl5jn0cbzzvypv1jgdeliokcm8iafgcdiagqrgeswmb4munjuuazqpan8xzfkzq6675dv3vacqx93eicrliaa/640?wx_fmt=png& Tp=webp&wxfrom=5&wx_lazy=1 "style=" margin:0px 0px-.46em. 26em;padding:0px;height:auto;vertical-align: Middle, "alt=" 640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy= "/>650" this.width=650; "src=" http:/ mmbiz.qpic.cn/mmbiz/vqlbvfl5jn0cbzzvypv1jgdeliokcm8iajsgehwkaztfxzh95sk2xdq6p3gdpjs1fhbicxvjyhaf3yv91n4xxuyq/ 640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1 "style=" margin:0px. 3em 0px 0px;padding:0px;height:auto; Vertical-align:middle; "alt=" 640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy= "/>
One
Accelerated page Loading
As I have just mentioned, there is no such thing. The web is somewhat surprisingly complex. The slow loading of pages may not be the right standard for you to focus on!
However, there are some fairly important factors that often lead to obvious differences. You may have met before, but you may not understand why they are important. 1 compression Transfers HTML, CSS, and JavaScript with gzip compression, reducing the number of bytes that need to flow through the cable. This can significantly reduce the time it takes to download resources. The browser renders the page without HTML and CSS, so we want to download these resources as soon as possible. 2 picture optimization I have a friend, he set up WordPress site for customers, there are many sites often upload a lot of pictures, I recently chatted with him. He was confronted with a problem that the customer directly uploaded the pictures in the camera to their website.
More than 1MB of photos were taken by mobile phones. Even if you resize with CSS, you still need to download this very large picture from the cable. Users with slow speeds need to wait a long time to open.
To understand how to cope, we strongly recommend a program to optimize the picture, see: Https://scaleyourcode.com/interviews/interview/19.
3 Do not transfer unnecessary east to see the different pages of the script and CSS files, ask yourself, these files for the page is not really necessary. You'll probably find some files that have been added to it and haven't been removed.
The plug-in's performance in this respect is really bad. Quite a few of my Contacts ebordpress Web site, loaded with a lot of CSS files, half of which files in some pages are not used at all! Many non-WordPress sites also have similar phenomena. When I checked some of the pages on scaleyourcode.com earlier, I also found that they were loading an unnecessary script.
Erasing a script or style sheet can be scary. What if it's really necessary for that page, but you don't remember? There are some tools that can help us confirm and recommend DevTools (under audits).
Can you see the similarities between these optimizations? They all reduce the number of bytes we need to transfer. Two
Progressive rendering
You need to give the HTML bytes to the browser as soon as possible.
For example: A request comes in and (ideally) your data is cached so the server can get it quickly. The browser then starts parsing the data and renders it on the screen.
As I mentioned earlier, page loading times may not be the performance criteria you need to focus on, thanks to progressive rendering.
650) this.width=650; "Src=" http://mmbiz.qpic.cn/mmbiz/ Vqlbvfl5jn0cbzzvypv1jgdeliokcm8iajibwjvyw28gepimuibmmyerspreia616mibmwy8epnia42szjdeipvhogmq/640?wx_fmt=png &tp=webp&wxfrom=5&wx_lazy=1 "style=" margin:0px;padding:0px;height:auto;width:646.205px; "alt=" 640?wx _fmt=png&tp=webp&wxfrom=5&wx_lazy= "/>
Progressive Rendering
The page can be huge, but as long as you're presenting something to the user in a short period of time (preferably less than 1 seconds), they still feel loaded quickly.
Amazon has done a good job in this area:
incremental rendering for Amazon
For this webpagetest, you get the first screen in 1.5 seconds, but you can see that it doesn't contain all the content. It contains enough content to start browsing the page, or to view holiday transactions.
Then, to 3.5 seconds, the other part loads more deals. To 6.5 seconds, some things are still loading! In fact, the completion of the entire page load lasts until 18 seconds. Can you wait that long? I doubt that!
If Amazon is focused on the slowest page loading, someone must be irritated. They are focused on sending the most important bytes in the earliest packet. Further, they may fill the first packet with the most important bytes. I bet they're also focused on sending you those bytes as soon as possible.
This is the origin of TTFB (time to first Byte).
When a browser initiates a page request, it is in a state of waiting for a response. TTFB represents how long it takes to receive the first byte of a response. This time not only represents the time it takes for your server to generate a response, it also means the time it takes to transfer the cable.
650) this.width=650; "Src=" http://mmbiz.qpic.cn/mmbiz/ Vqlbvfl5jn0cbzzvypv1jgdeliokcm8iawx5kflfqqptuekgdiappnnhicxme3puizibsovshld1ivpx5ioqgwial4g/640?wx_fmt=jpeg &tp=webp&wxfrom=5&wx_lazy=1 "style=" margin:0px;padding:0px;height:auto;width:646.205px; "alt=" 640?wx _fmt=jpeg&tp=webp&wxfrom=5&wx_lazy "/>
This picture has a very fast TTFB. If you go online, you can see different TTFB, and you see things like:
650) this.width=650; "Src=" http://mmbiz.qpic.cn/mmbiz/ vqlbvfl5jn0cbzzvypv1jgdeliokcm8ia6qpdzcecbzftqxlvlzepxbpgslsmvkh7tyhl2x4pbtsupou3slhhfa/640?wx_fmt=png&tp= Webp&wxfrom=5&wx_lazy=1 "style=" margin:0px;padding:0px;height:auto;width:646.205px; "alt=" 640?wx_fmt=png &tp=webp&wxfrom=5&wx_lazy= "/>
Why is this the case, how can we minimize the time? Should you focus on optimizing it? Good question, I have prepared more information on this, please see: HTTPS://SCALEYOURCODE.COM/BLOG/ARTICLE/27.
If you are interested in learning more, please refer to Steve Souders's wonderful Speech (Https://www.youtube.com/watch?v=f5_iAzS3WMQ), which describes the performance criteria used for measurement. Page loading times are not always the best standard. Three
Other factors that allow content to be presented more quickly
Now that we have a faster TTFB, will every place be presented at a rapid pace? Not necessarily, let's look at the critical rendering path.
The key rendering path is the sequence of steps that the browser has to perform in order to get HTML, build the DOM, get style information, execute critical JavaScript, and draw the content.
650) this.width=650; "Src=" http://mmbiz.qpic.cn/mmbiz/ Vqlbvfl5jn0cbzzvypv1jgdeliokcm8iaeh35fnrcrg8czvkyha4xuoiafjodmcvtnviambrpeiatdka3ndpweercg/640?wx_fmt=jpeg &tp=webp&wxfrom=5&wx_lazy=1 "style=" margin:0px;padding:0px;height:auto;width:646.205px; "alt=" 640?wx _fmt=jpeg&tp=webp&wxfrom=5&wx_lazy "/>
God, there's a lot of work to do.
That's why we need to take it seriously. The more HTML, CSS, and JavaScript, the longer it takes. This is why you add the async tag when you load a JavaScript file.
When the browser encounters JavaScript, it may not know if the JS here will change the DOM. Therefore, it has to assume that it will change, and then it blocks rendering until JavaScript completes the execution process. If an async tag is added, it is equivalent to assuring the browser that the JS is not critical to the page, so the browser can continue rendering without waiting for JS to complete.
If you run into a script that modifies the page, does that mean it should not be asynchronous? possible. However, even if you asynchronously modify the script of the page, it is also useful from a user's perspective. The user is able to see the content and begin to generate interaction. Indeed, some places may not be able to be presented, or it might take more than a moment. Of course, it all depends on your application, so try it and see if it meets your needs.
Critical paths are so important to receive bytes as fast as possible, because the sooner you can start processing the whole process, the faster it can be done. For more information on optimizing critical render paths, see: https://developers.google.com/web/fundamentals/performance/critical-rendering-path/ Optimizing-critical-rendering-path?hl=en. Four
How to measure the good and bad of asynchronous application
How do you measure the good and bad of an asynchronous (or other optimization) application?
There's a good measuring tool, webpagetest. You can get a variety of useful information, including slide views. The slide view is the visual process I just used to show Amazon pages. You can use it on your website to compare the differences between the asynchronous and the parallel.
Until recently, DevTools implemented its own slide view.
Open Chrome DevTools and click Reload Page TimeLine, screenshots.
You can see the screenshot of the page loading process. Isn't that good?
650) this.width=650; "Src=" http://mmbiz.qpic.cn/mmbiz/ vqlbvfl5jn0cbzzvypv1jgdeliokcm8iaejiabujzbob7kapbxdjxfuwp0sf6p7mwrtbdtkaaboxdlpjwhb3zs7a/640?wx_fmt=jpeg& Tp=webp&wxfrom=5&wx_lazy=1 "style=" margin:0px;padding:0px;height:auto;width:646.205px; "alt=" 640?wx_fmt= Jpeg&tp=webp&wxfrom=5&wx_lazy "/>
Now, you can:
Switch your network speed (remember, not everyone has an ultra-fast internet)
View Slide View
Change the script to asynchronous (or make other adjustments)
Compare slides
650) this.width=650; "Src=" http://mmbiz.qpic.cn/mmbiz/ Vqlbvfl5jn0cbzzvypv1jgdeliokcm8iapckv6dbu9pibyic7tfldvkklevwlicfuiaxrfentqceedoacy4be0ava6q/640?wx_fmt=jpeg &tp=webp&wxfrom=5&wx_lazy=1 "style=" margin:0px;padding:0px;height:auto;width:646.205px; "alt=" 640?wx _fmt=jpeg&tp=webp&wxfrom=5&wx_lazy "/>
You can adjust the speed in the DevTools.
Another tool is Speedcurve, which I recently stumbled on. It was developed by two clever guys: Mark Zeman and Steve souders, and it looked very helpful. Five
The use of DevTools
DevTools is very good, how can we better understand its usage?
The challenge is to increase the side effects of too many features that are unfortunately caused.
Besides looking at the example above, what is the better way to start learning and practicing? For how to use Devtools,paul Lewis in the actual website and others have already experienced it.
Web performance that developers should know
