Discussions

Do we have any documentation on how to reduce Maxymiser library size?

Macdara-Oracle
Macdara-Oracle Posts: 12 Employee
edited Apr 28, 2022 3:58AM in Infinity & Maxymiser

Hi Team , I received this question from a customer: We are trying to improve SEO ranking driven by WCV (https://web.dev/vitals/) and tweak how Maxymiser is deployed:

 Do we have any documentation on how to reduce Maxymiser library size as majority javascript code is not used but is loaded and consuming cpu, memory and bandwidth therefore penalising LCP for the ranking score in our site. 

Post edited by OIT Integration User on
Tagged:

Best Answer

  • Oleksii Stanko-Oracle
    Oleksii Stanko-Oracle Posts: 2 Employee
    edited Apr 16, 2021 3:25PM Answer ✓

    I have run a few measurements using PageSpeed Insights comparing different implementation options. Those were done on a relatively small webpage (taking 0.5 megabytes with all its assets) to make the latency impact prominent. Here are the numbers for Largest Contentful Paint when the tag is located directly in the head:

    • Maxymiser campaigns are sync - 0.9 second
    • Maxymiser campaigns are async - 0.9 second
    • No tag - 0.7 second

    If it's the CX tag, available to joint Maxymiser-Infinity customers, than we already have an article on implementation options. You can access it by clicking here. It covers the flicker topic as well.

    I'm also attaching the screenshots of the reports if someone would want to take a look at those.

    And a few words regarding the Campaign Design Library (mmpackage.js) and a specific percentage of code not being used on every page. Our studies have shown that because it is a statc file, always cached and is relatively fast for the first request, there's no point of splitting it into separate modules. This may sound surprizing, but it's much more efficient being a bigger file, than having two or more separate files. Here's a screenshot for reference:

    The data under the "Time" column is what I see on a WiFi connection, impacting the load time for 0.04 of a second.

    Even though I got this data for my page, a browser may show a different picture elsewhere. As I mentioned before, it would be affected by any other asset on a page and look as if Maxymiser's performance itself is not optimal. That's why for now we approach latency concerns on client-by-client basys. There's a plan to put all the knowledge we have into an article though.

Answers

  • Let me first provide some background, so we can have a substantive discussion. The following JavaScripts are served from Maxymiser:

    1. The Maxymiser tag (mmapi.js). It is just a bootsrapper that requests the optimization campaigns. We kept its functionality at a minimum, making it a very small package passed over network (of just a few kilobytes).
    2. As soon as you map something to a URL (such as a campaign), there is an additional library (Campaign Design API library) loaded in the visitor's browser called mmpackage.js. It is cached for a year, so should be fetched only once. It contains all the helpful methods used in the campaign code.
    3. And then there is the campaign response from the Maxymiser service, that contains code relevant for a visitor. It depends on how campaigns are built, and can be optimized by reviewing the way those are set up.

    According to what I studied, Maxymiser takes 1-4% of an average page load time. This range does not apply to highly dynamic websites that would first load a really quick static version of a page from the CDN's node though, but the number is common for ordinary webpages. So it would be good if you could outline the exact issues someone has faced with the Maxymiser implementation.

    In the past we were approached with the render-blocking (synchronous) call being flagged. But our studies confirmed that it doesn't really affect the Google's Lighthouse rating when compared to an asynchronous implementation.

    It's also important to understand that Maxymiser itself is affected by all the assets on a page. Meaning that the more scripts, images or styles there were before Maxymiser, the slower Maxymiser would look when added. It happens because everything loads in parallel. On some pages the same content may take 0.1 second, while making it 0.6 second on others (that are very heavy).

    Please let us know if a SEO-specific article for developers would make sense in the Developer Help Center.

  • Macdara-Oracle
    Macdara-Oracle Posts: 12 Employee
    edited Apr 14, 2021 6:17PM

    Thanks Alex,

    An SEO-specific article for developers would be a great idea as changes by Google will impact many customers and my Customer wants to make pro-active changes to ensure they are not penalized.

    As of May 2021 Google will adopt three three Core Web Vitals for UX as ranking a signal; Largest Contentful Paint (LCP) measures loading activity largest image or text block. In many customer cases whilst LCP is not fed by Maxymiser load times will be impacted by Maxymiser. It would be good to provide some best practice, below is the feedback from customer.

    Customer is looking to reduce LCP from current performance from Poor/above 4s to Good/Needs Improvement/0-4s to ensure they are not prevented by being penalized when new ranking signals are adopted by Google.

    Customer has reviewed latest CX Tag Maxymiser documentation along with current documentation and has spoken with their respective partner. The guidance provided was to proceed with sync tag and campaign for quickest time to render. Customer has however tested sync tag with an async campaign and LCP reduces by over 1.5s. What guidance do Oracle provide on this other than risk of flickering.

    As outlined above, following JS are served from Maxymiser: tag/mmapi.js, Campaign Design API library/mmpackage.js & campaign response. Customer has noticed that Campaign Design Library package is with 62% bytes returned unused. Do Oracle have a way to reduce this % unused bytes or provide Best Practice?

    Post edited by Macdara-Oracle on