JavaScriptを使用してパフォーマンスの高い「ビューポートディメンションを取得」ミニアプリを作成する

「スロットルされた場合は 真の値を持っている場合は、 ifを実行します のコード」。

「しかし、スロットルの場合 します 真実の価値を持っているなら、そこでやめなさい！」

JavaScriptのTrueとFalseの値は何ですか？

JavaScriptには、真実があります および偽り 値。うん、それは彼らが呼ばれているものです。真実は真実である価値です。 Falsyは、falseと見なされる値です（驚きです！）。

JavaScriptには、6つの偽の値があります。

• 未定義
• null
• 0
• '' （空の文字列）
• NaN
• false

In JavaScript, anything that is not one of the above values is considered a truthy value. That’s pretty simple, right?

Back to the throttler

With that quick lesson on true vs. false, go ahead and check if our throttled variable is indeed undefined, and a falsy value type.

We can quickly find out with console.log() by using !! to check our variable:

var throttled;
console.log(throttled); // undefined
console.log(!!throttled); // false value

!! is a double not operation. It’s a quick way to check for truthy and falsy values.

Great, now we have confirmed that throttled is undefined, and a falsy value type. This means that the very first time our throttler() runs, if ’s condition is indeed met.

// I start out as a falsy value
var throttled;

// I’m triggered by the window resize event
function throttler() {
  // I will only run my { code } if throttled is falsy (it is!)
  if (!throttled) {
    // code to execute
  }
}

Which means that we can move onto what happens inside if’s code block.

Inside if’s code block

Once inside the if statement code block, we immediately start the callback to functionToExecute 。

We also set our global throttled variable to true, so it’s no longer undefined (no longer a false value). This stops any future calls to functionToExecute() 。

if (!throttled) {
  // Run callback
  functionToExecute();
  // Set global throttled variable to true
  throttled = true;

  // ...
}

But then right below, we use setTimeout to reset the the throttled value back to a falsy value, after the 100ms delay:

function throttler() {
  if (!throttled) {
    // Run callback
    functionToExecute();
    // Set global throttled variable to true
    throttled = true;

    setTimeout(function() {
      // Set throttled back to false after delay
      throttled = false;
    }, delay);
  }
}

So every time the window resize event is running, it triggers the throttler() , which will call functionToExecute every 100ms!

Throttling is power

It’s easier to understand how powerful throttling is if you look at two opposite extremes. Try the following in the throttler function on CodePen:

• Swap 100 out with 500 and resize your window. Notice how infrequent the functionToExecute() is called (twice per second).
• Then try to swap out 500 with 16 and resize the window. Now functionToExecute() is bombarded with calls (up to 60 calls per second).

That’s how throttling works. We use it to limit the number of times a function can be called over time. It’s a very easy way to avoid wasting hardware resources. The hard part is finding the “optimal” execution rate for a given function, as no project is the same. More about that later.

Adding the throttler to our project

To apply the throttler function to our own project, we’ll need to do a bit of refactoring to the old code first. Refactoring is when we improve the structure of a program but don’t change the overall functionality.

In other words:we take something that already works, and makes it easier to use and understand.

We no longer want the window resize event to directly execute the function that returns width and height. Instead, we want our throttler function to regulate when and how often the code executes.

Fortunately, the change is simple. We just need to declare a named function and then put all code from the anonymous function inside that named function.

Let’s call the new function getViewportDimensions() ：

function getViewportDimensions() {
  var width = window.innerWidth;
  var height = window.innerHeight;

  viewportDimensions.textContent = width + "px" + " x " + height + "px";
  viewportDimensions.style.display = "block";

  clearTimeout(resizeTimeout);
  resizeTimeout = setTimeout(removeViewportDimensions, 3000);
}

Now let’s take the same throttler function from earlier, and replace the functionToExecute() with getViewportDimensions() ：

function throttler() {
  if (!throttled) {
    // Callback: the function we want to throttle
    getViewportDimensions();

    throttled = true;

    setTimeout(function() {
      throttled = false;
    }, delay);
  }
}

And finally we add the window resize event listener:

window.addEventListener("resize", throttler);

That’s it, all the hard work is done! Before we wrap up, let’s check our app’s performance, and see if we need to tweak anything.

Hardware Performance vs. Perceived Performance

I don’t know about you, but when I resize my browser window, the width and height numbers are rendering a bit laggy to my screen. It’s not as smooth as it was before we added the throttler.

But that’s not surprising. Before we added the throttler, our code’s execution rate was absurdly high. Now it’s firing around 10 times per second. That’s why it’s a bit laggy now.

There’s no doubt that our app is very performant, from a hardware usage perspective. Our hardware hardly does any work, so it absolutely loves us right now. Which is good.

But what about the perceived performance, from the User Experience point of view? Do our users love us too?

Our rendering should be smoother. Our function execution rate is currently capped at 10 times per second. Let’s increase it. But how much?

We can make it easier to make that decision if we first take a look at the relationship between time and frame rate.

Time vs. Frame Rate

Frame rate is also known as FPS (Frames Per Second). It refers to the number of individual frames displayed per second.

In general, the higher fps the smoother the rendering will be. Video games often need 60fps or more to render smoothly. Most movies and tv series run smoothly at 24-30fps. The more fast-paced action a video or graphic has, the more FPS it needs to render smooth.

For some types of graphics, you can go as low as 15fps and still get a smooth render. But you should rarely go below 15fps because then the perceived performance will start to look noticeably slower.

To find your desired FPS in ms, you divide your target fps with 1000, e.g. 1000/15(fps) =66ms.

Take a look at this FPS to millisecond table:

var 2fps  = 1000/2; // 500ms
var 10fps = 1000/10; // 100ms
var 15fps = 1000/15; // 66ms
var 24fps = 1000/24; // 42ms
var 30fps = 1000/30; // 33ms
var 60fps = 1000/60; // 16ms

Do you recognize something? Our app is currently executing every 100ms, or in frame rate terms:10 frames per second.

Remember, I just said that anything below 15fps will usually appear slow? That could explain why current app’s rendering feels a bit off. There are not enough frames per second to render it smooth. It doesn’t feel instant.

Let’s do some testing

I’ll guarantee that if we crank our Viewport Dimensions feature up to run at 15fps (66ms), it will look significantly smoother than at the current 10fps (100ms).

And it won’t cost too much extra CPU power.

We only need it to be smooth enough.

Like I said earlier, testing opposite extremes is a good way to find out what not する。 Then the question becomes where between the two extremes does your project fit?

Try testing the following frame rates:5fps (500ms), 15fps (66ms), and 60fps (16ms) on your Viewport Dimensions app and see what happens.

What do you think?

5fps looks horrible. It looks broken. That would never work. Our hardware would love it, but our users will hate it!

15fps looks good to me. I wouldn't say that this frame rate is 100% smooth, but it’s clearly better than 10fps.

It’s also important to remember that if your eyes are trained to look for small details, it’s not comparable to the average user’s experience. Most people will consider 15fps smooth, for this type of graphic.

60fps is super smooth — not surprisingly. But honestly, it’s not worth massively extra hardware usage.

I’m going to settle at 15fps for my app.

Why 15 FPS?

The reason I decided on 15fps / 66ms, is because that frame rate is high enough to be perceived as smooth (for most people).

Most software, computers, and displays (screens) can render at 15fps without problems. Even most small, handheld devices can handle 15fps without issue.

The irony of high frame rates is that while logic tells us that more frames per second =smoother, it can also have the opposite effect.

If you try to force a frame rate or refresh rate that your user’s hardware and software can’t handle, the result is often:lagging.

Refresh rate :is how many times your display can redraw your screen. A refresh rate of 45Hz means that your display can redraw it’s entire screen 45 times in 1 second.

Now if your CPU &GPU can generate a frame rate of 60fps, but your display’s refresh rate is only 45Hz, then you have a mismatch. This often causes unpredictable results.

We developers and designers can easily get out of touch with reality. Our development machines are usually more powerful than the average person’s computer.

This is why we need to do solid research and test our assumptions before we push products on the market.

So 15fps is a happy medium that will also work for people who don’t have powerful machines.

Using 15fps will also save us at least 75% of the energy our hardware used before we added the throttler.

Anything below 15fps will usually start to look slow and laggy. It becomes really obvious once you get to around 10fps, which is why our initial frame rate wasn’t good enough.

Here’s an insightful video on the topic of response times which supports my argument for not going below 15fps (on most things).

Context &the Minimum Effective Dose

How much of a perceived difference is there from 15 to 30fps? If you test it out on the app we just built, you’ll be surprised.

You probably won’t be to notice any significant difference. Not a deal-breaking 違い。 But the price you pay for hardware usage is double up!

High fps costs a lot of hardware power. So why use more than necessary? There’s always a point of diminishing returns. That’s where the Minimum Effective Dose (MED) comes in. You only need enough, to get the desired effect, no more, no less.

Of course, it always depends on the context. Are we talking about an explosive first-person shooter video game or a simple pixel counter like the one we’ve built? Context is key!

A Finishing Touch

All the hard work is done. For good measure, let’s wrap all our code inside an IIFE ((function () {...})(); ) and initialize use strict mode inside:

(function() {
  "use strict";

  // Put all your code below

})();

IIFE (Immediately-Invoked Function Expression), keeps all your code inside a local scope.

If we don’t wrap our code like this, we risk “polluting the global namespace”. This is a fancy way of saying that we risk causing conflicts with other code, outside of our app.

use strict; is also used to prevent conflicts with 3rd party software that don’t follow strict coding rules.

We’re done!

Here is all the code we’ve written. I've added some comments for clarification and some extra white space for readability:

Finished project code:

(function() {
  "use strict";

  // throttled value before window event starts
  var throttled;

  // Delay function calls to 66ms (frame rate: 15fps)
  var delay = 66;

  // Declare empty variable for later use
  var resizeTimeout;

  // Grab body element
  var body = document.querySelector("body");

  // Create element
  var viewportDimensions = document.createElement("div");

  // Style element
  viewportDimensions.style.position = "fixed";
  viewportDimensions.style.right = 0;
  viewportDimensions.style.top = 0;
  viewportDimensions.style.padding = "16px";
  viewportDimensions.style.zIndex = 3;
  viewportDimensions.style.fontSize = "22px";

  // Add div element inside body element
  body.appendChild(viewportDimensions);

  // window.resize callback function
  function getViewportDimensions() {
    var width = window.innerWidth;
    var height = window.innerHeight;

    viewportDimensions.textContent = width + "px" + " x " + height + "px";
    viewportDimensions.style.display = "block";

    clearTimeout(resizeTimeout);
    resizeTimeout = setTimeout(removeViewportDimensions, 3000);
  }

  // Called from getViewportDimensions()
  function removeViewportDimensions() {
    viewportDimensions.style.display = "none";
  }

  function throttler() {
    // Only run code if’s block if we’re not throttled
    if (!throttled) {
      // Callback: the function we want to throttle
      getViewportDimensions();
      // We're currently throttled!
      throttled = true;
      // Reset throttled variable back to false after delay
      setTimeout(function() {
        throttled = false;
      }, delay);
    }
  }

  // Listen to resize event, and run throttler()
  window.addEventListener("resize", throttler);

  // End of IFFE wrapper
})();

Here’s a CodePen you can play with.

How to use your app on any project

Include a script tag at the bottom of your HTML document, just above your closing body tag ( ) and add the path to your js file, like this:

<script src="/js/get-viewport-dimensions.js"></script>

Browser Compatibility

Our app is compatible with all modern browsers, and from Internet Explorer 9 and up.

Advanced throttling

What we learned in this tutorial is a great precursor for some the more powerful performance tools on the market.

If you need to boost performance on more complex projects than the one we built, check out the Lodash JavaScript library. Lodash has a lot of performance features and is very popular among developers. You can also learn a lot from digging through the library’s code.

Resources

• Mozilla’s Resize Event docs
• Mozilla’s Frame Rate docs
• Video on Response Times
• Frame Rate vs Refresh Rate
• Why 66ms when using setTimeout