Naguel

I'm Nahuel, and these are my work experiences, ideas and thoughts as a web developer working on the eCommerce industry.

Proper way to configure asynchronous email sending in Magento

Proper way to configure asynchronous email sending in Magento

There are two ways to configure how Magento send order related emails (order confirmation, invoice, shipment and credit memo emails):

  • Either immediately when an action is performed (for example, right after you place an order).
  • Or cron-based (asynchronous).

Magento itself recommends to configure this to be asynchronous for performance reasons, so the email dispatch process doesn't block nor delay what the customer is doing (for example, less time consumption when the customer is placing an order), or to avoid long cron runs (or total crons block) when an ERP is updating orders status in bulk.

Enabling the “Asynchronous email notifications” setting moves processes that handle checkout and order processing email notifications to the background.

Configuration best practices by Magento

For my personal experience, it is also recommended to configure emails sending to be asynchronous to avoid having unsent emails.

When this is configured as immediately (not async), if an email fails to be dispatched because of any reason (like a server timeout) then Magento won’t try to send that email again in the future and the customer won’t be ever notified of his/her action.

Basically, there are a lot of good reasons to have this to be async.

Before setting this up

If you are going live for the first time on a new site there's not much to worry about, but if you are changing this setting from not-async to cron-based on an already live site then there's something to consider first.

The way this works when it's configured to be async is that Magento will rely on a cron to pick up from the database (from those tables related to Orders, Invoices, Shipments and Credit Memos) all those entities where the email was not dispatched, and it will send it.

Problem is that Magento doesn't care much about the date of those entities.

For example, if there’s an Order from 2019 whose order confirmation email was not sent because of any reason (for example, because there was a PHP error that stopped the execution), the cron will now pick this Order up and Magento will send the email related to that order.

To avoid this behaviour we should mark all pending emails from Orders, Invoices, Shipments, and Credit Memos as if they doesn't need to be dispatched, which can be done by executing the following SQL statements before enabling the asynchronous sending.

UPDATE sales_order SET send_email = 0;
UPDATE sales_invoice SET send_email = 0;
UPDATE sales_shipment SET send_email = 0;
UPDATE sales_creditmemo	 SET send_email = 0;

What we are doing here is ignoring the sending of emails for old Orders (and Invoices, Shipments and Credit Memos) so when we change this to be async the cron will only cares for future stuff.

Changing the configuration

Enable the “Asynchronous sending” option under “Stores → Settings → All Stores → Sales → Sales Email → General Settings”.

Lazyload post Feature Image from Unsplash in Ghost

Lazyload post Feature Image from Unsplash in Ghost

Unsplash is a great Ghost built-in integration that allows you to quickly add an image to your posts, and I personally use it every time to add the Feature Image to all my articles (the big one below the title, before the content).

Unfortunately, out of the box the image from Unsplash is really big (2000px wide) and impacts on the page speed of the site since the browser will download the image first then continue with the rest of the page.

There's no much we can do about the image size as we can't follow the "How to use responsive images in Ghost themes" official guide because that only applies to images you manually upload and not those coming from third-parties...

Dynamic image sizes are not compatible with externally hosted images. If you insert images from Unsplash or you store your image files on a third party storage adapter then the image url returned will be determined by the external source.

...but with a little bit of HTML and JavaScript we can lazy load them to prioritize the content over the image download.

Usually, the Feature Image in the Ghost theme will look something like:

<img src="{{feature_image}}" />

This is a classic img tag with the src containing the URL of the image. But we need to do some changes here first before moving to the JS side of this technique.

In the src we are going to put a placeholder image to avoid having a broken image while the rest of the page loads, we are going to move the actual image to the data-src attribute, and finally we'll add a new class to the element.

<img src="{{asset "images/placeholder.png"}}" data-src="{{feature_image}}" class="lazyload" />

The placeholder image should be a small image in terms of weight. I'm using an image with a solid colour of 183 bytes so I can "reserve" the space of the final Feature Image to avoid "jumps" in the browser while everything loads.

Finally, the JS is quite simple. We need to wait for the window to be loaded, get all the img elements with the lazyload class, and replace the src with what's on the data-src so we trigger the actual image download.

window.addEventListener('load', (event) => {
    let images = document.getElementsByClassName('lazyload');

    for (let i = 0; i < images.length; i++) {
        images[i].src = images[i].dataset.src;
    }
});

With this in place we should see that the content is prioritized over the Unsplash image, and if we are using a placeholder we should see that first in the "Network" tab of our browser's DevTools, with the actual image loading later.

Fun facts about the page speed of a website

Fun facts about the page speed of a website

Everybody, everywhere, all the time, is saying that page speed matters. We get it, we heard it a trillion times, and I'm not sure why we keep writing about it or discussing it.

Page speed matters as much as the sun is hot, period. If you are still in doubt then you're having a serious problem. Make your website faster, and do not argue this fact, as it will cost you money.

That disclaimer being made, you probably also read that Amazon run some test and found out that if their site become 1 second slower it could cost them 1.6 billions dollars a year. And that's 1.600.000.000 dollars.

How much is 1.600.000.000 dollars?

  • That's more than 133 millions dollars per month. An amount of money I probably never going to see in real life, at least not all together, whether you divide per months or even days (more than 4 millions a day).
  • In Argentina, that's 48 billions pesos considering the currency value by the time I'm writing this post.
  • That's 96 millions (just millions) kilograms of premium ice cream. That amount of ice cream means that you and your future generations can enjoy more than a kilo of ice cream per day starting today and for the following 200 thousands years.
  • If you buy an iPhone X, and iPad Pro, an Apple Watch Series 3... And then a MacBook Pro, an iMac Pro, an Apple TV... and finally an iPod Touch just because, you'll be spending around 20 thousands dollars meaning that for 200 years you can get yourself a brand new model of all this products everyday.
  • 320 millions Caramel Macchiato Venti from Starbucks.
  • A Magento Commerce licence could rise up to 125 thousands dollars per year based on expected annual gross sales revenue, meaning you can build 12800 new eCommerce websites using this platform.
  • The Apple Inc. v. Samsung Electronics Co. legal battle you probably read on the Internet doesn't event get near this number. Wikipedia talks about 539 millions in favor of Apple for the first US trial, and then 120 millions for the second US trial. It was pointless to check the legal battles in the other countries.
  • And my home banking doesn't let me enter 1.600.000.000 in any form's input.

It was hard to find the real source of this 1.6 billions dollars proclamation, so I'm not sure about the veracity of such statement but for the end of this post it is not 100% relevant.

What I did find is that Greg Linder, best known as the inventor of Amazon's recommendations, made a presentation in 2006 saying the following:

Every 100ms delay costs 1% of sales.
Greg Linder

Probably somebody took that statement, and calculated it to be 1.6 billions dollars a year.