Magento 2 Audit: Improve Site Performance and Results

At SwiftOtter, we offer several different types of audits, so we can help all types of businesses determine which parts of their site need improvement, including: 

1. A free Magento 2 audit: This free audit for Magento 2 sites/Adobe Commerce sites includes a 45+ page document packed with immediately actionable insights. This analysis covers SEO, user experience, merchandising, and more. (Click here to start your free site analysis)

2. Different paid audits, including:

• Module review—This is a hands-on/manual review of every third-party module in your project. These are found in the app/code and the vendor/ directories. Vulnerabilities often creep in through third-party modules, and can lead to compromised information or sites that crash.
• Custom code review—We review the custom code you have implemented on your site. Magento 2 developers often don’t build sites following best practices. We look for potential errors that can hurt site performance now or might affect it in the future.
• Server and application configuration - We review key things such as varnish configuration, HTTP/2, PHP configuration, MySQL configuration, and more. 
• Security posture— We confirm that your site is updated and protected from known vulnerabilities by installing applicable vendor-supplied security patches. Even being out of date by one month leaves your site open to vulnerabilities.
• Frontend performance– This is looking at the front end of your site, focusing on things such as image optimization (poor optimization effects load times), render-blocking assets (how long after a request is the desired page loaded, and content layout shifts (how much of your frontend changes after it’s loaded).
• Backend performance – Generally speaking, any problem on the front end can be traced to backend performance. So, we make sure to look at your site’s backend, too.
• Purchase journey experience – We look at problems in the codebase that are affecting – directly or indirectly – your on-site conversions. When we fix these issues, our clients generally see a direct boost in sales.
• Conversion rate optimization — Another more sales-focused audit, we look for trends in customer acquisition and how the conversion rate is affected. We find drop-off locations where customers chose not to buy but instead to leave or abandon their cart.
• Post-order delight – At this level of the audit, we always place an order to open the box. We want to see what your customer sees. What is this experience like? Are there review requests? Is there an opportunity to take advantage of a customer’s delight when seeing this new acquisition for the first time? While this doesn’t lead to an immediate sales increase, it will lead to more return customers, which lowers your overall cost per acquisition.
• Technical SEO – While we do not focus on technical SEO at SwiftOtter, we can recommend skilled SEOs who will take a close look at your keywords, header tags, schema, rich snippet, site map, and more. 

Keep reading to learn more about how our audits are conducted and the kind of deliverables you can expect. 

To summarize:

• An audit generally takes 2-3 weeks (perhaps longer if the website is more complex).
• Audits must be completed by highly-skilled individuals.
• Audits must be comprehensive—this article details the SwiftOtter audit process.

Your ecommerce experience represents first impressions that lead to the follow-through of the purchase. Customers are flaky in that they want a quick and painless purchase journey. As a customer needs help finding what they wish or flat-out errors in the purchase process, they are likely to abandon and look elsewhere.

This article discusses how the audit process works at SwiftOtter and what you can expect. Alternatively, if you are technical, this is our plan that you can also follow.

We unlock your blackbox (website).

Eliminate surprises and become completely informed.

Critical audit pieces

• Module review
• Custom code review
• Server and application configuration
• Security posture
• Frontend performance
• Backend performance
• Purchase journey experience
• Conversion rate optimization
• Post-order delight
• Technical SEO

What value does an audit bring?

An audit is your “State of the Union”. Your website can appear as a black box if you are not a developer. You know these powers transactions, but you are also aware of bugs and other problems. You are an expert at running an ecommerce business but not at debugging Adobe Commerce. This makes you worried that there are other problems in the platform you are unaware of.

An audit shines a light into the unknown. You have an understandable and thorough document that goes through every aspect of the system. You know the quality of your developer’s decisions. You know the weaknesses and strengths of your system. You know how well Adobe Commerce is configured. You see the speed bumps that inhibit customers from purchasing. You understand the security vulnerabilities that could land you in a PCI-compliance or GDPR nightmare.

Even if you have a stable relationship with an agency, a periodic audit will turn up aspects that are easy to overlook. This gives a game plan for the next steps on improving security and the conversion rate.

What is needed from the merchant for an audit?

What is the deliverable from this audit?

You get a document of 5-15 pages (or longer). This is highly detailed but still understandable by a “lay” person. When we deliver the audit, we walk you through our findings so you will have plenty of opportunity to ask questions.

Core: Module review

This is a hands-on/manual review of every 3rd-party module in your project. These are found in app/code/ and the vendor/ directories.

The first thing is to compare the currently-installed version with the latest version. We often find significant disparities that can account for bugs or security issues.

We focus on all modules in app/code/ to identify whether or not these can be moved into Composer version management. What’s the problem with leaving them in app/code/? They are harder to update. In other words, updates don’t happen. It’s even worse in that the Composer-managed modules are updated: having some outdated modules can cause bugs when interacting with updated modules (that’s a lot of the word “update” in a paragraph!).

Our following review is to understand what each module does. We can achieve immediate performance boosts by removing modules that no longer provide value. We take an initial stab at determining a module's value by reviewing the database and log files.

Every module is evaluated for significant security issues. We don’t review every line of code, but it’s pretty close. A good developer has first places they review that often are markers for the quality of the rest of the module. These issues are called out for further review or diagnosis.

Core: Custom code review

3rd-party modules can have poor-quality code, but custom modules are often worse.

These must be reviewed with a fine-toothed comb. Every line must be checked. Depending on the size of the website, this is very time-consuming.

Our developers often apply well-learned heuristics to identify the overall quality of the architecture. As the code passes or fails basic checks, the developer knows what further to review.

RED FLAGS

If a problem, like a SQL injection vulnerability, is found in one module, it’ll be found in others. It is up to the architect to find every case of these violations and notate to ensure they are promptly fixed.

We use tools such as phpcs to assist in the more automatable processes. For example, if the developer uses tabs instead of spaces, this will likely point to further issues. If there is a significant amount of commented code, we see they were not relying on version control.

One of my personal favorites is ObjectManager in the code. This should never be present in almost any circumstance.

Core: Server and Application Configuration

This is the most “checklist-able” step of the audit. Up to and after this point, most of the work is completed by hand.

Here are some of the points we review.

• Varnish configuration
• HTTP/2
• PHP configuration
• MySQL configuration
• Cache configuration
• Session configuration
• Effective use of RabbitMQ
• CloudFlare (or other good CDN) in use
• Cron jobs are running
• Attribute sets are adequately used
• Scoping is configured
• Categories are correctly structured
• Admin users are not shared
• Proper use of role scopes and resources (does the custom code work with these resources?)

All database tables are reviewed to identify runaway tables representing massive data storage.

Core: Security posture

Magento is what version?! This is our starting point. We identify this as the most critical problem if Magento is outside a patch version or two.

If Magento is updated by more than one month, you are no longer PCI compliant. Check this out:

Performance: Frontend

The front end of a website is what is seen in your browser. This could be the Product Display Page or the Admin area. The front end is when you click on something, and the page doesn’t refresh, but something happens. For example, when you change from one email to another in Gmail, this is the front end.

One of the front-end's most notable and universal areas is the Adobe Commerce checkout. This is presented by Javascript, and more specifically, a Javascript-powered framework. We won’t typically find too many issues with poorly-performing Javascript.

What we see is initially identified through the Google Page Speed (or Lighthouse) audit. The resolution is the challenging part.

We focus on

• Content Layout Shift (CLS): this is the metric of how much the page changes after loading it. We’ve all had those instances where just as we click on something, the page changes, and we click on the wrong “thing.” This is annoying at best and can be problematic at worst if an order is submitted or a form is cleared. Google penalizes websites with a high CLS. Adobe Commerce sites have a poor track record in this category.
• Largest Contentful Paint (LCP) or Render-blocking Assets: this is the point in time after the request is triggered that the page is considered loaded. This takes into account the server processing time as well as the time to download assets. Again, Magento loads many files, and these scores are often less-than-ideal.
• Image optimization: Content managers typically upload images. Unfortunately, many have not been trained to optimize these images, negatively affecting page load.
• Script Execution: it’s easy for you merchants to sign up for a new service that promises better conversion rate opportunities. Unfortunately, many of these services negatively affect your website. One or two is fine, but they add up significantly. We recommend paring these back, deferring their load, or loading only on specific pages (like the PDP and checkout pages).
• LESS / CSS: these don’t affect performance as long-term upgradeability. We review the stylesheets to understand how the theme was constructed and provide recommendations on how to improve these.

Related to upgradeability

Outside of preferences, one of the most significant headaches of upgrades is theme-related issues. This is one reason why using other themes (like Porto) can be of concern. We must review every step of the customer journey to identify theme-related issues. The more out of date a theme is or if it is poorly-implemented, the more the cost to upgrade.

Performance: Backend

Customer experience: Purchase Journey

The purpose of an audit thus far has been to identify problems with the codebase. These things, like performance problems or bugs, indirectly affect the conversion rate. Fixing these issues often represents a boost in sales.

However, the best part of the process is when we can review aspects that directly affect sales. Our quality assurance team reviews the site with a fine-toothed comb. Our business analyst walks through each step to identify missed opportunities.

This part of the audit is the least concrete. We'd like to give our team complete latitude to apply the best-practice heuristics they have learned and see how your website matches up.

Customer experience: Post-order delight

The customer experience continues past clicking the “Submit Order” button.

At this level of the audit, we always place an order so we can open the box. What is this experience like? Are there review requests? Is there an opportunity to take advantage of a customer’s delight when seeing this new acquisition for the first time?

You won’t see an immediate return on investment for changes implemented here. You will see it in the form of long-term loyal customers. You will see it as customers share the good word about your brand. You will be glad that you put some dollars into this category.

Customer experience: Technical SEO

We are not a search engine optimization company. We have partners that we can refer you.

Technical SEO represents the technology-powered aspects of getting your domain name to rank highly on search engines. Do your header tags properly scheme? Do you use rich snippets? Do you have a sitemap? A robots.txt? Any crawl errors? Do you have penalties due to poor performance?

In conclusion

SwiftOtter takes a serious approach to every audit we perform. We leave no stone unturned.

The result is a highly insightful report that removes the black box covers. You now have a gameplan for pushing forward to the new features you wish to deliver.