The same guy you hire to do your

mdh673558

The basic idea is to leverage web workers to define which scripts will load in sequence vs. which may load in parallel. While you can force JavaScript to load in parallel, doing this by default is extremely inadvisable. Integrating technology such as this would largely mitigate the need for SSR in most cases. However, it will be very fiddly to implement and will require (you guessed it!) the time of a senior web developer.  full JavaScript code audit might be able to help you with this, too. If you combine JavaScript parallelization with a critical JavaScript rendering path, then you’re really flying.

In this example, here’s the really interesting thing: Image 97 You DB to Data immediately see that whilst the main thread is occupied for 17 seconds, JavaScript execution accounts for 12 seconds. Does that mean 12 seconds of the 17 seconds of thread work are JavaScript execution? That is highly likely. We know that all JavaScript is pushed through the main thread by default. That’s also how WordPress, the active CMS, is set up by default. Since this site is running WordPress, all of those 12 seconds of JavaScript execution time likely come out of the 17 seconds of main thread work. That’s a great insight because it tells us that most of the main processing thread’s time is spent executing JavaScript.



And looking at the number of referenced scripts, that’s not hard to believe. Taking the crusade to Chrome Dev Tools It’s time to get technical and remove the training wheels. Open a new instance of Chrome. You should open a guest profile to ensure there’s no clutter or enabled plugins to bloat our findings. Remember: perform these actions from a clean guest Chrome profile. Image 98 Load up the site you want to analyze. In our case, that’s TechCrunch. Accept cookies as needed. Once the page is loaded, open Chrome DevTools (right-click a page and select Inspect). Image 99 Navigate to Performance > Screenshots.