What is the difference between fast and slow websites?
Is there a right answer?
No, unfortunately, not yet. The reason is that a website has many factors, each of which has the potential to slow down a website. So, instead of giving you a checklist to complete, this article intends to explain clearly how certain factors can slow down a website and what you can do about it.
As the proverb says:
Giving a man a fish is worse than teaching him how to fish; teaching a man a fish will save him for a while, but teaching a man to fish will save him for a lifetime.
In addition to letting you add "async" tags to scripts, or lay out pages in a specific order, I'm going to explain the differences these changes make. This way, you can fiddle with your application and confirm which modifications are useful.
one,
Speed up page loading
As I mentioned earlier, there is no such thing. The web is somewhat unexpectedly complex. The phenomenon of slowing down page loading may not be the right measure of focus for you!
However, there are some fairly important factors that often make a noticeable difference. You may have encountered them before, but may not understand why they are important. 1Compression transmits HTML, CSS, and JavaScript with gzip compression, reducing the number of bytes that need to flow through the wire. This can significantly reduce the time to download assets. Browsers need HTML and CSS to render pages, so we want to download these resources as soon as possible. 2. Optimizing images I have a friend who builds WordPress sites for clients. Many sites often upload a lot of images. I chatted with him recently. He ran into a problem with customers uploading pictures from the camera directly to their website.
Photos taken by the phone exceed 1MB. Even if you resize with CSS, you still need to download this very large image over the wire. Users with slow internet will have to wait a long time to open.
If you want to know how to deal with it, I strongly recommend a program related to optimizing pictures, please see: https://scaleyourcode.com/interviews/interview/19.
3. Don't transfer unnecessary stuff Look at the scripts and CSS files in different pages and ask yourself if these files are really needed for the page. You are likely to find some files that were added but not removed.
The performance of plugins in this regard is really bad. Quite a few ebordPress sites I work with load a bunch of CSS files, half of which are never used on some pages! Many non-WordPress sites have a similar phenomenon. When I checked earlier some pages on scaleyourcode.com, they were also loading an unnecessary script.
Clearing out scripts or stylesheets can be scary. What if it's really necessary for that page and you just don't remember it? There are some tools that can help us to confirm, recommend DevTools (under Audits).
Can you see the commonalities between these optimizations? They both reduce the number of bytes we need to transfer. two,
progressive rendering
You need to get HTML bytes to the browser as early 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 rendering it on the screen.
As I mentioned earlier, page load time may not be the performance metric you need to focus on, thanks to progressive rendering.
Progressive rendering
pages can be huge, but as long as you present some content to the user for a short period of time (preferably less than 1 second), they will still find it to load quickly.
Amazon does a good job here:
Amazon's Progressive Rendering
got the first screen in 1.5 seconds for this WebPageTest, but as you can see, it doesn't cover everything. It contains enough content to get you started browsing the page, or checking out holiday deals.
Then, by 3.5 seconds, another section loads more transactions. At 6.5 seconds, something is still loading! In fact, the entire page load completed until 18 seconds. Can you wait that long? I doubt it!
If Amazon focuses on the slowest page loads, someone must be pissed off. Instead, they focus on sending the most important bytes in the earliest packets. Going a step further, they may cram the most significant bytes in the first packet. I bet they're also focused on sending you those bytes as fast as possible.
This is where TTFB (Time To First Byte) comes from.
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 response bytes. This time not only represents the time it takes for your server to generate a response, but also the time it takes to transmit over the wire.
This graph has a very fast TTFB. If you go shopping online, you can see different TTFBs and you will see something similar to the picture below:
Why is this the case and how can we minimize this 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're interested in learning more, then check out Steve Souders' great talk (https://www.youtube.com/watch?v=f5_iAzS3WMQ) about performance metrics to measure. Page load time isn't always the best metric. three,
Other factors that make content render faster
Now that we have a faster TTFB, will everything be rendered extremely fast? Not necessarily, let's look at the critical rendering path.
The critical rendering path is the sequence of steps the browser has to perform in order to get the HTML, build the DOM, get style information, execute critical JavaScript, and draw the content.
Gosh, that'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 will take. Add the async tag when loading a JavaScript file, that's why.
When the browser encounters JavaScript, it probably doesn't know if the JS here is going to change the DOM. So it has to assume it will change, and then it blocks rendering until the JavaScript has finished executing. Adding the async tag is equivalent to assuring the browser that the JS is not critical to the page, so the browser can continue rendering without waiting for the JS to finish executing.
If you encounter a script that modifies the page, does that mean it shouldn't be asynchronous? possible. Still, even if you asynchronously make the script that modifies the page, it's still practical from the user's point of view. Users can see the content and start interacting. It is true that some places may not be available, and it may take a little longer. Of course, it all depends on your application, so try it out and see if it meets your needs.
The reason the critical path is so important to receive bytes as fast as possible is that the sooner you can start processing the entire process, the faster it can be completed. For optimizing the critical rendering path, see: https://developers.google.com/web/fundamentals/performance/critical-rendering-path/optimizing-critical-rendering-path?hl=en. Four,
How to measure whether asynchrony is good or bad for your application
How do you measure whether asynchrony (or other optimizations) is good or bad for your application?
There is a nice measurement tool, WebPageTest. You can get all kinds of useful information, including slide view. The slide view is the visualization I just used to show the Amazon page. You can use it on your website to compare side-by-side differences with and without async.
Until recently, DevTools implemented its own slideshow view.
Open Chrome DevTools, click TimeLine -> Enable Screenshots -> Reload page.
You can see a screenshot of the page loading process. Not bad right?
Now you can:
-
Switch your internet speed (remember, not everyone has super fast internet)
-
View slideshow view
-
Change the script to be asynchronous (or make other adjustments)
-
Compare slides
Another tool you can adjust your internet speed in DevTools
is SpeedCurve, which I stumbled across recently. It's been developed by two smart guys: Mark Zeman and Steve Souders, and it seems helpful. Fives,
How to use DevTools
DevTools is great, how can we better understand its usage?
The difficulty is the unfortunate side effect of adding too many features.
What better way for us to start learning and practice than looking at the examples above? Paul Lewis and others have experienced how to use DevTools in real web sites.