DEV Community: Lyubomir Angelov

Vbox7.com - quick performance audit

Lyubomir Angelov — Tue, 18 Feb 2020 21:57:21 +0000

Intro

I was curious what is the speed performance of Vbox7.com website, a vastly visited website in Bulgaria. Vbox7.com is video platform just like Youtube.com but only with Bulgarian content. In December 2019 the total (desktop, mobile & APPs) visits are 3 200 000, quite a lot, more info you can find on their page here.

Based on that I decided to not spend too much time and do quick performance analysis on the website.

Images

With this number of visits and the huge amount of images and videos played, they should have lots of servers and lots of bandwidth that goes through them.

That's why I went through a few pages using Webpagetest and Cloudinary Image Analysis results.

Logo

The logo is an SVG file, which is very good, but what they can do is to inline it, compress it (remove unnecessary tags, comments, attributes) and make it smaller.

Compression and Format

They can implement a few things for dynamically generated images eg. video posters:
- better compression like mozJPEG for JPEGs
- provide right type and format using <picture> tag - Webp

This should decrease the average total image size per page approximately 2.5 MB!

Lazy load images

Open this Webpagetest result and you will see that this page have ~306 requests, of which 113 are images.

If they implement lazy load on images, the total amount of images per page can drop to ~30!

The CDN

As Patrick Meenan says, most of out there CDNs do not do proper HTTP2 prioritization, thus make slower load times of images and other requests. On this website, the prioritization is terrible.
By simple look how to test http2 prioritization I managed to test their CDN i49.vbox7.com and the results are quote "EPIC FAIL", you can check in the test here.

I will stop here, they have lots of room for performance improvements if you only do a quick look at the pages. :)

Can I ask Why

Why they don't do it, why they are not spending several hours to implement few basic optimisations on the pages and deliver better user experience, less user traffic spent and fewer costs for servers?

Case Study: React partial SSR with SFCC

Lyubomir Angelov — Wed, 15 Jan 2020 18:06:15 +0000

Case Study: React partial SSR with SFCC

React partial SSR in restricted cloud CMSs

This case study will show a way to implement partial Server-Side Rendering (SSR) and achieve performance gains without big investments for middleware in cloud-based platforms.

All cloud CMSs like Salesforce Commerce Cloud (SFCC) and Magento have their pros and cons. In those CMSs, we have lots of restrictions, but the major one for the purposes of this article is that we do not have access to the server, so we can't use Server-Side Rendering.

SFCC (ex Demandware) is cloud-based unified e-commerce platform for B2C retailers. Its core is written in Java but clients can extend it with JavaScript which they transpile to Java.

Our application is built with React and consumes JSON API returned from our headless SFCC.

If we want the performance gains of the SSR we have two options:

Create middleware between the React app and the backend SFCC
Create Partial SSR with what you have from the system

In our project, we can't go with option 1 because of budget, resources and time. That's why we chose option 2. This post describes what we did, but first, let's start with some background information.

React, SSR, Hydration, Progressive Hydration

If our goal is to make our React website fast, one of the best things we can do is to use Server-Side Rendering (SSR) for the whole application. For this to work, we need control over the server where the application is hosted and render the React app using, for example, Next.js or NodeJS.

SSR generates complete HTML for the page and returns it to the browser.

<html>
  <head>
    Some meta, CSS, scripts, third-parties etc.
  </head>
  <body>
    <div id="app">
      <div id="app-root">
        <header>
          Logo, username etc.
          <nav>The navigation items</nav>
        </header>
        <div id="app-container">
          All the content between header and footer
        </div>
        <footer>
          Copyright and links stuff
        </footer>
      </div>
    </div>
  </body>
</html>

That's ok, now we just need to use hydration to let React attach all events handlers that it needs.

ReactDOM.hydrate(element, container[, callback])

With that, we get approximately 20% faster in most of the metrics - LCP, Speed Index and TTI - but we will get a little bit slower Time to first byte (TTFB) because the backend needs additional time to SSR the application.

But we can improve the app even further: we can apply React Progressive Hydration (which I won't discuss in detail, there are lots of articles about it:
Dan Abramov Progressive Hydration demo,
Progressive React,
SSR React and Hydration).

What is Progressive Hydration?

With Progressive Hydration React can attach only the events for elements that are visible in the initial viewport, so we can further reduce JavaScript's execution time.

Problems

Since we're using SFCC we are not able to do the SSR described above, that's why we had to think about what we can do in order to achieve similar results as if we had SSR.

Our Homepage and Category Landing Pages are pure HTML, CSS and a little bit of JavaScript that is created in the CMS from WYSIWYG editor, again the limitation of the platform. This content is created by the third party which is responsible for the whole dynamic content on the platform. Then this content (HTML, CSS, JS) is provided with JSON API that the React app gets and fills the app-container div.

Example:

let content = {
                "result": {
                    "html": "ENCODED HTML/CSS/JS from the WYSIWYG editor"
                }
            }

render() {
    return (
        <div dangerouslySetInnerHTML={ __html: content.result.html } />
    )
}

Because of that approach, the end result that the customers are seeing is this:

Problem one

What we can return directly from the backend is the HTML below, which is not enough for the React app to hydrate.

<html>
  <head>
    Some meta, CSS, scripts, third-parties etc.
  </head>
  <body>
    <div id="app-shell">Static Header</div>
    <div id="app-container">
      Content between header and footer
    </div>
    <div id="app"></div>
  </body>
</html>

Problem two

In order to use React and the hydration mode, we must provide the whole DOM structure of the React-generated HTML.
It is React app, almost every HTML is generated by the React and the JSON API that he consumes. With that, we don't have for example the HTML of the <header> and <footer>. This is the maximum of what we can do as server-side generated HTML:

<html>
  <head>
    Some meta, CSS, scripts, third-parties etc.
  </head>
  <body>
    <div id="app">
      <div id="app-root">
        <header></header>
        <div id="app-container">
          Content between header and footer
        </div>
        <footer></footer>
      </div>
    </div>
  </body>
</html>

If we return this HTML without the content of the <header> and <footer>, tags, React will throw an error, because it needs the whole DOM structure in order to attach the events and cannot fill the missing elements.

So what we did?

First of all, initially, we thought that we can just create the above HTML structure and React will fill the missing elements only but few hours and errors later we figured out that React needs whole React-generated HTML in order to hydrate.

Step One

Return what we have as HTML from the backend and the initial structure looks like that:

<html>
  <head>
    Some meta, CSS, scripts, third-parties etc.
  </head>
  <body>
    <div id="app-shell">Static Header</div>
    <div id="app-container">
      Content between header and footer
    </div>
    <div id="app"></div>
    <script src="OUR_INITIAL_REACT_BUNDLES"></script>
  </body>
</html>

Step Two

Our initial App architecture is like this:

App.js

class App extends Component {
    render() {
        <div className='app-root' >
            <RouteList {...this.props} />
        </div>
    }
}

RouteList.js

class RouteList extends Component {
    render() {
        return (
            <React.Fragment>
                <Header />
                <div className="app-container">
                    <React.Suspense fallback={<span />}>
                    <Route exact path='/' render={(props) => <Category {...props} />} />
                    etc.
                    </React.Suspense>
                </div>
            </React.Fragment>
        )
    }
}

When React is ready and in RouteList we delete the app-container and app-shell divs from Step one and let our <Category /> component get again the HTML by making a request to the JSON API and render it.

Something like this:

class RouteList extends Component {
    componentDidMount() {
        let elem = document.getElementById('app-shell');
        elem.parentNode.removeChild(elem);
        let elem = document.getElementById('app-container');
        elem.parentNode.removeChild(elem);
    }

    render() {
        return (
            <React.Fragment>
                <Header />
                <div className="app-container">
                    <React.Suspense fallback={<span />}>
                    <Route exact path='/' render={(props) => <Category {...props} />} />
                    etc.
                    </React.Suspense>
                </div>
            </React.Fragment>
        )
    }
}

Then we have our first Partial SSR!

Step Three

The second step makes an additional request to get the same content that it's deleting, so we have changed the HTML returned from the first request:

<html>
  <head>
    Some meta, CSS, scripts, third-parties etc.
  </head>
  <body>
    <div id="app-shell">Static Header</div>
    <div id="app-loader"></div>
    <script>
    const appContainer = {
      html: '<div id="app-container">Content between header and footer</div>'
    }
    var appLoaderElement = document.getElementById('app-loader');
    appLoaderElement.innerHTML = decodeURIComponent(appContainer.html);
    </script>
    <div id="app"></div>
    <script src="OUR_INITIAL_REACT_BUNDLES"></script>
  </body>
</html>

Then again in RouteList component, we delete the app-loader div but the <Category /> component will check if appContainer is not empty and get the HTML from it and won't make an additional request. (Yup, we know, it is ugly.)

The result is this timeline:

(Final) Step Four

That white gap that you see above is ruining all our previous efforts, the SpeedIndex and LCP won't improve because of this gap and, more importantly, it's really awful for the user.

This is happening because we use React.lazy() and <Suspense> on routing level for components that are not <Header> and we are passing an empty <span> to the fallback attribute, so while React is waiting, the <Category /> to load, it shows empty span below the Header.

<React.Fragment>
  <Header />
  <div className="app-container">
    <React.Suspense fallback={<span />}>
      <Route exact path='/' render={(props) => <Category {...props} />} />
      etc.
    </React.Suspense>
  </div>
</React.Fragment>

To fix the gap we pass the JS global variable containing the HTML as the fallback:

<React.Fragment>
  <Header />
  <div className="app-container">
    <React.Suspense fallback={ <div dangerouslySetInnerHTML={ __html: decodeURIComponent(appContainer.html) } } >
      <Route exact path='/' render={(props) => <Category {...props} />} />
      etc.
    </React.Suspense>
  </div>
</React.Fragment>

dangerouslySetInnerHTML is not a good practice at all, it can expose you to cross-site-scripting attack but we don't have any other choice except to live with it for now :)

And the result:

Performance improvements

While the above code is not the prettiest one, our performance improvements are significant for Homepage and Category Landing Pages:

Thank you for reading this long article, I will be happy if you have any comments or suggestions :)

The dimensions of an img tag

Lyubomir Angelov — Sat, 03 Aug 2019 20:40:10 +0000

The other day in the team we were playing with one simple bug.
The bug was why the Intersection Observer is loading almost all images on the page which are not in the viewport?

It was simple, the src attribute was empty:

    <img src="" data-src="" class="lazy-load" alt="Some title" />

This was making all images on the page to render close one to another with the size of the defined line-height. So almost all images were initially in the viewport when the Intersection Observer was triggered.

Ok, we got the issue, so let's define some dimensions to the img tags:

    <img src="" data-src="https://URL_TO_IMAGE" class="lazy-load" height="200" width="200" alt="Some title" />

Ahh, still the images are only with the size of the line-height and still almost all are visible...

Then after adding some CSS to try to set the size "min-height" and etc. we were not able to set the proper dimensions.

Suddenly someone remembers it if you don't have some URL to image in the src attribute, the Width and Height won't be used and the tag won't be that size.

The simple solution was:

    <img src="https://URL_TO_1x1_PIXEL_IMAGE" data-src="https://URL_TO_REAL_IMAGE" class="lazy-load" height="200" width="200" alt="Some title" />

Yes, if you set 1x1 image in the src, the height and width will be applied and the Intersection Observer will do his job properly.

Most of the articles for Image lazy loading are not mentioning that you need src attribute filled, it is better for UI and for the lazy load.

When to use browser push notifications

Lyubomir Angelov — Thu, 09 May 2019 17:57:16 +0000

Push notifications are a really nice feature, you can trigger a notification to the user device with any text that you want with title, image, body and it even can make the mobile device to vibrate (depends on the browser) when receiving it.

This is a really cool way to get the user attention when you have promotions, forgotten baskets full of products or you have published something new.

In order to use push notifications you have first to ask the users for permission, this is the small pop-up next to URL bar with buttons "allow" and "block":

How the majority of the websites are using this feature?

They make this pop-up appear immediately when you visit their site, you have no Idea what is this, for what you have to subscribe and for god sake I didn't do anything, what is this pop-up for? Ok, block it!

Most of the users are clicking block because you don't ask for permissions on the right time and you are just throwing away the chance to convert this user.

Instead of triggering it on initial loading, please do it on user action, for example after he read the article put a button to ask if the user wants to subscribe for more news. Or on saving an item to his wish list, you can ask him if he wants to subscribe to notifications in order to receive information when this item will be available.

Here you can find more information about what is possible and how to install it in Google Dev website

Why you should care when you are sending the notifications?

Lyubomir Angelov — Wed, 17 Apr 2019 20:42:22 +0000

What I observe on vast of the majority of the news websites and not only them, is that they are sending all kind of notifications (Apps, Twitter, Emails etc.) when possible, 10 AM, 2 PM, 11 PM, 1 AM.
That's not right, know your audience, look at your analytics, check most valuable hours, think when you want those notifications, ask friends etc.

If you are not thinking about that, not knowing your audience, it is time to start doing that.

Why? Because you can disappoint your users, for example when you publish something to Twitter or you send an email at 1 AM.
Believe me, users will stop their subscription to your Twitter tweets or will unsubscribe from your newsletter and they will not read. You are not leaving a good impression like that.

In general try to think as a real customer, ask friends and make A/B tests.
Send one email, ok at 1 AM to half of your users, then check how many of them opened it, read it and clicked on the links in, then do the same with the other HALF but in a different time, for example, 9 PM.

All big websites are doing that, why you are not doing it?

How to send emails that are not marked as SPAM?

Lyubomir Angelov — Sun, 14 Apr 2019 16:05:13 +0000

Recently I helped one company to prevent common emails for registrations and etc. to be marked as SPAM automatically from users mailboxes.

When you are using third-party service like MailChimp and with your own domain to send your emails you have to do several steps to prove all mailboxes that you are you and that you are not some spammer.

To do that all services will have instructions on how to set DKIM and SPF records to your domain name that you will be using for sending the email. Usually, I create a subdomain like mail.example.com, then we have to add those DKIM and SPF records provided by the service.

They represent texts which tell to mailboxes that you are using different service for sending emails then your own server

MailChimp examples are:

    • DKIM:
    Create a CNAME record for k1._domainkey.yoursite.com with this value: dkim.mcsv.net.

    • SPF:
    Create a TXT record for yoursite.com with this value: v=spf1 include:servers.mcsv.net ?all

If you follow all the instructions of the service you will have a subdomain with DKIM and SPF records and then you should be ready to send all your newsletters and common emails with no problems.

Despite the above configurations, mailboxes like Gmail might mark your emails as SPAM. Why? Because there is one last step that you have to configure when sending emails.
Your From record have to match the sender, otherwise, it is not trusted.

Let's give an example:

    Received: by mail.example.com
    From: info@example.com
    To: someuseremail@gmail.com

In that example, the domain that the service is using for sending the email is different from the domain that is used in the From.

But if you change that to:

    Received: by mail.example.com
    From: yourfriends@mail.example.com
    To: someuseremail@gmail.com
    Reply-to: info@example.com

Emails won't be marked as spam because sender domain and email From domain are the same.
With Reply-to when the user wants to reply to our email, he will write not to yourfriends@mail.example.com but to what we defined in Reply-to.

Hope that will help someone with his emails. :)

Apache - Rewrite all URIs to a single file

Lyubomir Angelov — Thu, 11 Apr 2019 17:01:07 +0000

This week I had to help a friend with his new small ReacJS website running on Apache.

His problem was that URIs which does not exist the Apache was returning as 404 pages, he needed a common rule used by a lot of PHP frameworks, Rewrite all URIs which are not Files or Directories to /index.html

Example URL www.example.com/myprofile to actually load www.example.com/index.html and let the ReactJS route do his work and show what it needs.

In that case, you might write something like this:


    RewriteEngine on

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^ index.html [L]

What is this doing, it will check the URI either exists as a file or is a directory if it is NOT, it will call index.html. The [L] means that this will be the LAST match and will stop there, will not continue if we have other rules below that.

This is code is ok, not so simple and you can mess up the conditions, for example, I have seen a lot of [OR] next to RewriteCond %{REQUEST_FILENAME} !-f [OR] which will not work in our case above.

If you need this simple Rewrite rule, you might use Apache command available after 2.2.16 version


    FallbackResource /index.html

This will do the same as the above 4 lines if the URI is not found on the server, ie. not a File or a Dir, it will load to /index.html

This command is not part of mod_rewrite, but of mod_dir, if you don't have it enabled, run sudo a2enmod dir and restart the Apache.

JavaScript interview question that you have to know

Lyubomir Angelov — Tue, 02 Apr 2019 21:46:11 +0000

What is the difference between var, let and const in JavaScript?

It happened to me with few junior JavaScript and few PHP mid/senior developers that they didn't know the answer and the bad side is that all of them had a decent experience in projects with JavaScript.

The difference is huge, Scope, Declaration and Re-declaration.
I was going to explain in details but found a very good article here that have all the details Var, let and const- what's the difference?