[\r\n {\r\n \"resourceSizes\": [\r\n ...\r\n ],\r\n \"resourceCounts\": [\r\n ...\r\n ]\r\n }\r\n]Within the resourceSizes and resourceCounts arrays, you can add individual objects that specify the resourceType and its budget. The budget can be any positive integer and the resourceType can be any of the following:
| Resource type | \nDescription | \n
|---|---|
| script | \nJavaScript files | \n
| document | \nHTML documents | \n
| image | \nImages | \n
| stylesheet | \nCSS files | \n
| font | \nWebfonts | \n
| media | \nOther media | \n
| other | \nAny other resource which doesn’t match the above, e.g. data transfers over Websocket connections | \n
| third-party | \nAll resources from a third-party domain | \n
| total | \nAll resources combined | \n
For example, the following file will set a 200Kb budget for all scripts, a 500Kb for all images, and a 500Kb for all other resources. Then it sets the total network requests to be 25.
\n[\r\n {\r\n \"resourceSizes\": [\r\n {\r\n \"resourceType\": \"script\",\r\n \"budget\": 200\r\n },\r\n {\r\n \"resourceType\": \"image\",\r\n \"budget\": 500\r\n },\r\n {\r\n \"resourceType\": \"total\",\r\n \"budget\": 500\r\n }\r\n ],\r\n \"resourceCounts\": [\r\n {\r\n \"resourceType\": \"total\",\r\n \"budget\": 25\r\n }\r\n ]\r\n }\r\n]As of Lighthouse 5.3 you can add a path property to select which pages the budget should apply to. This is very handy because it allows you to have a centralised budget file for all your pages.
[\r\n {\r\n \"path\":\"/*\",\r\n \"resourceSizes\": [\r\n ...\r\n ],\r\n \"resourceCounts\": [\r\n ...\r\n ]\r\n },\r\n {\r\n \"path\":\"/blog\",\r\n \"resourceSizes\": [\r\n ...\r\n ],\r\n \"resourceCounts\": [\r\n ...\r\n ]\r\n },\r\n {\r\n \"path\":\"/contact\",\r\n \"resourceSizes\": [\r\n ...\r\n ],\r\n \"resourceCounts\": [\r\n ...\r\n ]\r\n }\r\n]How should you choose your numbers?
\nFinding the performance budget is not an easy task since it will depend on your application’s structure and bundling style. However, you can use this useful tool called Performance Budget Calculator to have a starting point. You might have to run the tool multiple time to each to a point where you’d be happy with the result. You don’t want to be too aggressive and also too complacent either.
\nUsing the CI locally
\nYou can install the CI locally with:
\nnpm install -g @lhci/cliIt also has a dashboard which shows you the historical runs, compares reports and store their results.
\nnpm install @lhci/serverBefore running the CI, you need to have a configuration file to tell the tool what to test and where to find the budget file (you could also pass those individually without a config file, but it’d be a pain):
\n// lighthouserc.json\r\n{\r\n \"ci\": {\r\n \"collect\": {\r\n \"numberOfRuns\": 2,\r\n \"startServerCommand\": \"yarn serve\",\r\n \"url\": \"http://localhost:8080\"\r\n },\r\n \"preset\": \"lighthouse:recommended\"\r\n }\r\n}Then you can run the tool on your local web server by first running:
\nlhci autorun --config=./lighthouserc.jsonand then:
\nlhci assert --no-lighthouserc --budgetsFile=budget.jsonAnd you will get a result similar to below based on your app’s performance:
\n2 result(s) for http://localhost:8080/\r\n\r\n × resource-summary.script.size failure for maxNumericValue assertion\r\n Keep request counts low and transfer sizes small\r\n Documentation: https://developers.google.com/web/tools/lighthouse/audits/budgets\r\n\r\n expected: <=102400\r\n found: 2416174\r\n all values: 2416174, 2416174\r\n\r\n\r\n × resource-summary.total.size failure for maxNumericValue assertion\r\n Keep request counts low and transfer sizes small\r\n Documentation: https://developers.google.com/web/tools/lighthouse/audits/budgets\r\n\r\n expected: <=512000\r\n found: 2437694\r\n all values: 2437694, 2437694\r\n\r\nAssertion failed. Exiting with status code 1.Using the tool on your PRs
\nI am focusing on GitHub using actions here. But you can apply this technique to Azure DevOps, CircleCI, TeamCity, or any other tool you’re using. For this to work you will need to have a GitHub flow in your git repository defined.
This article’s focus is not to teach you how to create a workflow, but here is the bare minimum you will need to have. Create a .yaml/.yml file in the .github/workflows folder, you can name it whatever you want. I usually name them after what’s their purpose, e.g. lighthouse.yml or lhci-performance-bot.yml.
But before we get to the content of our yaml file, let’s see what we need to do on each PR:
- \n
- Pull down the code \n
- Build the app \n
- Deploy to a temporary site (I am using Netlify Preview here, but you can use others like staging slots on Azure App Service, etc) \n
- Run Lighthouse CI on the site \n
- Fail if the conditions are not met \n
For this to work, we need an application. So I just spun up a new Vue application using Vue CLI, then added my workflow to it and pushed it to a new GitHub repo.
\nHere is how my workflow looks like:
\nname: Lighthouse CI\r\n\r\non:\r\n pull_request:\r\n branches: [master]\r\n\r\njobs:\r\n lighthouse:\r\n runs-on: ubuntu-latest\r\n\r\n steps:\r\n - uses: actions/checkout@v2\r\n - name: Setup Node 12\r\n uses: actions/setup-node@v1\r\n with:\r\n node-version: 12.x\r\n - name: Yarn Install and Build\r\n run: |\r\n yarn\r\n yarn build\r\n \r\n - name: Waiting for 200 from the Netlify Preview\r\n uses: jakepartusch/wait-for-netlify-action@v1\r\n id: waitFor200\r\n with:\r\n site_name: \"lighthouse-ci-pr\"\r\n\r\n - name: Audit URLs using Lighthouse\r\n uses: treosh/lighthouse-ci-action@v2\r\n with:\r\n urls: |\r\n $DEPLOY_URL/\r\n $DEPLOY_URL/about\r\n runs: 3\r\n budgetPath: ./budget.json\r\n env:\r\n DEPLOY_URL: ${{ steps.waitFor200.outputs.url }}What is happening is that I am just creating an action on each PR. In this action, we need to pull down the code, install node, run yarn and yarn build to build the application, wait for Netlify to deploy our PR into a preview site, then get the URL and inject it into the next step.
I’m just using wait-for-netlify-action, but it’s not that hard to implement this part. Then we will be using the lighthouse-ci-action to run our audit on the paths we have specified.
Notice I am not using a Lighthouse configuration file in this workflow because it’s not needed. You can pass the parameters directly to the action like I’ve done above. I am just auditing the home and about pages since I’ve only got these two pages.
\nYou can pass as many URL’s to this as you like, but if there are many of the, it makes more sense to add the config file back.
\n\n\n💡 Remember to setup Netlify for your site and set it to create a deployment for every PR. Then get the site id and pass it to the
\nwait-for-netlify-actionaction.
Pro tip: When you setup your Vue CLI generated application which is using Vue Router, the non default routes won’t work if the user types them in the browser URL bar and hits enter. That’s because that route is handled on the client side and server doesn’t know about it. To fix that you need to add a URL rewrite rule to return your index.html for all legitimate routes.
In case of Netlify, just create a file named _redirects inside your public and add the following line to it.
/* /index.html 200Result
\nI created a branch and pushed it up. Then created a PR and voila, the action kicked in and failed, since I have a large image on the about page.
\nThis is how it looks like: Now let’s add a twist to this code. Let’s run a bit of code at the same time as the animation is running. We add a button and a handler that calls a function to calculate the Fibonacci number sequence 🤷♂️. So let’s get into it and add the button: And let’s implement the Fibonacci series with a recursive function. Then we will use the Now if you click on the button, you will see that the animation will stop and resume after the call to You can clearly see how users might feel if they face a similar situation on your web application. And this is when the Up until recently, the drawing capabilities of canvas was directly dependent on the To make it even more interesting, the rendering operations can now be run inside a worker, thanks to the aforementioned decoupling. This alone opens the doors of possibilities to all sorts of performance improvements. Web Workers are the web’s version of multi threading. They allow you to run code/tasks in a separate thread (aka background 😁). Now that the decoupling between DOM and Canvas API has landed, we can run it inside a worker. By expanding our previous example, we will add another copy of the same animation, but this time we’ll do the rendering in an We need to setup our worker code in a script (I’ve named No you can create two canvas elements side by side: \r\n Interaction is blocked when a theme is\r\n loading\r\n \r\n Interaction works even if a theme is loading\r\n And finally create the worker from the script tag above, request an animation frame (we used Let’s see what’s happening here. First we need to detect the feature (OffscreenCanvas is not fully supported yet). Next we hook an event handler for our button to put some load on the main thread. This will put some stress on our animation rendering in the main thread. Afterwards, we get our canvas and run the animation code in the main thread, after which, we do the same in our worker. Except that we have to send a message to our worker to get that started (pay attention to the switch case in the worker code). And last but not least, make sure you don’t miss the most important part of the code which is call to Below you can see the whole code in action: We saw the difference in rendering smoothness when using an A while back, Nick Galov from Hostingtribunal.com contacted me to let me know they had created an inforgraphic photo for web performance statistics. This infographic contains some very useful statistics regarding page load time and some advice on where to focus for improvements. This was after I’d given my talk on web performance at NDC Sydney, so the timing was really good. I got so busy during the last couple of months that I rarely blogged and more was focused on my talk for NDC Porto. Here you go, this is the infographic promised to be published on my blog. Hope this helps people find their motive to move towards a faster web. There is a catch however which is not all browsers currently support unicode-range. Fortunately most of the major browsers support it, you will need to have a fallback option. Now if you’re asking how I can determine which subsets I need, the answer is: You can generate the subsets using an open source tool called pyftsubset tool. In addition to that some font services allow manual subsetting via custom query parameters. There are some other opportunities you can leverage apart from subsetting. Let’s say you just need a Google font to show your page title. You can specify which characters to download from that font only using a Some users might already have the fonts installed on their system, so why they should be forced to download the fonts again. You can prevent this by making sure you give precedence to In the above sample note how the By default the fonts are lazy loaded, which means the network request is delayed until the render tree is fully constructed, which in turn results in delayed text rendering. There are three hooks you would need to implement a custom font loading strategy: If there is a high chance that the font is used in the page, then you can load the font eagerly using the platform feature: This will tell the browser that the font should be fetched early, but it won’t specify how to use it. You will need to specify the appropriate CSS For more info on the other solutions refer to this great post. In short these are the points you have to consider when optimising web fonts: Hope this helps you move one more step in the right direction to improve your web application’s performance. Recently I had a chance to present a talk at NDC Sydney about web performance and it received a great feedback. That inspired me to write up a series of posts on each topic I covered in that talk, and who knows, maybe each of these posts would be a talk some day by their own 😃. All other parts: Part 2 use Preload/Prefetch to boost load time Part 3 JavaScript tips and tricks Believe me you don’t want Google to hate your website. Knowing\r\nthe most heavy weight items on every website are images, it is very important to focus on their optimisation. Fortunately, reducing their size is very easy and has massive impact on the overall size of the page. For most of the users on a mobile device, the image quality wouldn’t be so important. Even on a desktop with high resolution there are sacrifices you can make. That’s because human eyes won’t detect certain pixels not being present. As long as you don’t go too far optimising an image to make it ugly, it is a good to continue reducing its size 🤷. Images take more than %50 of a web page’s overall weight 😱. That’s why we should optimise them! Image optimisation is referred to reducing image sizes using different techniques. This will result in the page being loaded faster, hence having a better user experience. Here are some benefits you would gain by optimising your images: The primary goal of image optimisation is to find the balance between file size and image quality. But before we start on optimisation tips, we should understand different image formats and when to use each. There are some newer image formats like WebP and Jpeg2000, but the browser support is not there yet. In summary you should use JPEG for images with lots of colour and PNG for simpler images. This is an example of an image before and after compression. Note how the quality is impacted (you can’t see it in the cat, but around it): Before\r\n For the same reason that you can’t figure out the difference in the cat itself between the first and second image, it is safe to compress image to that degree. Just to let you know the first image is 4mb and the second is only 27kb. 🤷 Now that you know how important it is to compress images and reduce the quality, it is also important to know we have two types of compression: Lossy - this is kind of a filter to eliminate some data from the image, in the above example you could see some loss in the area around the cat. Using this technique, the file size will be reduced to a large degree. Tools such as Adobe Photoshop, Affinity Photo or some free online tools such as Image Compressor will do the trick for you. Lossless - this is a filter that does not eliminate any data, but uses compression only to reduce the size, but it means it requires images to be uncompressed to operate. You can do this easily using tools like FileOptimizer and ImageOptim. You will need to experience it yourself and find the sweet spot for your images. It is a task which requires some work beforehand but saves you a lot of time later. Another thing to consider is to use these tools like ImageOptim in your build process, this way you don’t even need to worry about doing it upfront. And your original images remain untouched. As important as compression is, by itself it can go only so far keeping the same dimension. After you apply the compression you cannot reduce the size with the same width and height anymore. Apart from this, you will need to know that showing a picture with 2000px width on a mobile device is not such a good idea. Especially on smaller devices the human ability to detect changes are far less than when they are looking at a bit monitor with a large aspect ratio. To achieve this you can use the Let’s see what this API offers: The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport. Opposite to the previous technique where you might see some performance impact on the page because of all of those event handlers, this approach is relatively new. This API removes the previous performance hit by doing the math and delivering a very efficient way to call a callback function when the resource is on screen: We attach the observer on all the images we want to be lazy loaded. When the API detects that the element has entered the viewport, using the CSS background images are not as straightforward as the image tag. To load them the browser needs to build both the DOM tree and CSSDOM tree (see here). If the CSS rule is applicable to the node the browser loads it, otherwise doesn’t. So all we need to do is to not give it a background property by default and add it when it’s visible: And: We’ve seen how to reduce the image size using different compression methods, how to load different sizes for different screen sizes and at last how to lazy load them. Using these techniques, you can improve the performance of the page so much it becomes a hobby for you after some time to play with. And as always please spread the word and behold for the next post on web fonts 😃👋. Recently I had a chance to present a talk at NDC Sydney about web performance and it received a great feedback. That inspired me to write up a series of posts on each topic I covered in that talk, and who knows, maybe each of these posts would be a talk some day by their own 😃. All other parts: Part 2 use Preload/Prefetch to boost load time Time to see what we can do for our old friend JavaScript. So let’s begin. With more and more hosting providers supporting HTTP/2, it’s becoming a good time to switch to this protocol instead and benefit from its multiplexed nature. What it means in terms of performance is that we don’t need to bundle all of our JavaScript into large bundles to reduce the number of calls to server. With HTTP/2 designed to handle large number of requests, you can now increase the number of files required to render the page. Not too much tho: Too much of a good thing is a bad thing. As I mentioned before, JavaScript, like CSS is a render blocking element. This simply means the browser needs to wait for it to load and execute before it can parse the rest of the This hugely increases our First Meaningful Pain. In order to fix this issue we can use two of the features which are not used by many people but are very effective. When you use a The This attribute can be used only on external JavaScript files. The file would be downloaded in parallel and once the download is finished, the parsing is paused for the script to be executed: At the end remember to put all of your As for the browser support, fortunately these attributes are fully supported by all of the major ones. Most of the modern sites will bundle all of their JavaScript into one, resulting in an increase in load time and suffering from load performance. Code splitting allows you to split your application code into separate chunks and lazy load them when needed. This also means minimum required code to client and improve the page load time. You can split your code in three areas: Vendor code like Angular, React, moment, etc. can be separated from your main code. Webpack has full support for this and other methods. This technique allows you to have better control over cache invalidation of your bundles whenever your app or vendor code changes independently of one another. This is something every app should do. This technique separates your code by entry points in your app. These points are where bundlers like webpack start from, when they build a dependency tree of your app. This is bar far the easiest way to split code, but it is manual and has some pitfalls: This technique is not suitable for when you have client side routing or when you have a mix of server side rendering and a single page app. Separate code when dynamic This is one of many times when you hear me say it depends (I am a consultant after all 😉). If your app has many routes with isolated functionality and heavily uses frameworks and libraries, this answer is most probably YES. However, it is up to you to decide whether you need it or not by your own understanding of your app structure and code. If you use When using a framework or a library, make sure you investigate wether they have separate modules you can import and if yes, only import what you need. For instance, let’s assume you are using underscore, but only use Instead of this, you could just import what you need: This way you only bring what your need and the bundlers will take care of the rest for you. Your total package size and as a result your page load time will decrease. Ok, enough about the size, let’s see where else we can improve our performance. Many times you have to add an event listener to do something, like listening to page scroll. Then we forget that the listener fires every time the event is triggered. In the above example, the message is printed into console whenever you scroll. Imagine you have some heavy operation in that callback function, this would turn into a big performance bottleneck. If you can’t remove that event listener and use a different approach, then you can use either This feature enforces a function call to not happen until some time has passed since it’s last call. For example, call the function if 100 millisecond has passed from it’s last call. Look at this implementation from underscore: Now we can debounce our event listener for every 100 millisecond: Throttling is similar to debounce but different since it will enforce the maximum number of times a function can be called over a period of time. For example execute this function once every 100 millisecond. Here is a simple implementation: Now we can throttle our scroll event listener: I hope I have given you enough information on just some of the areas you can focus to improve your applications performance when using JavaScript. If you would like to have other topics covered please comment below and I will add them here or in another post. And as always don’t forget to share the ❤️. Recently I had a chance to present a talk at NDC Sydney about web performance and it received a great feedback. That inspired me to write up a series of posts on each topic I covered in that talk, and who knows, maybe each of these posts would be a talk some day by their own 😃. Link to all other parts: Part 3 JavaScript tips and tricks OK, just to recap, here are the rules from part 1: In this part, we’re going to see how we can request our resources before we need them. You might be wondering why we want to do so, and the answer is, if you want to send minimal CSS to client, or any other resource for that matter, you need to break them into smaller pieces and load them separately. There are some techniques which allow you to do it like lazy loading, but with lazy loading, user has to wait (most probably watching a spinner 😏) until the resource is loaded. But, we can do better. One of the letters from PRPL pattern stands for Before we go further into how, let me explain their difference: So by now you should have guessed that If you are trying this for your stylesheet and don’t see your styles get applied, it is because there is a catch when using What happens now is that the styles get applied as soon as the file is loaded. Resources loaded by this technique are loaded after current page is loaded, page load event is finished and bandwidth is available. This means it is ideal for lazy loading future routes’ resources or resources that user might need later. Some use cases are fetching a next page if pagination is used: By the time user clicks on next page button, the page is already loaded and the app feels real fast. To read more about the usage of these features and also know about other useful features, have a look at Google developer’s resource prioritisation page. Same catch applied for So to emphasise why we need to know about these techniques, let me take you back to part one. CSS is a render blocking element, so we need to break it down to the smallest possible chunk which is required to render our main route. Then we can use the above techniques to either load the resource later in the same page without blocking the rendering or to load the resource which is required for our possible next route beforehand and use it when needed. Hope this has helped you to get started with optimising your HTML and CSS loading so far. Next post will be on Alla prossima 😎. Recently I had a chance to present a talk at NDC Sydney about web performance and it received a great feedback. That inspired me to write up a series of posts on each topic I covered in that talk, and who knows, maybe each of these posts would be a talk some day by their own 😃. Link to all other parts: Part 2 use Preload/Prefetch to boost load time Part 3 JavaScript tips and tricks So here we go, part one is about tips and tricks on HTML and CSS to improve the performance. But before we jump into this, you will need to know how browsers render your page. This involves HTML, CSS and JavaScript and steps every browser takes to show your web page to end user. The Critical Rendering Path consists of five steps which are best to be seen in visual: Alright now that you saw it in a picture, let me explain each step in more details. As most of the pages consist of HTML, CSS and JavaScript. Web browsers need to know what and how to show to users and they do this by parsing the HTML page sent over network and constructing a Document Object Model (DOM). They look at HTML tags ( By processing the start and end tags for each token in order, the browser then establishes their hierarchy (parent and child). This is way simpler than it looks, in the picture above imagine DOM to be a bit tree with all the nodes (branches) and their children (leaves). This tree contains all the dependencies of nodes to construct our HTML: Image from W3C website The DOM represents your whole markup and is built incrementally by the browser. As of HTML5 the browsers support streaming HTML instead of waiting for the whole page to get sent to browser in one go. This is great because it helps the rendering to be done at the same time as the bytes are arrived. After constructing the DOM, browser looks at any style which is referenced in the page to build the CSS Object Model (CCCOM). CCCOM describes the style rules that need to be applied to the document. This is very similar to how DOM was built, however, in this process each child inherits the styles applied to its parent - hence the name cascading style sheets. Partial processing of styles is not possible so browsers need to wait for all the style rules to be sent over before they can start inferring what rule is applied to which nodes. This is the reason why CSS is a render blocking element. Mix of DOM and CCCOM is something called the Render Tree. This tree includes all the nodes and their dependencies plus all the CSS rules which are applied to those. After constructing all the nodes, browser needs to know which ones to show on the page. Render Tree is exactly the representation visible content on the page. The browser stars from the root and then copies all the visible nodes from DOM and CCCOM. The steps taken are roughly as below: Image from Google Developers Now that we have all the nodes with their styles, it’s time to figure out where to put them on screen. This is exactly what layout step is. The first thing which is needed is the browser window size. This is the basis for all the following calculations, since the layout depends on it to know the position and dimension of each element. The output of this step is the Box Model which captures the exact position and size of it, plus their margin, padding, border and etc. This step will be repeated by each change to size or when we switch between landscape and portrait on a mobile device. This step is the last one where pixels are painted on screen which can take some time because the browser has quite a lot of work to do. This time depends on window size, how much style is applied to each node, the hardware used on device and so on. When this step is finished, the page is finally visible in the viewport. Ok, enough with Critical Rendering Path, let’s see how we can improve the web performance with tweaks on HTML and CSS. When sending HTML to client try to flush the buffer often instead of once at the end. This means chunks of HTML would arrive and browser can parse them as they arrive not at the end. This will help to boost the performance. As an example, when Minifying and compressing is really important since it can reduce the payload size and reduce the HTTP response time which in turn results in better load time. These techniques along with the right caching strategy can massively help the web performance to be improved. As you saw CSS is a render blocking element, so it should be sent down to client as early as possible. Also think of how much CSS is needed on first page load, extract the unused CSS from the main file and load them separately and later when needed. You can also use pre-loading/pre-caching to improve the performance. These are part of PRPL pattern which was introduced by Google in 2016. Another technique which is not used as often by developers is to use link tags inside body along with content. This is really useful as you can send a minimum amount of CSS to client even inside your HTML in a In short, keep your recourses minimum and send them fast and optimum. Try to cut down unused CSS rules and use minification and compression to speed up the transfer. Hope you’ve enjoyed reading this and are looking forward for the rest of the series 😉. Spoiler alert: we cannot compare these two as they are different in nature, but, I try to go through some points you to need to consider, when choosing a front end technology. When you deploy your app you probably want to delay sending unnecessary files to client and increase the page load speed. Well if that’s the case Angular has very little support for that as you can lazy load html templates. Although you can do so for the JS files but you eventually end up with a spaghetti code which is hard to maintain and also takes some time to completely address what you need. In this area React is the winner as it simply is JS and doesn’t care, you can lazy load files with RequireJS and also integrate with frameworks like WebPack. I think learning Angular would take more time than React. As some people including me have experienced you can learn React to a good extent in about a week. With Angular, however, it takes some time to learn the basics and then it gets harder as you go like a marriage. Good abstraction is priceless. Abstraction provides fast development and hides details that are not necessary for the developer using a library. Angular is week in keeping people away from its model state as so many developers have had to debug its internal state as they were debugging their code. React’s abstraction has led to it being less flexible like not be able to add attributes to Html tags (which I think is fixed by mixins implementation). However in total React is the winner. Data model complexity is another factor which means how it is structured to be shown in view later on. Angular is suffering from relying heavily in scope because of the copy-n-compare. React gives you the ability to choose without facing performance hits and the outcome depends on whether you are a good or bad coder. Next thing to consider is binding. Angular allows you to bind only to model. This means that you cannot bind to a server/async service. If you want to do that you have to have intermediate models and even then you will suffer from the explicit watches and digest cycle. React on the other hand provides syntactic sugar for binding which is called valueLink. It is a single attribute for both “Value” and “onChange” properties. This is so simple to believe that it is doing what you want but it does and if you understand it well, you can implement any of your needs easily. Then it comes debugging. With debugging you want to achieve mostly two things. First why you logic is not working and second why the HTML outcome does not look like what you wanted to be. Angular does a good job of providing constructs that are logical, like services. If used correctly, they make the code easier to test and debug, but any good programmer will try to separate code and logic with or without them. React has two main scenarios - updating the model/doing other actions as a result of user events; and the one-way rendering flow which is always the same. This means that there are fewer places to look for your bugs and the stack traces have clear distinction between React’s code, and your own. They normally don’t mix. React also has less magic, and it’s all concentrated in one place - the vDom comparison. It is a closed black box but in our experience, it worked as expected. Time to discuss performance tweaking. In Angular you need to count the number of scopes, global scope variables and functions (which makes scope heavy and sometimes tided to other scopes) and in some cases you have to implement a component in pure js as you can find heaps of articles on Angular perf tuning. On the other hand React makes it easy to take control of performance by letting you choose between customising when the DOM should be updated by yourself or let React take care of it by a simple comparison of the vDOM. Of course if your model if complex you need to do it yourself by implementing a custom ShouldComponentUpdate method to use efficient way of doing state and dirty checks. Next comes my favourite Code Reuse. No one can deny the fact that there are thousands of libraries ready to use for Angular. The point here is to not use too many libraries from different vendors due to namespace and priority collisions. React lets you do that by creating reusable components and it is super easy to create complex hierarchical component structures that can be used for future needs. But the winner is Angular as you can almost find anything from a simple date only directive to a complex file upload with background ajax calls to upload your file with nice UI which has progress bar and everything. Templating is another important feature of any front end framework. Angular is a clear winner in this case but not in all aspects and you will see why when I walk you through an example. Imagine that you are writing a repeater which looks like this in React: In Angular this will be like: Which one is better to you? The question here will be how do we get advantage of all of React’s benefits while preserving this great feature of Angular. The answer is by using rt pre-compiled templates. You can find more information on this here. Thanks to this awesome feature the code above will become: And this is a true if expression which means this will not render if the condition is false: It is nice, isn’t it. Now wait for this sugar: Also for transclusion: And handling events: Conclusion: It seems that the question is wrong basically because each framework has something special to offer and is used it a specific scenario. Also you can combine them together (we’ve done that in one project and it is very nice and easy to get done) to use the React’s fast rendering experience along with end-to-end features of Angular. Of course there are a lot of other ways to combine React with other techs to replace Angular but they have their own pros and cons.var mainCanvas = document.getElementById(\r\n 'myCanvas'\r\n)\r\nvar mainContext = mainCanvas.getContext('2d')\r\n\r\nvar canvasWidth = mainCanvas.width\r\nvar canvasHeight = mainCanvas.height\r\n\r\nvar angle = 0\r\n\r\nvar requestAnimationFrame =\r\n window.requestAnimationFrame ||\r\n window.mozRequestAnimationFrame ||\r\n window.webkitRequestAnimationFrame ||\r\n window.msRequestAnimationFrame\r\n\r\nfunction drawCircle() {\r\n mainContext.clearRect(\r\n 0,\r\n 0,\r\n canvasWidth,\r\n canvasHeight\r\n )\r\n\r\n // color in the background\r\n mainContext.fillStyle = '#EEEEEE'\r\n mainContext.fillRect(\r\n 0,\r\n 0,\r\n canvasWidth,\r\n canvasHeight\r\n )\r\n\r\n // draw the circle\r\n mainContext.beginPath()\r\n\r\n var radius =\r\n 25 + 150 * Math.abs(Math.cos(angle))\r\n mainContext.arc(\r\n 225,\r\n 225,\r\n radius,\r\n 0,\r\n Math.PI * 2,\r\n false\r\n )\r\n mainContext.closePath()\r\n\r\n // color in the circle\r\n mainContext.fillStyle = '#006699'\r\n mainContext.fill()\r\n\r\n angle += Math.PI / 64\r\n\r\n requestAnimationFrame(drawCircle)\r\n}\r\n\r\ndrawCircle()<button type=\"button\" id=\"make-busy\">\r\n Hit the main thread!\r\n</button>requestAnimationFrame to make sure this code is run on the next available repaint. For more info on requestAnimationFrame, make sure to check out the documentation.function fibonacci(num) {\r\n if (num <= 1) return 1\r\n\r\n return fibonacci(num - 1) + fibonacci(num - 2)\r\n}\r\n\r\ndocument\r\n .querySelector('#make-busy')\r\n .addEventListener('click', () => {\r\n document.querySelector('#busy').innerText =\r\n 'Main thread working...'\r\n requestAnimationFrame(() => {\r\n requestAnimationFrame(() => {\r\n fibonacci(40)\r\n document.querySelector(\r\n '#busy'\r\n ).innerText = 'Done!'\r\n })\r\n })\r\n })fibonacci function is returned.OffscreenCanvas can help.OffscreenCanvas
\n<canvas> element which meant it would depend on DOM (Document Object Model). OffscreenCanvas on the other hand, decouples DOM and Canvas API by moving it’s operations off screen.Using it in a worker
\nOffscreenCanvas in a web worker.animation.js) which we can use later. First we need to move our animation code to its own file. Then let’s create our worker code:let animationWorker = null\r\nself.onmessage = function(e) {\r\n switch (e.data.msg) {\r\n case 'start':\r\n if (!animationWorker) {\r\n importScripts(\r\n e.data.origin + '/animation.js'\r\n )\r\n animationWorker = new ThemedAnimation(\r\n e.data.canvas.getContext('2d')\r\n )\r\n }\r\n animationWorker.start()\r\n break\r\n case 'stop':\r\n if (!animationWorker) {\r\n return\r\n }\r\n animationWorker.stop()\r\n break\r\n }\r\n}Canvas on main thread
\r\n Canvas on worker thread
\r\n <main>\r\n <section class=\"support\">\r\n Your browser does not support OffscreenCanvas.\r\n </section>\r\n <div>\r\n <h1>Canvas on main thread</h1>\r\n <p>\r\n Interaction is blocked when a theme is\r\n loading\r\n </p>\r\n <canvas\r\n id=\"canvas-window\"\r\n width=\"400\"\r\n height=\"400\"\r\n ></canvas>\r\n </div>\r\n <div>\r\n <h1>Canvas on worker thread</h1>\r\n <p>\r\n Interaction works even if a theme is loading\r\n </p>\r\n <canvas\r\n id=\"canvas-worker\"\r\n width=\"400\"\r\n height=\"400\"\r\n ></canvas>\r\n </div>\r\n</main>setTimeOut previously), and run the animation in both canvases at the same time.document\r\n .querySelector('main')\r\n .classList.toggle(\r\n 'supported',\r\n 'OffscreenCanvas' in window\r\n )\r\ndocument\r\n .querySelector('#make-busy')\r\n .addEventListener('click', () => {\r\n document.querySelector('#busy').innerText =\r\n 'Main thread working...'\r\n requestAnimationFrame(() => {\r\n requestAnimationFrame(() => {\r\n Animation.fibonacci(40)\r\n document.querySelector(\r\n '#busy'\r\n ).innerText = 'Done!'\r\n })\r\n })\r\n })\r\n\r\nconst canvas = document.querySelector('#case1')\r\nconst animationWindow = new Animation(\r\n document\r\n .querySelector('#canvas-window')\r\n .getContext('2d')\r\n)\r\nanimationWindow.start()\r\nconst workerCode = document.querySelector(\r\n '#workerCode'\r\n).textContent\r\nconst blob = new Blob([workerCode], {\r\n type: 'text/javascript',\r\n})\r\nconst url = URL.createObjectURL(blob)\r\nconst worker = new Worker(url)\r\nconst offscreen = document\r\n .querySelector('#canvas-worker')\r\n .transferControlToOffscreen()\r\nconst urlParts = location.href.split('/')\r\nif (\r\n urlParts[urlParts.length - 1].indexOf('.') !==\r\n -1\r\n) {\r\n urlParts.pop()\r\n}\r\nworker.postMessage(\r\n {\r\n msg: 'start',\r\n origin: urlParts.join('/'),\r\n canvas: offscreen,\r\n },\r\n [offscreen]\r\n)\r\nURL.revokeObjectURL(url) // cleanuptransferControlToOffscreen on the canvas. This is where the magic of OffscreenCanvas happens. This method converts our regular canvas into an OffscreenCanvas instance.Summary
\nOffscreenCanvas in comparison with running the same on the main thread. This amazing feature can be used alongside all of the other techniques in my previous posts on web performance to help you have a faster website and happier customers 😊.What happened
\nWhat next
\n@font-face {\r\n font-family: 'Awesome Font';\r\n font-style: normal;\r\n font-weight: 400;\r\n src: local('Awesome Font'),\r\n url('/fonts/awesome-l.woff2') format('woff2'),\r\n url('/fonts/awesome-l.woff') format('woff'),\r\n url('/fonts/awesome-l.ttf') format('truetype'),\r\n url('/fonts/awesome-l.eot') format('embedded-opentype');\r\n unicode-range: U+000-5FF; /* Latin glyphs */\r\n}\r\n\r\n@font-face {\r\n font-family: 'Awesome Font';\r\n font-style: normal;\r\n font-weight: 400;\r\n src: local('Awesome Font'),\r\n url('/fonts/awesome-jp.woff2') format('woff2'),\r\n url('/fonts/awesome-jp.woff') format('woff'),\r\n url('/fonts/awesome-jp.ttf') format('truetype'),\r\n url('/fonts/awesome-jp.eot') format('embedded-opentype');\r\n unicode-range: U+3000-9FFF, U+ff??; /* Japanese glyphs */\r\n}local() directive allows you to reference, load, and use locally installed fonts. The url() directive allows you to load external fonts, and are allowed to contain an optional format() hint indicating the format of the font referenced by the provided URL.\n
\n@font-face rules.&text= syntax:<link\r\n href=\"//fonts.googleapis.com/css?family=Roboto&text=log\"\r\n rel=\"stylesheet\"\r\n/>l, o, and g will be shown on Roboto.@font-face {\r\n font-family: 'Roboto';\r\n src: local('Roboto'), local('Roboto'),\r\n url(fonts/Roboto.woff2) format('woff2'), url(fonts/Roboto.woff)\r\n format('woff');\r\n}Always check for the font locally
\nlocal() in the src attribute of font face rule.src: local is used before the url.Optimnising the loading and rendering
\n\n
\n<link rel=preload>font-display propertyPreload your web font
\n<link rel=preload>.@font-face:<link\r\n rel=\"preload\"\r\n href=\"/fonts/Roboto.woff2\"\r\n as=\"font\"\r\n/>@font-face {\r\n font-family: 'Awesome Font';\r\n font-style: normal;\r\n font-weight: 400;\r\n /* will be preloaded */\r\n src: local('Awesome Font'),\r\n url('/fonts/awesome-l.woff2') format('woff2'),\r\n url('/fonts/awesome-l.woff') format('woff'),\r\n url('/fonts/awesome-l.ttf') format('truetype'),\r\n url('/fonts/awesome-l.eot') format('embedded-opentype');\r\n unicode-range: U+000-5FF; /* Latin glyphs */\r\n}Summary
\n\n
\nlocal() in your src list.<link rel=\"preload\">, font-display, or the Font Loading API.Intro
\n\n
\n\n\n
\n\n \n\n\n\n \n\nAverage bytes per page 2018 \nWhat does image optimisation mean
\nWhy bother
\n\n
\nLet’s optimise them
\nChoose the right format
\n\n
\nSize vs Compression
\nLossy vs Lossless Optimisation
\n\n
\nUsing the right dimension
\nsrcset and width descriptors attribute in HTML. With this, you can mention multiple screen sizes and specify which image to use for each size.\n \n\n\nSize: 81.4KB \n
\n\n\n
\n \n\n\nPNG \n\n document.addEventListener(\r\n 'DOMContentLoaded',\r\n function() {\r\n var lazyloadImages = document.querySelectorAll(\r\n 'img.lazy'\r\n )\r\n var lazyloadThrottleTimeout\r\n\r\n function lazyload() {\r\n if (lazyloadThrottleTimeout) {\r\n clearTimeout(lazyloadThrottleTimeout)\r\n }\r\n\r\n lazyloadThrottleTimeout = setTimeout(\r\n function() {\r\n var scrollTop = window.pageYOffset\r\n lazyloadImages.forEach(function(img) {\r\n if (\r\n img.offsetTop <\r\n window.innerHeight + scrollTop\r\n ) {\r\n img.src = img.dataset.src\r\n img.classList.remove('lazy')\r\n }\r\n })\r\n if (lazyloadImages.length == 0) {\r\n document.removeEventListener(\r\n 'scroll',\r\n lazyload\r\n )\r\n window.removeEventListener(\r\n 'resize',\r\n lazyload\r\n )\r\n window.removeEventListener(\r\n 'orientationChange',\r\n lazyload\r\n )\r\n }\r\n },\r\n 20\r\n )\r\n }\r\n\r\n document.addEventListener('scroll', lazyload)\r\n window.addEventListener('resize', lazyload)\r\n window.addEventListener(\r\n 'orientationChange',\r\n lazyload\r\n )\r\n }\r\n)Using intersection API
\n\n
\ndocument.addEventListener(\r\n 'DOMContentLoaded',\r\n function() {\r\n var lazyloadImages\r\n\r\n if ('IntersectionObserver' in window) {\r\n lazyloadImages = document.querySelectorAll(\r\n '.lazy'\r\n )\r\n var imageObserver = new IntersectionObserver(\r\n function(entries, observer) {\r\n entries.forEach(function(entry) {\r\n if (entry.isIntersecting) {\r\n var image = entry.target\r\n image.src = image.dataset.src\r\n image.classList.remove('lazy')\r\n imageObserver.unobserve(image)\r\n }\r\n })\r\n }\r\n )\r\n\r\n lazyloadImages.forEach(function(image) {\r\n imageObserver.observe(image)\r\n })\r\n } else {\r\n var lazyloadThrottleTimeout\r\n lazyloadImages = document.querySelectorAll(\r\n '.lazy'\r\n )\r\n\r\n function lazyload() {\r\n if (lazyloadThrottleTimeout) {\r\n clearTimeout(lazyloadThrottleTimeout)\r\n }\r\n\r\n lazyloadThrottleTimeout = setTimeout(\r\n function() {\r\n var scrollTop = window.pageYOffset\r\n lazyloadImages.forEach(function(img) {\r\n if (\r\n img.offsetTop <\r\n window.innerHeight + scrollTop\r\n ) {\r\n img.src = img.dataset.src\r\n img.classList.remove('lazy')\r\n }\r\n })\r\n if (lazyloadImages.length == 0) {\r\n document.removeEventListener(\r\n 'scroll',\r\n lazyload\r\n )\r\n window.removeEventListener(\r\n 'resize',\r\n lazyload\r\n )\r\n window.removeEventListener(\r\n 'orientationChange',\r\n lazyload\r\n )\r\n }\r\n },\r\n 20\r\n )\r\n }\r\n\r\n document.addEventListener(\r\n 'scroll',\r\n lazyload\r\n )\r\n window.addEventListener('resize', lazyload)\r\n window.addEventListener(\r\n 'orientationChange',\r\n lazyload\r\n )\r\n }\r\n }\r\n)isIntersecting property, we pick the URL from the data-src attribute and move it to the src attribute for the browser to trigger the image load like before. Once this is done, we remove the lazy class from the image and also remove the observer from that image.CSS background image
\ndocument.addEventListener(\r\n 'DOMContentLoaded',\r\n function() {\r\n var lazyloadImages\r\n\r\n if ('IntersectionObserver' in window) {\r\n lazyloadImages = document.querySelectorAll(\r\n '.lazy'\r\n )\r\n var imageObserver = new IntersectionObserver(\r\n function(entries, observer) {\r\n entries.forEach(function(entry) {\r\n if (entry.isIntersecting) {\r\n var image = entry.target\r\n image.classList.remove('lazy')\r\n imageObserver.unobserve(image)\r\n }\r\n })\r\n }\r\n )\r\n\r\n lazyloadImages.forEach(function(image) {\r\n imageObserver.observe(image)\r\n })\r\n } else {\r\n var lazyloadThrottleTimeout\r\n lazyloadImages = document.querySelectorAll(\r\n '.lazy'\r\n )\r\n\r\n function lazyload() {\r\n if (lazyloadThrottleTimeout) {\r\n clearTimeout(lazyloadThrottleTimeout)\r\n }\r\n\r\n lazyloadThrottleTimeout = setTimeout(\r\n function() {\r\n var scrollTop = window.pageYOffset\r\n lazyloadImages.forEach(function(img) {\r\n if (\r\n img.offsetTop <\r\n window.innerHeight + scrollTop\r\n ) {\r\n img.src = img.dataset.src\r\n img.classList.remove('lazy')\r\n }\r\n })\r\n if (lazyloadImages.length == 0) {\r\n document.removeEventListener(\r\n 'scroll',\r\n lazyload\r\n )\r\n window.removeEventListener(\r\n 'resize',\r\n lazyload\r\n )\r\n window.removeEventListener(\r\n 'orientationChange',\r\n lazyload\r\n )\r\n }\r\n },\r\n 20\r\n )\r\n }\r\n\r\n document.addEventListener(\r\n 'scroll',\r\n lazyload\r\n )\r\n window.addEventListener('resize', lazyload)\r\n window.addEventListener(\r\n 'orientationChange',\r\n lazyload\r\n )\r\n }\r\n }\r\n)#bg-image.lazy {\r\n background-image: none;\r\n background-color: #f1f1fa;\r\n}\r\n#bg-image {\r\n background-image: url('path/to/some/cat/image.jpg');\r\n max-width: 600px;\r\n height: 400px;\r\n}Summary
\nSwitch to HTTP/2
\n\n
\nAsync & Defer
\nHTML document.Normal execution
\n<script> to load a JavaScript file, it interrupts the parsing of the document. Browser fetches the resource, executes this and then continues on paring:The
\nAsync attributeAsync attribute is used to indicate that this resource can be executed asynchronously. The parsing doesn’t need to be halted, it can be done right after the resource is fetched from network and is ready.<script async src=\"script.js\">script tags right at the end of the body to prevent more delay in parsing your HTML.Code splitting
\n\n
\nVendor code
\nEntry point
\n\n
\nDynamic splitting
\nimport are used. This is the best option for single page applications. Having different modules for different routes in your SPA is an example of this.Do I even need code splitting?
\nImport wisely
\nnpm or other package management systems for your dependencies, then you will have a lot of extra and unneeded files in your buid folder.groupBy, shuffle, and partition. Most people import the whole library like this:import * as _ from 'underscore'import {\r\n groupBy,\r\n shuffle,\r\n partition,\r\n} from 'underscore'Throttling and debounce
\nwindow.addEventListener('scroll', function() {\r\n console.log('page scrolled')\r\n})debounce or throttle to alleviate the situation.Debounce
\nconst debounce = (func, delay) => {\r\n let inDebounce\r\n return function() {\r\n const context = this\r\n const args = arguments\r\n clearTimeout(inDebounce)\r\n inDebounce = setTimeout(\r\n () => func.apply(context, args),\r\n delay\r\n )\r\n }\r\n}var efficientScrollListener = debounce(\r\n function() {\r\n console.log('page scrolled')\r\n },\r\n 100\r\n)\r\n\r\nwindow.addEventListener(\r\n 'scroll',\r\n efficientScrollListener\r\n)Throttle
\nconst throttle = (func, limit) => {\r\n let inThrottle\r\n return function() {\r\n const args = arguments\r\n const context = this\r\n if (!inThrottle) {\r\n func.apply(context, args)\r\n inThrottle = true\r\n setTimeout(\r\n () => (inThrottle = false),\r\n limit\r\n )\r\n }\r\n }\r\n}var efficientScrollListener = throttle(\r\n function() {\r\n console.log('page scrolled')\r\n },\r\n 100\r\n)\r\n\r\nwindow.addEventListener(\r\n 'scroll',\r\n efficientScrollListener\r\n)So what
\n\n
\npre-cache. An effective way to load your resources before they are required, cache them and then use them when they are needed. We can achieve this using preload and prefetch features of browsers.Preload
\n<link rel=\"preload\"> tells the browser that the resource should be loaded as part of the current navigation and it should start fetching it ASAP. This attribute can be applied to CSS, fonts, images, JavaScript files and more. When using this attribute you will also tell the browser what file type this file has, which can be set in an as attribute:<link\r\n rel=\"preload\"\r\n as=\"script\"\r\n href=\"super-important.js\"\r\n/>\r\n<link\r\n rel=\"preload\"\r\n as=\"style\"\r\n href=\"critical.css\"\r\n/>preload is used in the current route and resources fetched via this technique are very important. The difference between using rel=preload and rel=stylesheet is that browser will know about that resource way ahead of time allowing the download to start sooner.preload which is the browser downloads the resource but won’t apply it until we tell it to. To get it working you will need a bit of JavaScript:<link\r\n rel=\"preload\"\r\n as=\"style\"\r\n href=\"critical.css\"\r\n onload=\"this.rel='stylesheet'\"\r\n/>Prefetch
\n<link rel=\"prefetch\"> is different from <link rel=\"preload\"> in that it is not trying to load a critical resource faster, it is trying to load a non-critical resource sooner.<link rel=\"prefetch\" href=\"page-2.html\" />prefetch as well. But since we are loading a resource which is required potentially for a different route, you might have a separate rel=stylesheet on that page which uses this in memory file or in case of a SPA just set the rel to stylesheet when the route is loaded.When to use these
\nJavaScript and what we can do there to improve our web application’s performance.The Critical Rendering Path
\nBuilding DOM and CCCOM
\n<p></p>, <div></div>, <h1></h1>) and convert them to tokens. These tokens are then converted to nodes in parallel.![\"Document](\"/2c902bcd526dc480e0cd902e1381fcc1/DOM.gif\")
Render Tree
\n\n
\n\n
\ndisplay: noneLayout
\nPaint
\nSo what
\nStream HTML to client
\nHEAD tag is arrived browser can send other requests for assets while the rest of the HTML is arriving.Size matters
\nSend the CSS early and keep it minimal
\nstyle tag and then load the rest later when needed to improve the render time.Summary
\nResources
\n\n
","timeToRead":4,"frontmatter":{"title":"Improve HTML and CSS performance","unformattedDate":"2018-09-29T00:00:00.000Z","date":"Sep 29, 2018","path":"web-perf-1/","author":"Yaser Adel Mehraban","tags":["web","performance","html","css"],"thumbnail":{"childImageSharp":{"gatsbyImageData":{"layout":"constrained","placeholder":{"fallback":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAOABQDASIAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAAAAIDBAX/xAAVAQEBAAAAAAAAAAAAAAAAAAAAAf/aAAwDAQACEAMQAAAB7aWimgQX/8QAGRABAAIDAAAAAAAAAAAAAAAAAQIRAAMS/9oACAEBAAEFAmg1T7jiWVHXkXo//8QAFBEBAAAAAAAAAAAAAAAAAAAAEP/aAAgBAwEBPwE//8QAFBEBAAAAAAAAAAAAAAAAAAAAEP/aAAgBAgEBPwE//8QAFxAAAwEAAAAAAAAAAAAAAAAAABEg4f/aAAgBAQAGPwLYYz//xAAcEAADAAEFAAAAAAAAAAAAAAAAAREhEDFBYXH/2gAIAQEAAT8hW52ejrGuNFSY0MN3MCYD/9oADAMBAAIAAwAAABAAD//EABYRAQEBAAAAAAAAAAAAAAAAAAEQEf/aAAgBAwEBPxBHZ//EABQRAQAAAAAAAAAAAAAAAAAAABD/2gAIAQIBAT8QP//EABwQAQADAAIDAAAAAAAAAAAAAAEAESEQMUGh8f/aAAgBAQABPxBUxHf0htYKTS5474UHY+oLDaBQzJWRC62f/9k="},"backgroundColor":"transparent","images":{"fallback":{"src":"/static/f7498c20b7bc9bf0825914e963e06b46/414c8/WebPerformance.jpg","srcSet":"/static/f7498c20b7bc9bf0825914e963e06b46/414c8/WebPerformance.jpg 448w","sizes":"(min-width: 448px) 448px, 100vw"},"sources":[{"srcSet":"/static/f7498c20b7bc9bf0825914e963e06b46/cfb46/WebPerformance.webp 448w","type":"image/webp","sizes":"(min-width: 448px) 448px, 100vw"}]},"width":448,"height":311}}}}}},{"node":{"id":"0955b60a-f44d-5cc2-b476-79548854cc48","html":" {this.props.items.map(createItem)}
`, `69538522002416255000`)\"\n >\n var createItem = function(itemText) {\r\n return <li> {itemText} </li>\r\n}\r\n\r\nreturn <ul> {this.props.items.map(createItem)} </ul><ul>\r\n <li ng-repeat=\"item in items\"><span ng-bind=\"item\"></span></li>\r\n</ul><ul>\r\n <li rt-repeat=\"item in items\">{item} at index {itemIndex}</li>\r\n</ul><label rt-if=\"chips.isGoodForHealth\"> I don't think so </label>
\r\n Last viewed at:\r\n '25-11-2015'}"\r\n >{item.lastSeen}\r\n`, `45717313012831900000`)\"\n >\n <div rt-scope=\"this.getItems() as items\" title=\"{item.title}\">\r\n Item Description: {item.description}<br />\r\n Last viewed at:\r\n <span rt-class=\"{status:true, lasSeen:this.lastSeen(item) > '25-11-2015'}\"\r\n >{item.lastSeen}</span\r\n >\r\n</div><span>{this.props.children}</span><div>\r\n <div\r\n rt-repeat=\"task in tasks\"\r\n style=\"font-weight:{task.selected ? 'bold' : 'normal' }\"\r\n onClick=\"() => this.toggleTask(task)\"\r\n >\r\n {task.title}\r\n </div>\r\n <button onClick=\"{this.save}\">Save</button>\r\n</div>