For the first screen, the Site's largest rendering blocking resources is the CSS. The browser will only start rendering the page when the CSS file inside is fully loaded. This approach is well thought out, and if not, the browser needs to continually recalculate the layout dimensions throughout the rendering process and redraw them continuously.
Key CSSThe key CSS is blocking the browser from rendering a small subset of the CSS that the user can Recognize. We pay attention to the page 上半版版面
. obviously, there is a big difference between the layout of the two Devices. So we made a bold guess.
Manually detecting this part of the critical CSS is a time-consuming process, especially when styles, features, and so on are constantly changing. Here are a few good scripts that can generate critical CSS when you build a Web Page. We have adopted Addy Osmani
the Version.
Here are the page effects we render separately using the key CSS and the entire css. Note that the next half of the version still has some content that does not have a style.
The left-hand page is rendered with a key css, while the right-hand page is a full-copy css. Red lines are the dividing Line.
Service sideWe deploy our own de Voorhoede
Web site because we want to be able to control the server Environment. We also want to try and see if we can dramatically improve performance by changing the configuration on the server Side. Currently we use the Apache
service and HTTPS Protocol.
ConfigurationTo improve performance and security, we studied how to configure the server Side.
We use the H5BP
Apache template configuration, which is a good start to improve the performance and security of Apache network Services. They also have configurations for other server Environments. For most of our HTML, CSS, and JS, we use gzip Compression. For all of our site resources, we use the practice of caching HTTP Headers. Interested please read the section on File-level caching.
HTTPSUsing HTTPS to service your site can have a performance impact. The main thing is to set up an SSL handshake that introduces a lot of potential stuff. But usually, we can make some changes!
HTTP Strict Transport Security
is an HTTP header that lets the server tell the browser to interact with it only with https. This way, the HTTP request is prevented from being redirected to Https. All requests to access the site using HTTP will be automatically converted to Https. This saves a round trip.
TLS false start
Allows the client to immediately send encrypted data back to the end of the first TLS round. This optimization reduces the number of handshakes for a new TLS Connection. Once the client knows the key, it can begin transmitting the application Data. The remaining handshake is used to confirm if someone tampered with the handshake record and can be processed in parallel.
TLS session resumption
Save us a trip by confirming that the browser and server have been Contacted. The browser remembers this one time identifier, and the next time the connection is initiated, the identifier is reused, saving a back and Forth.
I sound like a developer and ops, but it's Not. I've just read some books and I've seen some videos. I like Google I/O 2016 Mythbusting HTTPS
: Emily Stark
the security of urban LEGENDS.
Use of cookiesWe do not use a service-side language, only the static Apache network Service. But an Apache Web service can still do back-end services, including ssi, and read Cookies. By skillfully using cookies and running portions of HTML that were rewritten by apache, we can dramatically improve front-end performance. Here's An example (our actual code is more complicated than this, but the thinking is consistent):
<!-- #if expr="($HTTP_COOKIE!=/css-loaded/) || ($HTTP_COOKIE=/.*css-loaded=([^;]+);?.*/ && ${1} != ‘0d82f.css‘ )"-->
<noscript><link rel="stylesheet" href="0d82f.css"></noscript>
<script>
(function() {
function loadCSS(url) {...}
function onloadCSS(stylesheet, callback) {...}
function setCookie(name, value, expInDays) {...}
var stylesheet = loadCSS(‘0d82f.css‘);
onloadCSS(stylesheet, function() {
setCookie(‘css-loaded‘, ‘0d82f‘, 100);
});
}());
</script>
<style>/* Critical CSS here */</style>
<!-- #else -->
<link rel="stylesheet" href="0d82f.css">
<!-- #endif -->
Apache service-side logic looks like a line-by-line comment, typically to <!-- #
begin With. Let's take a step-by-step look at it:
$HTTP_COOKIE!=/css-loaded/
Detects if a CSS cache cookie Exists.
$HTTP_COOKIE=/.*css-loaded=([^;]+);?.*/ && ${1} != ‘0d82f.css‘
The version that detects the cache is not the current version you Want.
If <!-- #if expr="..." -->
If it is true, we assume that this is the first time the user has Browsed.
The first time we added a <noscript>
tag, it was placed inside <link rel="stylesheet">
. This is done because we want to load the entire CSS and JS asynchronously. If JS is not available, this practice cannot be performed. This means that we have to do a fallback using the usual method of loading css.
We added a inline script to lazy load css, onloadCSS
callback inside can set Cookies.
In the same script, we loaded the entire CSS Asynchronously.
In onloadCSS
the callback, we use the version number to set the value of the Cookie.
After this script, we added a line of key CSS Styles. This will block the rendering, but the time is very short, and can avoid the page display only pure HTML and no Style.
<!-- #else -->
css-loaded
the user repeatedly browses the statement (meaning that the cookie already exists). Because we can assume to some extent that the CSS file has been loaded before, we can use the browser cache to provide the style Sheet. This way, loading from the cache is Fast. The same method is used to load the font asynchronously for the first time, and subsequent repeated browsing also gets the font from the Cache.
This is our first and repeated browsing when we used to differentiate the Cookies.
File-level CachingSince we rely heavily on the browser cache to reproduce the page, we need to verify that our cache is Reasonable. Ideally we would like to store resources Forever (CSS, js, fonts, pictures), only need to be updated when these files are Modified. When the requested URL is unique, the cache is Invalidated. we'll use a label for each version we update git tag
. So the simplest way is to add a parameter (code version number) to the URL we requested, such as https://www.voorhoede.nl/assets/css/main-8af99277a6.css?v=1.0.4.
.
however, The disadvantage of this approach is that when we are going to write a new blog post (which is also part of our code base and is not permanently stored in the cms), the original cached resources will be invalidated, although the original resources are not changed.
As we try to improve this approach, we find the gulp-rev
and gulp-rev-replace
. These scripts will automatically add a hash value after our file Name. This means that the requested URL is changed only when the file is actually changed, so that the cache for each file is automatically Invalidated. I am so excited by this practice!
ResultsIf you see this, you should want to know the Result. Testing the performance of a Web page can take a PageSpeed Insights
tool like this, it has a very useful hint. can also be used WebPagetest
to test, with extensibility for network Analysis. I think the best way to test Web page rendering performance is to watch the Web page process as it frantically curbs network traffic. This means that there is an unrealistic way to curb Communication. In Google chrome, you can do this (via the Inspector > Network tab) to restrict communication, observing how slowly the request is loaded during web page Formation.
Below is the loading status of our web page in the case of 50kb/s.
This is the de Voorhoede site
first screen of the network analysis, the Web page is an overview of the first process.
Notice how we made the first screen render only for 2.27 seconds in the 50kb/s Speed. The position represented by the Yellow line in the first slide and the waterfall Chart. The Yellow line is exactly where the HTML has been Loaded. HTML contains key CSS to ensure the objectivity of the Page. All other CSS is loaded lazily, so we can wait until all the resources have been loaded to interact with the Page. This is the effect we want!
Another notable thing is that a custom font never loads on this slow link. font face
the viewer will automatically notice This. however, If we do not load the font asynchronously, you gaze at most browsers, which will appear FOIT
(flashes of invisible text, mentioned above).
All CSS files are loaded only after 8s. conversely, If we don't take the method of loading the key css, instead of loading all the css, we'll see a blank page in the first 8 seconds.
If you're curious and want to compare load times with sites that don't pay much attention to performance, try it Out. That time must have been soaring!
We tested our website with the tools described above, and the results were satisfying. It PageSpeed insights
gives us 100 points in terms of mobile performance, how amazing!
PageSpeed insights
The voorhoede.nl
test results of the pair! speed 100 points!
When we look at it WebPagetest
, we get the following result:
Test results of Webpagetest pair voorhoede.nl
As can be seen, our server is running well, the first screen speed indicator is 693. This means that our page can be used under a widescreen cable in 693 MILLISECONDS.
Technical RouteWe are not finished yet, and we will continue to repeat our Approach. In the near future, we will mainly focus on the following topics:
Http/2We are currently experimenting with http/2. Most of the things described in this article are based on best practices within http/1.1 permissions. In short, the http/1.1 will go back to 1999, when both the table layout and the inline style are in full swing. http/1.1 has never been designed to accept 200 requests for a 2.6MB web Page. In order to alleviate the pain caused by the old protocol, we combine js, css, key css, and also set the data source URI for the small picture. Save requests in a variety of ways. Since HTTP/2 can run multiple requests in parallel on the same TCP link, the use and reduction of all of these joins can be a negative pattern. When we run through this experiment, we will adopt the HTTP/2 Protocol.
Service WorkersThis is a JavaScript API for modern browsers running in the Background. It has many features that are not available on previous sites, such as offline support, message push, background synchronization, and so On. We are trying to use it now, but we have to do it Service Worker
on our own website First. I promise you, we'll do it!
Cdntherefore, we want to control and deploy our website Ourselves. And now we're going to use a CDN to get rid of the network problems caused by the actual distance between the server and the Client. While our users are basically dutch, we want to reflect to the World's front-end community the best we can do in terms of quality, performance and driving the development of the Web.
Eof
Nuggets is a high-quality technology community, from ECMAScript 6 to vue.js, website performance optimization to open source class library, so you are good at WEB development of every technical dry. Long-click on the image QR code identification or the major application market search "nuggets", Technical dry in the grasp.
160830, How to use the latest technology to improve the speed and performance of Web pages