My name is Piotr Dolistowski, a Senior Director of Engineering at Instapage. I lead the technical branch of the company in Warsaw, Poland including project coordination and people management. Everything in today’s article is a direct result of my team’s efforts to create a faster page rendering system for Instapage customers.
It’s no secret to digital marketers that page load speed has a direct impact on user engagement and bounce rate. Google and others have made page speed a point of emphasis for anyone working in digital marketing for at least a few years, so it’s nothing new for 2019.
We’ve featured this many times before, but Google’s research shows that for slow loading pages, user engagement plummets while bounce rates rise:
This is why our team worked tirelessly to bring you the Thor Render Engine™. The render engine is our new page generator and part of our fully responsive page experiences that ensure your post-click landing pages load incredibly fast without any effort from you.
Before we dive into the details of Instapage’s new rendering system, let’s review why slow loading post-click landing pages are detrimental to conversions.
The impact slow loading pages have on conversions
Just how slow is a slow loading page? Every second delay in mobile page load time leads to a drop in conversions:
Translation: online users don’t have the patience to wait very long for your page to load. So if it doesn’t load near instantly, they’ll leave the page. This increases bounce rate, decreases user engagement, is bad for overall user experience, and ultimately limits conversions.
Akamai had the following insights after collecting data on 10 billion user visits from top online retailers:
- Half of the consumers browse for products and services on their smartphones, while only one in five actually buy on their mobiles.
- A 100-millisecond delay in website load time can hurt conversion rates by 7%
- A two-second delay in web page load time increases bounce rates by 103%
- 53% of mobile site visitors will leave a page that takes longer than three seconds to load
- Mobile phone shoppers bounce rates were the highest, while tablet shoppers had the lowest bounce rates
So, how can you ensure your post-click landing pages load fast? Google’s PageSpeed Insights can help, but how much?
Google’s PageSpeed Insights reports on the performance of a page, showing whether a page is fast, average, or slow on both mobile and desktop devices. It also provides suggestions on how that page may be improved:
But, if you don’t have a technical background, the page speed insights may confuse you. Understanding what First Contentful Paint (FCP) and the First Input Delay (FID) metrics may go right over your head.
Enter Instapage’s Thor Render Engine™.
The details behind the Thor Render Engine™
We developed the Thor Render Engine™ to ensure that all Instapage post-click landing pages load fast.
This meant a full rewrite of the post-click landing pages in every aspect — changing the HTML structure, JavaScript and CSS Refactoring, and CSS Responsiveness to ensure everything in the backend of your pages allowed them to load instantly.
The best part of all these changes is that you don’t need to do anything because the Thor Render Engine™ works silently behind the scenes to make your pages lightning fast.
Let’s break down the changes to see what we’ve done for faster loading pages.
HTML structure
A lot went into making the page rendering system faster from an HTML standpoint, starting with resource prioritization.
Resource prioritization
We’ve stripped post-click landing pages of a lot unused, ambiguous, or un-optimal code, resulting in a clear, fast-rendering markup.
The new HTML structure guarantees that all resources will load in the correct order. Page styles (except font styles) have been added to the head section because, after that, pages load faster than using CSS stylesheets.
Responsiveness no longer needs additional breakpoints in CSS or JavaScript because pages will load fast and look great without additional code. Moreover, all scripts are placed in the bottom of the page body so they don’t block page rendering. Critical scripts and resources (e.g., fonts) use browser pre-load abilities, which means they’re not blocked while the page renders. Furthermore, no synchronous JavaScript is placed in the head tag of the page.
Image and video lazy loading
Although images and videos are not render-blocking, when there are multiple present on the page, the bandwidth can be clogged up with too many requests, especially with large images. This can lead to poor user experience since images in the top fold are loaded simultaneously with images below the fold, which aren’t visible to the visitor.
To solve the issue, we introduced the following optimizations:
- Images above the fold load with higher priority — the download starts immediately so they are visible even before the page gets interactive.
- Images and videos below the fold are loaded lazily — the download triggers when the user scrolls to them. Gray boxes are used as placeholders for not-yet-loaded images.
- To prevent the user from seeing these gray boxes, images are actually loaded when they are scrolled into the viewport. But when they are scrolled at a distance of 400px to viewport bottom. When they enter viewport, they are already loaded.
- The same rule applies to videos, that are loaded in iframes.
To make this happen we leveraged cutting-edge API of IntersectionObserver, that makes lazy-loading super-efficient with small code size footprint:
JavaScript refactor
The JavaScript refactor included the following optimizations:
- Modular architecture: All JavaScript code on post-click landing pages relate to features of specific widgets. We split our code into multiple bundles, each containing a code for the specific feature. So, when a user designs a page with only images and links, no code for Form or Popup widgets will be loaded making the page load fast.
- Super lightweight: We removed old libraries and re-designed the entire code architecture, this allowed us to reduce total JavaScript size on the page from over 1MB to about 200kB (that is 5x less!), while a typical page will load less than 100kB thanks to modularization described above.
- All Async: Since JavaScript is render-blocking, we moved all script imports to the bottom of the BODY tag. This allows the browser to render the full page before scripts are executed allowing the visitor to see meaningful content earlier. Scripts that provide interactivity will load and execute only after they start to interact with that section of the page. This provides a very good experience especially on mobile devices with lower performance and often a poor internet connection.
CSS refactor
We’ve also re-written our entire CSS stylesheets, removing the unnecessary third-party code so our stylesheets are reusable, readable, and lightweight. Also, we use generic CSS classes to reuse CSS code as much as possible.
We’ve also implemented CSS-only animations with GPU acceleration. The most important change in our CSS stack was introducing the relative unit “rem” instead of pixels. Thanks to this, post-click landing pages now scale smoothly on every device size, from smartphones to 4k desktop displays.
CSS responsiveness
We are using “rem” in combination with “vw” unit to make post-click landing pages responsive. This means there are two gaps in device resolutions when the post-click landing page is scaled down between 768 and 1200 pixels width and below 400 pixels width. In all other resolutions, the main content remains a fixed width, just like in the builder. The fixed width value is 400px for mobiles and 1200px for desktop.
“Rem” units give us the ability to recalculate widget position and size smoothly. It also means we don’t have to use JavaScript to make this happen.
In summary:
- below 400px content automatically scales to fit the screen width
- between 400px and 767px the content width is fixed
- from 768px mobile view switches to desktop view
- from 768px to 1200px content automatically scales to fit the screen width
- above 1200px the content is fixed
Thor Render Engine™ speed test example
Since you never know how people view your post-click landing page (desktop, mobile, or tablet) it is important the page experience be completely responsive. The Thor Render Engine™ solution is fully responsive on all resolutions.
Now let’s compare the new render engine with our old page generator. The images below show the page speed results of the same page albeit with different URL. (Note: The pages are no longer active as these URLs are for testing purposes only):
Old Instapage page rendering results:
Thor Render Engine™ results:
Scoring a 56 on the first test, and increasing it to 95 on the second test is a 58.9% increase in page load speed!
Page load speed comparison
Having summarized all the changes with the Thor Render Engine™ let’s see how Instapage’s page load speed compares to the competition.
We tested the speed of this page (screenshot only shows above the fold) on a 3G connection:
Here’s how much time the page takes to load:
- With the old Instapage page rendering system (top row): 10.5 seconds to begin loading
- Thor Render Engine™ (middle row): Within 5 seconds, the page is 98% loaded
- Using competitor (bottom row): 8 seconds to begin loading
On a 4G connection, here are the results:
- With the old Instapage page rendering system: 4.5 seconds to start loading
- Thor Render Engine™: Loads completely within 3.5 seconds
- Using competitor: 4.5 seconds just to start loading
Enjoy faster loading pages with the Thor Render Engine™
Page speed plays a significant role in user experience and ultimately your conversions. When a page load time lags, not only do you risk a high bounce rate but also create frustrated users in the process.
With the Thor Render Engine™, we can now guarantee that your post-click landing pages will load instantly without any effort from you. Sign up for an Instapage Enterprise demo today and experience the difference yourself.