The only Front-End Performance Checklist that runs faster than the others

-

Introduction

Performance is a huge subject, but it's not always a "back-end" or an "admin" subject: it's a Front-End responsibility too. The Front-End Performance Checklist is an exhaustive list of elements you should check or at least be aware of, as a Front-End developer and apply to your project (personal and professional).

How to use?

For each rule, you will have a paragraph explaining why this rule is important and how you can fix it. For more deep information, you should find links that will point to hammer_and_wrench tools, book articles or video_camera medias that can complete the checklist.
All items in the Front-End Performance Checklist are essentials to achieve the highest performance score but you would find an indicator to help you to eventually prioritised some rules amount others. There are 3 levels of priority:
  • Low means that the item has a low priority.
  • Medium means that the item has a medium priority. You shouldn't avoid tackling that item.
  • High means that the item has a high priority. You can't avoid following that rule and implement the corrections recommended.

Performance tools

List of the tools you can use to test or monitor your website or application:

References

HTML

html
  •  Minified HTML: medium The HTML code is minified, comments, white spaces and new lines are removed from production files.
    Why:
    Removing all unnecessary spaces, comments and break will reduce the size of your HTML and speed up your site's page load times and obviously lighten the download for your user.
    How:
    Most of the frameworks have plugins to facilitate the minification of the webpages. You can use a bunch of NPM modules that can do the job for you automatically.
  •  Remove unnecessary comments: low Ensure that comments are removed from your pages.
    Why:
    Comments are not really useful for the user and should be removed from production files. One case where you want to keep comments could be if you need to keep the origin for a library.
    How:
    ⁃ Most of the time, comments can be removed using an HTML minify plugin.
  •  Remove unnecessary attributes: low Type attributes like type="text/javascript" or type="text/css" are not required anymore and should be removed.
    <!-- Before HTML5 -->
<script type="text/javascript">
    // JavaScript code
</script>

<!-- Today -->
<script>
    // JavaScript code
</script>
    Why:
    Type attributes are not necessary as HTML5 implies text/css and text/javascript as defaults. Unused code should be removed when not used by your website or app as they add more weight to your pages.
    How:
    ⁃ Ensure that all your <link> and <script> tags don't have any type attribute.
  •  Place CSS tags always before JavaScript tags: high Ensure that your CSS is always loaded before having JavaScript code.
    <!-- Not recommended -->
<script src="jquery.js"></script>
<script src="foo.js"></script>
<link rel="stylesheet" href="foo.css"/>

<!-- Recommended -->
<link rel="stylesheet" href="foo.css"/>
<script src="jquery.js"></script>
<script src="foo.js"></script>
    Why:
    Having your CSS tags before any JavaScript enables better, parallel download which speed up browser rendering time.
    How:
    ⁃ Ensure that <link> and <style> in your <head> are always before your <script>.
  •  Minimize the number of iframes: high Use iframes only if you don't have any other technical possibility. Try to avoid as much as you can iframes.

CSS

css
  •  Minification: high All CSS files are minified, comments, white spaces and new lines are removed from production files.
    Why:
    When CSS files are minified, the content is loaded faster and less data is sent to the client. It's important to always minify CSS files in production. It is beneficial for the user as it is for any business who wants to lower bandwidth costs and lower resource usage.
    How:
    ⁃ Use tools to minify your files automatically before or during your build or your deployment.
  •  Concatenation: medium CSS files are concatenated in a single file (Not always valid for HTTP/2).
    <!-- Not recommended -->
<link rel="stylesheet" href="foo.css"/>
<link rel="stylesheet" href="bar.css"/>

<!-- Recommended -->
<link rel="stylesheet" href="foobar.css"/>
    Why:
    If you are still using HTTP/1, you may need to still concatenate your files, it's less true if your server use HTTP/2 (tests should be made).
    How:
    ⁃ Use online tool or any plugin before or during your build or your deployment to concatenate your files. 
    ⁃ Ensure, of course, that concatenation does not break your project.
  •  Non-blocking: high CSS files need to be non-blocking to prevent the DOM from taking time to load.
    <link rel="preload" href="global.min.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="global.min.css"></noscript>
    Why:
    CSS files can block the page load and delay the rendering of your page. Using preload can actually load the CSS files before the browser starts showing the content of the page.
    How:
    ⁃ You need to add the rel attribute with the preload value and add as="style" on the <link> element.
  •  Length of CSS classes: low The length of your classes can have an (slight) impact on your HTML and CSS files (eventually).
    Why:
    Even performance impacts can be disputable, taking a decision on a naming strategy regarding your project can have a substantial impact on the maintainability of your stylesheets. If you are using BEM, in some cases, you can end up with classes having more characters than needed. It's always important to choose wisely your names and namespaces.
    How:
    Setting a limit in terms of number of characters could be interesting for some people, but ensuring that you broke down your website in components can help to reduce the amount of classes (and declarations) and the length of your classes.
  •  Unused CSS: medium Remove unused CSS selectors.
    Why:
    Removing unused CSS selectors can reduce the size of your files and then speed up the load of your assets.
    How:
    ⁃ warning Always check if the framework CSS you want to use don't already has a reset / normalize code included. Sometimes you may not need everything that is inside your reset / normalize file.
  •  Embedded or inline CSS: high Avoid using embed or inline CSS inside your <body> (Not valid for HTTP/2)
    Why:
    One of the first reason it's because it's a good practice to separate content from design. It also helps you have a more maintainable code and keep your site accessible. But regarding performance, it's simply because it decreases the file-size of your HTML pages and the load time.
    How:
    Always use external stylesheets or embed CSS in your <head> (and follow the others CSS performance rules)
  •  Analyse stylesheets complexity: high Analyzing your stylesheets can help you to flag issues, redundancies and duplicate CSS selectors.
    Why:
    Sometimes you may have redundancies or validation errors in your CSS, analysing your CSS files and removed these complexities can help you to speed up your CSS files (because your browser will read them faster)
    How:
    Your CSS should be organized, using a CSS preprocessor can help you with that. Some online tools listed below can also help you analysing and correct your code.

Fonts

fonts
  •  Prevent Flash or Invisible Text: medium Avoid transparent text until the Webfont is loaded

Images

images
  •  Use vector image vs raster/bitmap: medium Prefer using vector image rather than bitmap images (when possible).
    Why:
    Vector images (SVG) tend to be smaller than images and SVG's are responsive and scale perfectly. These images can be animated and modified by CSS.
JavaScript
javascript
  •  JS Minification: high All JavaScript files are minified, comments, white spaces and new lines are removed from production files (still valid if using HTTP/2).
    Why:
    Removing all unnecessary spaces, comments and break will reduce the size of your JavaScript files and speed up your site's page load times and obviously lighten the download for your user.
    How:
    ⁃ Use the tools suggested below to minify your files automatically before or during your build or your deployment.
  •  No JavaScript inside: medium (Only valid for website) Avoid having multiple JavaScript codes embedded in the middle of your body. Regroup your JavaScript code inside external files or eventually in the <head> or at the end of your page (before </body>).
    Why:
    Placing JavaScript embedded code directly in your <body> can slow down your page because it loads while the DOM is being built. The best option is to use external files with async or defer to avoid blocking the DOM. Another option is to place some scripts inside your <head>. Most of the time analytics code or small script that need to load before the DOM gets to main processing.
    How:
    Ensure that all your files are loaded using async or defer and decide wisely the code that you will need to inject in your <head>.
  •  Non-blocking JavaScript: high JavaScript files are loaded asynchronously using async or deferred using deferattribute.
    <!-- Defer Attribute -->
<script defer src="foo.js"></script>

<!-- Async Attribute -->
<script async src="foo.js"></script>
    Why:
    JavaScript blocks the normal parsing of the HTML document, so when the parser reaches a <script> tag (particularly is inside the <head>), it stops to fetch and run it. Adding async or defer are highly recommended if your scripts are placed in the top of your page but less valuable if just before your </body> tag. But it's a good practice to always use these attributes to avoid any performance issue.
    How:
    ⁃ Add async (if the script don't rely on other scripts) or defer (if the script relies upon or relied upon by an async script) as an attribute to your script tag. 
    ⁃ If you have small scripts, maybe use inline script place above async scripts.
  •  Optimized and updated JS libraries: medium All JavaScript libraries used in your project are necessary (prefer Vanilla JavaScript for simple functionalities), updated to their latest version and don't overwhelm your JavaScript with unnecessary methods.
    Why:
    Most of the time, new versions come with optimization and security fix. You should use the most optimized code to speed up your project and ensure that you'll not slow down your website or app without outdated plugin.
    How:
    If your project use NPM packages, npm-check is a pretty interesting library to upgrade / update your libraries.

Server

server-side
  •  Minimizing HTTP requests: high Always ensure that every file requested are essential for your website or application.
  •  Use a CDN to deliver your assets: medium Use a CDN to deliver faster your content over the world.
  •  Serve files from the same protocol: high Avoid having your website using HTTPS and serve files coming from source using HTTP.
  •  Serve reachable files: high Avoid requesting unreachable files (404).
  •  Set HTTP cache headers properly: high Set HTTP headers to avoid expensive number of roundtrips between your browser and the server.
  •  GZIP / Brotli compression is enabled: high

Performances and JS Frameworks

Vue

React

Translations

The Front-End Performance Checklist wants to also be available in other languages! Don't hesitate to submit your contribution!

Comments

  1. David31 July 2020 at 00:34

    Excellent article. Explaining the important points in respect of low, medium, and high levels are really helpful in understanding. More to that, you also provided dozens of tools and plugins as a solution. You can also visit that website url-decode.com for more tools for your help.

    ReplyDelete

Post a Comment

Popular posts from this blog

.NET API

-
autorest  - Swagger (OpenAPI) Specification code generator featuring C# and Razor templates. Supports C#, Java, Node.js, TypeScript, Python and Ruby.  4.5.x or above Flurl  - Fluent URL builder and testable HTTP for .NET  http://tmenier.github.io/Flurl . LightNode  - Micro RPC/REST Framework built on OWIN  http://neuecc.github.io/LightNode . NSwag  - The Swagger API toolchain for .NET, Web API and TypeScript  http://NSwag.org . refit  - The automatic type-safe REST library for Xamarin and .NET  http://paulcbetts.github.io/refit/ . RESTClient .NET  - Simple REST Client for all .NET platforms. RestEase  - Easy-to-use typesafe REST API client library, which is simple and customisable. Swashbuckle  - Seamlessly adds a swagger to WebApi projects. WebAPIContrib for ASP.NET CORE  - Community Contributions for ASP.NET Core. GraphQL graphql-dotnetcore  - GraphQL for .NET Core based on  https://github.com/g...
Read more

.NET Sample Projects

-
AlbumViewerVNext  - West Wind Album Viewer ASP.NET 5 Sample. allReady  - Open-source solution focused on increasing awareness, efficiency and impact of preparedness campaigns as they are delivered by humanitarian and disaster response organizations in local communities.  http://www.htbox.org/projects/allready AspNet5GeoElasticsearch  - ASP.NET Core MVC Geo Elasticsearch Swashbuckle Swagger. aspnet-servicediscovery-patterns  - Samples of implementing Service Discovery patterns with ASP.NET Core. cloudscribe  - ASP.NET Core Multi-tenant web application foundation. distributed-playground  - Distributed service playground with Vagrant, Consul, Docker & ASP.NET Core. DotNetClub  - Tiny club written in ASP.NET Core. Entropy  - Chaotic experimental playground for new features and ideas - check here for small and simple samples for individual features. guidance-identity-management-for-multitenant-apps  - How to manage user identitie...
Read more

How to Write a Shell in C

-
It’s easy to view yourself as “not a  real  programmer.” There are programs out there that everyone uses, and it’s easy to put their developers on a pedestal. Although developing large software projects isn’t easy, many times the basic idea of that software is quite simple. Implementing it yourself is a fun way to show that you have what it takes to be a real programmer. So, this is a walkthrough on how I wrote my own simplistic Unix shell in C, in the hopes that it makes other people feel that way too. The code for the shell described here, dubbed  lsh , is available on  GitHub . University students beware!  Many classes have assignments that ask you to write a shell, and some faculty are aware of this tutorial and code. If you’re a student in such a class, you shouldn’t copy (or copy then modify) this code without permission. And even then, I would  advise  against heavily relying on this tutorial. Basic lifetime of a shell Let’s look at a s...
Read more