7 tips on how to improve the performance of your site in Microsoft Edge and other modern browsers

Quick Reference: Microsoft Edge is a new default browser in Windows 10 that replaces Internet Explorer. In addition to the new interface, under the hood of the browser there are also updated EdgeHTML engines (originally - IE11 engine fork) and Chakra (for JS). For a time, the browser was known under the temporary name “Project Spartan”.

Along with the growth of Windows 10, you probably could notice on your websites the growth in the number of Microsoft Edge users. Therefore, it's time to make some gestures to make your sites even better in Edge.
')
The tips I give below are generally of a generalized nature. In other words, not only Edge users will benefit from their implementation, but also other browsers.

Avoid browser definitions - determine functionality

Once upon a time, in the HTTP / 1.1 specification and, accordingly, the HTML specification introduced the concept of a User Agent, which should identify the browser (or any other client) that accesses the server. This function, useful in many scenarios and difficult to replace (for example, for collecting statistics), also gained notoriety in real life for utilization in order to divide browsers into “bad” and “good”.

Without going into the vicissitudes of browser battles, I would only note that there were times when developers, relying on the value of the string UA, every now and then gave one browser one layout and the other to another. Why there was a lot of sadness among users and the pain of browser developers. Last, time and again, they tried to deceive the fate of the Internet distribution and hid behind other people's UAs in the hope of a bright future.

According to the modern UA lines of popular browsers, you can study the history of the web:



(You know that according to the HTML5 specification, navigator.appCodeName is always “Mozilla” and navigator.product is always “Gecko”? All for compatibility.)



In an ideal world, of course, I want to believe that the times of battles are long gone, but, statistics, unfortunately, says the opposite. In the modern web, there is still a huge number of sites that to one degree or another use browser detection in order to give it one or another layout or implement this or that logic in JavaScript.

As they say, the Jedi who are on the bright side, the correct code looks at the capabilities of the browser, and not judged by its User Agent String. This approach was given the name Feature Detection, as many articles were written about and many words were spoken.

Tip # 1: use flexible solutions in your code, based on the browser's available functionality, not the version or name of the browser.

Libraries like Modernizr can help you with this.

Anyway, the new User Agent line in Microsoft Edge looks like this: "Mozilla / 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 42.0.2311.135 Safari / 537.36 Edge / 12.10240" . It is intentionally very similar to the Chrome line, although it has a distinctive Edge at the end.

Edge team deliberately works to ensure compatibility not only with web standards, but their implementation in other browsers, in particular, in Chrome and Firefox. Therefore, in most cases, “the layout for Chrome of the modern web should just work.”

The subtle point here is that if you detect Chrome on your public site in order to use the functionality available only in it, and this functionality is critical for UX, then people with Edge will be upset by the inactive site.

If you need to define a platform, do it right.

Confidently moving towards a bright future of compatibility on the desktop, as you know, the web missed the most powerful blow in the mobile world. We will talk about this a little later precisely in the context of compatibility, and now we will continue to deal with the detection of the browser.

The authors of many websites and web applications (not all, of course) in the mobile era thought not only about adding mobile “look and feel” to their resources, but also about acquiring mobile applications for different platforms.

Then they began to think how to tell the users of the site from their mobile devices that they now need to use mobile applications. And here they again remembered the user-agent string ... and it started.

In general, as soon as IE disappeared, Edge came to replace him, who pretends to be Chrome, who pretends to be Safari, who pretends to be Gecko and KHTML, who all pretend to be Mozilla ... Edge users on Windows 10 Mobile suddenly, instead of native applications, began to receive recommendations to put the application under Android

Often, this is done by self-written code, often copied from another blog post or StackOverflow, often ready-made libraries, for example, jQuery Smart Banner ...

As a lyrical and practical digression: I once opened a js code in a debugger on a Russian news site and was horrified by the library of 2012 (release time for iOS6 and Windows 8). She worked for a year or two, but then the WP8.1 update came out first, and then the mobile version of the Edge — and “it all broke.”

The user agent in the mobile version of Edge is as follows: "Mozilla / 5.0 (Windows Phone 10.0; Android 4.2.1 ; Nokia; Lumia 520) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 42.0.2311.135 Mobile Safari / 537.36 Edge / 12.10130" .

As you can guess, somewhere in the wilds of the library mentioned above and used on the site, it all goes together like this:

if (UA.match(/Android/i) != null) { this.type = 'android' } else if (UA.match(/Windows NT 6.2/i) != null && UA.match(/Touch/i) !== null) { this.type = 'windows' } 

And, obviously, in the case of the mobile version of Edge, the first branch is working. As a result, the good intention of the developers of the site turns into a microad for the user. Not to mention the fact that there is again the rake of versioning: in Windows 10, the version of the NT platform is 10, not 6.2, and in Windows 8.1 there was already version 6.3. However, the developer, hardly, could guess about it in 2012.

What to do? It turns out that even a UA-string, full of all “interesting” details, must, according to the specification, follow a simple rule: all listed products must be arranged in order of priority, as the client (browser) developer sees them.

Tip number 2: parsing UA-line, consider the order of occurrences, and not just the presence of keywords.

If the browser says that it is, first of all, Windows Phone, and only secondly it wants to receive content for Android, then for sure it wants you to perceive WP as the OS.

A relatively small change in the code on the site can bring you new happy users of the mobile application.

Upgrade libraries to newer versions.

We searched the web a little bit and found out that more than half of the most popular 20,000 sites use JavaScript libraries that have known problems fixed in more recent versions.

We made a scanner for sites that allows you to check:



By the way, the source code of the scanner is available on GitHub . If you find a bug, let us know in the repository.

The problem with outdated libraries sometimes has a very specific nature, strongly correlated with the very dynamics of the web and the implementation of web standards, in particular. There is a copy-and-paste code, and vendronic features and chips, and standards that change in the process of stabilization, and bad programming practices. Full bouquet.

What you should pay attention to when choosing libraries:

1. Minimum requirements for browsers and their engines. Must meet your minimum browser support requirements.
2. The lack of references in the code on the browser version and in general the detection of browsers. A good library should look to the future and be neutral, and not cling to some current cut.
3. Using stable cross-browser APIs, and when using new and, as a rule, experimental APIs, there are fallback branches in case they are not supported in a particular browser.
4. Minimizing the use of vendor APIs (usually with prefixes), better - the absence of such calls and references, and, if available, a mandatory fallback to the standard "non-prefixed" API. In other words, the library should give preference to the standardized API.
5. Version stability and development dynamics. It is always finding the right balance. A stable library should provide medium-term reliability, and the dynamics of development should show that this is not a stillborn project that is no longer interesting for its authors.

Tip number 3: use fresh and browser-neutral libraries with stable code.

For example, if the library has an official repository on GitHub, do not be lazy to check how many known problems it has and how often it is updated.

The attentive reader will note that in this section I have never said that this is only about JavaScript. And, indeed, all this concerns not only JS (and the corresponding APIs), but also any CSS frameworks and, in particular, excellent experiments on how to make something beautiful with new CSS features described in the draft of the next standard or documentation of one of the browser manufacturers.

Watch for errors, collect statistics

The history with libraries suggests that it is important not only to competently approach the writing of your code and the integration of someone else, but also to track changes in the environment, which happens in the world of the web. Somewhere the standard has changed, somewhere the browsers have turned off support for experimental functionality (for example, in the prefix form that you used), somewhere in the new version there was a implementation bug, somewhere the libraries stopped joining with each other ...

In general, the question is that when developing a certain solution, it is important not only to make sure that it works at the moments of the development itself and its immediate implementation, but also during further operation.



And if at the first stage you are ready to spend significant efforts to check how your web application behaves in current browsers, then further, unless it is a question of a constantly developing and updated project (and most sites are not like that!), checks happen rarely or not at all.

And the reaction and correction of problems, as a rule, occur in a reactionary mode, when there is some regular user with a problem about which he finds the courage and desire to tell.

In such a situation, a reasonable solution is to introduce statistics collection and its subsequent analysis. In other words, your code should be able to "in the event of an unforeseen", that is, in the case of exceptional situations, generate events and send meta-data to some information gathering service. On the other hand, you or the customers of the site should be able to understand what is happening with the site in the current historical realities. And not only from the point of view of marketing and sales, but also from a technological point of view.

Council number 4. Implement analytics and monitor inoperable functionality or incorrect behavior of the site.

In the long run, this may at a minimum help to be aware of compatibility issues.

"A minute of advertising." As you, for certain, already heard, we have a special cloud service for developers, made for such purposes - Application Insights in Microsoft Azure. (For students, the service is also available in the DreamSpark program .) In addition to tracking general events, such as the pages visited, it also allows you to enter your own events and metrics that you can send to analytics from your code at the right time:

 appInsights.trackEvent // or trackPageView, trackMetric, ... ("WinGame", // String properties: {Game: currentGame.name, Difficulty: currentGame.difficulty}, // Numeric metrics: {Score: currentGame.score, Opponents: currentGame.opponentCount} ); 

Now let's go back to CSS.

Avoid CSS Prefix Properties; Use Standard Properties.

Once it seemed that the introduction by manufacturers of browsers of experimental CSS properties with vendor prefixes was a great idea, which allowed them to experiment, and it didn’t seem to pollute the Internet.

It turned out that it is not. The good idea, as is usually the case, faced the harsh reality of life, in which many web developers fascinated by beauty began to exploit non-standard implementations in living projects.



You, for certain, remember all these stories about dramatic changes in the syntax of gradients that occurred between the initial implementation in the Webkit engine (Safari) and the final version in the corresponding web standard.

You also, for sure, imagine how the code with similar chips falls into the markup of many sites, being banally copied from another beautiful article. The problem is that often such code is written specifically for demonstration purposes, and therefore, for simplification or for reasons of compactness (or for some other misunderstanding), does not contain a complete history. That is, it does not tell how it is worth it (and whether it is worth it at all) to be used in operation on real sites.

The latter means in practice that you need 1) to list all the options for different browsers and 2) do not forget to indicate the version of the code that corresponds to the standard (perhaps designed).



Incorrect use of experimental and non-standard features can lead to the banality of the fact that the site does not just look "less beautiful", but also tritely ceases to implement its key functionality. In the example above, the use of --webkit-transition without mentioning alternatives and the standard version causes the site menu to stop opening in non-webkit browsers. This is sad.

Tip # 5 (Updated). Prefer the standard version without prefixes.

Adding properties with prefixes is best left to ready-made utilities, for example, autoprefixer .

I repeat, this concerns both the code that you write yourself, and the copied code, and the code of the link libraries. As an example: let's take a fairly popular library, normalize.css , which should, as the name and description imply, result in displaying different elements in different browsers in a more or less identical form. Below is a sample code from the library:

 html { font-family: sans-serif; /* 1 */ -ms-text-size-adjust: 100%; /* 2 */ -webkit-text-size-adjust: 100%; /* 2 */ } 

As it is easy to notice, there is clearly something missing here. For example, properties with --moz- prefix and version compatible with the standard being developed . By the way, the scanner , which I mentioned above, is able to determine such things.

Browser manufacturers, for their part, are also trying to deal with this: we tell website developers that it’s not good to do this, but for end users we have to implement support for “alien” prefix APIs in browsers.

Just for reference: in Microsoft Edge, the supported --webkit- prefixes are already larger than the own prefixes --ms-. (Not that we like it very much ... but we need it.)

Do without plug-ins where this is possible

Plug-ins in browsers are a long history of many interesting solutions, excellent technologies for their time, and long and not so sad falls. A brief version of the current state of affairs: browsers are moving towards a model without binary extensions.
For example, it does Chrome with the rejection of NPAPI and it does Microsoft Edge with the rejection of ActiveX. For all this, there are three simple and understandable reasons:

1. Substitution of web standards (uniform and portable)
2. Reducing the surface for attacks and potential security holes (and, as a rule, it’s about integrating third-party, little-controlled plug-ins into the browser)
3. Simplify the internal architecture of browsers in favor of using the same technologies as on the websites that they display (HTML, CSS, JavaScript).

If you are making solutions for the mobile web, tv-web and any other non-desktop platforms, almost certainly, plug-ins that are popular on the desktop will not be supported in the corresponding browser. Therefore, the story of the plump web is well known to you.

If you make decisions exclusively for the desktop, then you must already be aware of all current trends for the consistent replacement of a particular functionality of plug-ins (for example, Flash and Silverlight) with similar or alternative features.

Graphics, 3d-graphics, animations, sound control - all this can already be done in modern browsers, using technologies such as SVG, Canvas, WebGL, CSS-animations, WebAudio - all this in conjunction with JavaScript. For example, Unity already allows you to use this stack for browser games.

One of the key niches for using plug-ins on websites is playing audio and video content, including those with copyright protection.



HTML5 Audio / Video in combination with DASH / CENC / MSE / EME and DRM implementation at the hardware or software level completely allow plug-ins to be replaced .

Tip number 6: wherever possible, try to replace the use of plug-ins on modern web standards.

At least for modern browsers.

With the introduction of technologies such as WebRTC (ORTC), the plug-in-free world will be open for video and audio communications in the browser. I think that the introduction of web components will also significantly reduce the proportion of use of Flash in the advertising segment.

Of course, the actual introduction of technology takes time and the future without plug-ins, which we have been waiting for for several years, still does not come, but I personally continue to believe that "if not tomorrow, then surely."

You can monitor the implementation status of a particular functionality on the relevant sites: Microsoft Edge , Webkit (Safari), Blink (Chrome, etc.) - or track the general dynamics through caniuse.com .

Test sites in Microsoft Edge: directly or remotely

And the last batch of recommendations about how to test sites directly in Microsoft Edge.

The first thing you need to understand is that for Edge you need Windows 10. If you do not have Windows 10 (I remind you that you can upgrade with Windows 7/8 / 8.1 for free), then you can set up a virtual machine with Windows 10 and a new browser .



We tried to prepare images for all popular operating systems (Windows, Mac OSX, Linux) and virtualization platforms (HyperV, VirtualBox, VMWare, Parallels).

Second: you can use various tools to debug sites. It can be either updated F12 tools , embedded in the browser, or remote tools, such as Vorlon.js . You can also use WebDriver to automate testing.



And the third: as you, for certain, heard, from Microsoft Edge in comparison with Internet Explorer many outdated and non-standard things disappeared. Therefore, if you relied on them in IE, do not expect to use them in the Edge - we all sawed out.

Tip # 7: Add Microsoft Edge to the list of browsers in which you check your sites.

If you find problems in the browser itself (for example, a deviation from the standard or a difference with the implementation in other browsers), let us know via Connect , the browser’s built-in “Send feedback” function or on @msedgedev .

Results

Finally, I will try to collect all the tips together:

1. Use flexible code solutions based on the browser’s available functionality, not the browser’s version or name. (Feature Detection)
2. If you need to define a platform, parsing the string UA, consider the prioritization.
3. Upgrade libraries to fresh versions, choose libraries that are neutral to browsers.
4. Implement statistics on the site not only for the removal of marketing indicators, but also to account for technical telemetry.
5. Use standard CSS properties, minimize the use of prefixes, and if you add them, do it for all browsers.
6. As far as possible, replace plug-ins with technologies based on web standards.
7. Follow the dynamics of users and add Microsoft Edge to the list of tested browsers.