![]() ![]() ![]() Theexisting frameworks make this difficult, as there is no easy way to break up your application into pieces that are above and below the fold. This is not a new idea, but it is tough to execute. This is done by only sending the above the fold HTML. To improve FCP/LCP we simply must shrink that to a minimum. However, even with essentially no JavaScript we still can't score 100 for mobile if we don't fix the amount of HTML sentto the client for the above fold rendering. Such a minimal amount of JavaScript is what allows us to score a perfect score on TBT/TTI. The work described above lowers the amount of JavaScript the website has to download and execute to about 1KB, which takes a mere 1ms to execute. To fix this, we will be running GoogleAnalytics in a Web Worker using PartyTown. Bootstrapping analytics alone would prevent us from scoring a 100 on PageSpeed Insights for mobile. Analytics is different, as we can't delay it and must bootstrap it immediately. So far, we have fought a good fight in delaying JavaScript and hence improving the website’s performance. ![]() All of this happens naturally, without the user ever noticing the switcheroo. The file above downloads the real Intercom widget, removes the mock, and bootstraps Intercom. The standard way of installing it is to drop a piece of JavaScript into your HTML, like so:Įnter fullscreen mode Exit fullscreen mode Intercom is a third-party widget running on our site which allows us to interact with our customers. Eagerly download and execute JavaScript to make the menus workĪll of the above means that there is practically no JavaScript to execute a site load, and yet we can retain all of the interactivity of the site.Walk the DOM to determine where the listeners are.Qwik is resumable not replayable, and that makes all the difference. Since most of the site is static, we should not have to re-download that portion in JavaScript, or pay for rehydration of something we don't need. We need to fundamentally rethink the problem. The amount of HTML and JavaScript is simply too great to fit into the tiny sliver that PageSpeed allots for it on mobile. This also means that no existing framework will allow you to score 100 on mobile on a real-world site. What we are describing above is a fundamental limitation of every existing framework. Delaying rehydration would mean that the menus would not work. And the rehydration process can't be delayed, as it is the same process that installs DOM listeners. The framework must visit each DOM node and reconcile it against the VDOM, which takes time. To make matters worse, the rehydration process is slow. The implication is that the site is downloaded twice, once as HTML and then again in the form of JSX in JavaScript. In other words, even though 95% of the page is static, the framework must download all of the templates and re-execute them to determine listeners' presence. This process makes existing frameworks replayable. Specifically, it needs to run rehydration where the framework compares the templates against the DOM and installs all of the DOM listeners. To make the menus work, the application needs to be bootstrapped. Also, different menus are used for desktop and mobile devices.Įven though this is primarily a static site, it is still an application. Navigation system: Menus require interactivity and hence JavaScript.While the vast majority of the site is static, there are three things that require JavaScript: Why does it need JavaScript? Well, the homepage is a Next.js site, which means it is a React application (We use Mitosis to convert the output of our drag and drop editor into React). Our homepage is essentially a static page. Decrease the amount of content for the initial render. ![]() FCP/LCP: The page has too much content to render for mobile browsers.TBT/TTI: The JavaScript is causing too much blocking time on the page.It helps to look at the breakdown which makes up the score. Because the site itself is running on the Builder content platform, the content already adheres to all of the best practices for image sizes, preloading, etc. So let's dive in.īuilder.io is a standard Next.js site. Many companies claim 100 on desktop, but 100 on mobile is a bit of a unicorn. In this blog post, we share ways to get your site scoring 100 on mobile as well. When we embarked on this effort, we already scored 100 on desktop, but modern commerce is mobile commerce, and there we only scored in the mid-60s. We set out to see what it would take to score 100 on PageSpeed Insights on mobile. Getting a good score here is vital because Google has announced that it will use these scores as an input into its search ranking algorithm. Google PageSpeed Insights is a tool you can use to measure the perceived latency of your website. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |