Drupal Planet

D8 Performance: Image Optimization

The phrase “A picture is worth a thousand words” has never rung truer than in today’s digital society. Images are the essence of the modern web. According to HTTP Archive, around 64% of a website’s weight is comprised of images. Images are more memorable and are processed faster by the brain compared to text content. They are an important ingredient to engage your visitors and deliver your message. High performing websites enjoy higher visitor engagement, retention and conversion.

Images can also be the cause of poor web performance. If image files are too large, they can significantly slow down a site. Google punishes slow sites by moving them down in the search engine results page (SERP). On the other hand, if you reduce the image quality too much, then you end up with an unattractive website.

Images and their quality are especially important for e-commerce websites, where digital product display is the cornerstone to driving conversions. Nearly 50% of consumers won’t wait 3 seconds for an e-commerce site to load.

So, where is the sweet spot? How can you effectively use images on your website? We have curated a list of optimization techniques which you can use to maintain a fast Drupal website while still serving high-quality images.

What is image optimization?

Image optimization is the process of delivering high-quality images in the right format, dimension, size, and resolution without sacrificing quality, keeping your page load times low. Image optimization also relates to image SEO. A high ranking webpage can be just as important as a high ranking image on Google and other search engines.

Image naming

It is easy to use the image’s default file name, but those spared seconds mean that the opportunity to optimize the image name is missed. When Google indexes webpages, the image names are indexed as well. Image names are particularly important when dealing with hundreds of product images. When creating image names, keep your strategies similar to keyword optimization for your overall site. Use descriptive, keyword-rich file names for your images.

Ensure all images have a corresponding alt attribute. However, avoid ‘Keyword stuffing’! If you abuse the alt and over-optimize by using too many unnatural keywords, Google may penalize you.

Read more on the importance of naming images strategically on Moz.

Image dimensions

In Drupal, you should use and configure image style to output the correct dimensions per the image displayed. If images are too big, you will slow down the page loading time. Mobile users' experiences would especially be hurt. If a bigger image is necessary, place it on a separate page or utilize a popup/Javascript to dynamically load it as needed. If images are too small, then they will get blown up and pixelated, making your website look ugly.

A solution that we recommend in Drupal is the Responsive Image module. With Responsive Image, you can configure different image styles to use on different breakpoints. Different image sizes are generated and loaded based on the user’s device resolution and improving the performance further. This module can set up responsive images so that a smaller image will be used on mobile while a bigger image will be delivered to desktop users.

Reduce image file size

The important factors that determine an image file size are:

Image file format
Image quality
Image dimensions, as mentioned previously
Color

Choosing the right image file format will reduce the image file size. As a general rule of thumb, for line-based imagery, use PNG or GIF. For photography imagery, use JPG. For JPG, the image quality could be adjusted and affect the output file size significantly. An average of 70-80% JPG quality will provide a good output for the web without a visible quality drop. Depending on the image usage, some JPG could use 40-50% quality without difference visually. JPG also supports progressive loading format, which will improve page load time as well.

Optimize image before upload

There are free image tools readily available to help further reduce the image file size without a loss in quality. On macOS, a great option is ImageOptim. For Windows users, we recommend FileOptimizer. Both applications will try multiple optimization methods to give you the smallest file size possible. Running images through these tools before uploading them will help to reduce server storage and to produce smaller image styles.

There are a few issue queues on drupal.org which are trying to automate this process.

Optimize image styles

Images generated from image styles can be optimized by using applications such as ImageOptim. This app can be automated through the Image Optimize (or ImageAPI Optimize) module. Image Optimize creates an optimization pipeline for all image styles. The optimization pipeline uses local optimization binary via Image Optimize Binaries. This will require you to install different image binary tools used for the optimization.

Our favorite is Image Optimize reSmush.it. This uses the free reSmush.it service to best optimize the images generated in Drupal. The whole process is automated and transparent.

Lazy load the images

Lazy loading is a technique where only images that are within the viewport will be loaded. Visitors will experience faster loading times, and it will save data usage if the whole page is not viewed. This especially benefits mobile users, where the perceived page speed is increased significantly on image-heavy websites like e-commerce stores. This also helps to reduce server requests and save server bandwidth.

In Drupal 8, you can install Blazy, which integrates with Blazy Library. Blazy is a lightweight pure JavaScript script for lazy loading and multi-serving images. This works with all techniques previously mentioned.

Image sitemap

Consider using image sitemaps to help the Google search engine discover images on your website. Sitemaps are especially helpful if your site uses Javascript galleries or image pop-ups to improve the viewing experience. Image sitemaps will help get your images noticed by Google.

Check out Google’s help files here to learn more about image sitemap.

In Drupal 8, Simple XML Sitemap provides the option to generate image sitemap. The support for Media images is still in the works, though.

All in all, if a picture is, in fact, a thousand words, then a well-optimized digital image is worth a million. Using these tips to improve image quality and size can benefit your site by improving SEO and improving engagement. Does this sound like something you want for your site? Schedule a call today to speak with a qualified Drupal expert!

CK

Chin Kiong “CK” brings over 13 years of Drupal development experience and over 300 code “commits” or contributions to the Drupal community. He has a wild, insatiable talent and drive to solve even the toughest technical problems in a variety of technologies, and brings excellence and elegance in his high-level architectural solutions and invaluable direction and advice. He has taken lead architect roles for big clients and large projects such as The Juilliard School, University of Minnesota, Cornell, HelpSystems, and Estée Lauder.

Team

Drupal 8 (D8) Performance: Caching

Thanks to its newly improved Cache API and the addition of BigPipe, Drupal 8 is faster than ever. O8's long-time Lead Architect, CK, shows you how to take advantage.

The Internal Page Cache Module

Now enabled by default, a new core module called Internal Page Cache caches pages for anonymous users. Pages requested by anonymous users are stored and reused, speeding up performance.

The only configurable setting on the Internal Page Cache is the "Page cache maximum age”, which sets the max-age value in the Cache-Control headers output by Drupal 8. Set the max-age as high as the frequency with which you are updating the pages. If your site will be getting a lot of traffic, set the max-age to a higher value. The higher the max-age, the better the information that is being cached and reused. Your CDN and frontend caching, such as Varnish, will utilize the max-age and serve the cached copy until it expires. To disable caching for development purposes, set the "Page cache maximum age" to no caching. The only value that will disable Drupal's caching is "no caching".

This module assumes pages are identical for all anonymous users. So if your website is serving personalized content, you will want to disable the Internal Page Cache module. Otherwise, Javascript and Ajax can handle the personalization on the front-end.

Alternative: The Dynamic Page Cache Module

Alternatively, you can use Dynamic Page Cache. Dynamic Page Cache caches the pages minus the personalized sections. Hence, this is useful for both anonymous and authenticated users. Dynamic Page Cache uses the cache contexts, a declarative way to create context variations of all the items to be cached. These dynamic sections are marked with placeholders by Drupal 8 Render API, called auto-placeholdering. A placeholder is assigned and Drupal will postpone the rendering of the placeholder render array until the very last moment. The overall page with auto-placeholdering is cached by Dynamic Page Cache and Drupal continues to render cache fragments for those dynamic parts.

Using the Cache API

For developers working on Drupal 8, caching is a compulsory topic, it is important to learn and understand the basics of the Cache API.

Cache contexts

Cache contexts are analogous to HTTP's Vary header. It determines the context involved in the caching of a render array. Cache contexts are represented in sets of strings. Examples cache contexts are

languages (vary by all language types: interface, content, …)

languages:language_interface (vary by interface language)

```
user.roles (vary by user’s role)
```
```
url (vary by the entire url)
```

url.path.is_front (vary by the front page)

Cache tags

Cache tags show what data that the cache depends on to Drupal. Similar to cache contexts, cache tags are represented in sets of strings. A cache will be invalidated when a cache tag is matched.

For example:

user:10 (invalidates the cache when User entity 10 changes)

node:8 (invalidates the cache when Node entity 8 changes)

Cache max-age

Cache max-age determines the number of seconds the cache item is valid. Generally, you don’t need to set a max-age, relying on the default (Cache::PERMANENT) will do.

Debugging Cacheable Responses

You can debug cacheable responses by setting the http.response.debug_cacheability_headers parameter to true in your services.yml. For this to take effect, the container must be rebuilt. That will cause Drupal to send the corresponding X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers to cache tags and cache contexts.

Using cache contexts and cache tags

Use \Drupal\node\Entity\Node;

/** * Implements hook_preprocess_block(). */ 
function mymodule_preprocess_block(&$variables) { 
  if ($variables['elements']['#id'] == 'search_promo') { 
    // Unique cache per search query string. 
    $variables['#cache']['contexts'] = ['url.query_args:search']; // Depends on content from a node entity. 
    $node = Node::load($variables['promo_nid']); 
    $variables['#cache']['tags'] = [$node->getCacheTags(]; 
  } 
}

Let’s say that we have a promo content block which will display different content based on the searches performed. The “search” query string will determine the cache context of the block. The block will be cached vary on the “search” query string, hence the url.query_args:search. The cache tags indicate that the cached block should be invalidated when the node entity content, where the block is loading, is updated.

Generally cache tags take the form of <entity type ID>:<entity ID> or config:<configuration name>, you should not rely on these directly. You should retrieve cache tags to invalidate for a single entity using its ::getCacheTags() method, e.g. $node->getCacheTags(), $user->getCacheTags(), $view->getCacheTags(), etc.

To invalidate a cache use Drupal\Core\Cache\Cache;

Cache::invalidateTags($node->getCacheTags());

What are the available cache contexts?

A quick trick to find the list of cache contexts you could use is to search the files *.services.yml for the pattern "cache_context.*".

Gotchas:

The {{ content }} variable in template

You must render the {{ content }} variable to ensure that its cache tags bubble up and end up in the page cache. You may end up with an uncacheable page if the {{ content }} is not rendered.

So, ensure your template contains:

Or, if you would like to render some fields separately:

Tips:

Avoid random sort. A random sort in views or code will cause the page to be not cacheable.
All access-checking logic must now return AccessResultInterface objects, which allows for cacheability metadata. If you implement any form of access or alter existing access hooks, ensure you return one of these:
- return AccessResult::allowed();
- return AccessResult::forbidden();
- return AccessResult::neutral(); // The default if all conditions failed.

BigPipe: The New(er) Kid On The Block

BigPipe became stable as of Drupal 8.3. It was a technique invented at Facebook, which defines it as a way to "decompose web pages into small chunks called pagelets, and pipeline them through several execution stages inside web servers and browsers."

How It Works

During rendering, the personalized parts are turned into placeholders.
By default, Drupal 8 uses the Single Flush strategy (aka "traditional") for replacing the placeholders. i.e. we don't send a response until we've replaced all placeholders.
The BigPipe module introduces a new strategy, that allows us to flush the initial page first, and then stream the replacements for the placeholders.
This results in hugely improved front-end/perceived performance (watch the 40-second screencast above).
(source)

Since content is lazy-loaded with BigPipe, one important caveat is ensuring that the page load experience is not visually jarring. The easiest way to ensure this is having the BigPipe content appear in its own space on the page, which avoids reflowing content. Alternatively, you can apply the "interface previews" patch until it is incorporated into Drupal core, or add a loading animation in front of that content.

CK

Team

Drupal 7: End of Life

End of Drupal 7

Drupal 7.0 has served us well since it’s January 2011 release. It powered web applications, leading the era of Drupal as a favored option for building any kind of website. Drupal 7 introduced us to more than 11,000 contributed modules, 600 themes, and 200 distributions. Now that it reaches its end of life, we must thank Drupal 7.0 for its service in November of 2021, and let it go.

Drupal 7.0’s end of life will occur at the same time that Drupal 8 stops receiving support in November of 2021, making way for a new age of improved Drupal core models.

Drupal 7, 8, and 9

It's the classic joke: Why was 7 afraid of 9? Because Drupal 8 was a transitional step in between!

That's right, there will be a sudden switch to Drupal 9 when 7 and 8 both end in the same month. To explain this, we must first warn you that the migration from Drupal 7 to Drupal 8 is a big one. For some teams, this transition will be seamless. For others, it will be more challenging, requiring extra time, talent and resources. In the end, Drupal users will agree that the benefit of transitioning outweighs the cost.

Here are some highlights of what you can expect when you upgrade to Drupal 8:

Easy author editing with a WYSIWYG editor or to create and edit content in-place
Smart language translation
Universal configuration storage
Responsive to touchscreens, tablets, and mobile readers
Improved Compliance

The D8 upgrade makes D7 obsolete. As the Drupal community awaits the release of Drupal 9 on June 2020, the D8 migration will provide a better system for your Drupal site as well as ease the transition into future models.

Drupal.org has provided expectations for the transition from Drupal 7 to Drupal 8:

Drupal 7 will no longer be supported by the community at large. The community will no longer create new projects, fix bugs in existing projects or write documentation for Drupal 7.
There will be no further core commits to Drupal 7.
The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core or contributed modules, themes or other projects. Reports about Drupal 7 vulnerabilities might become public.
All Drupal 7 releases on all project pages will be flagged as not supported. Maintainers will be able to change the flag status if they choose to.
On Drupal 7 sites with the update status module, Drupal Core will show up as unsupported.
After November 2021, using Drupal 7 may be flagged as insecure during third-party scans as it will no longer receive support.
Best practice dictates not to use unsupported software — it would not be advisable to continue to build new Drupal 7 sites.
It is recommended to begin planning your migration to Drupal 8 now.

To all you sentimental folks, this is a welcomed change! Updating to Drupal 8 will upgrade your visitors’ user experiences, as well as make your life easier as a content creator. While Drupal 7’s end of life isn't exactly a cause for panic thanks to an extended support period until 2024, you should be eager to make the switch as soon as possible!

Schedule a call today to get the D8 ball rollin’.

The Importance of DrupalCamps

What is a DrupalCamp?

Drupal events happen all over the world, all year long. Drupal events called DrupalCamps are 1 to 2-day conventions focused on sharing knowledge and fostering connections among the Drupal community. Attending these camps can provide you and your team with an improved, in-depth skillset.

DrupalCamps x Higher Ed Institutions

September of 2019, O8 is getting involved by sponsoring a DrupalCamp at Cornell.

While higher ed institutions may seem like the perfect partner for these types of camps, this hasn’t always been the case. Traditional schools, whose students are drawn by the value of a degree, have historically felt threatened by coding boot camps. The fear of losing university students to these skill-based camps has always seemed too high of a risk to justify any partnership. In reality, when higher ed institutions partner with coding bootcamps, it benefits students. The theory learned in traditional schools combined with the hard skills learned in camps can bridge the gap between the two educational styles. We applaud Cornell for acknowledging the benefit of pairing theory-based learning and skill-based experiences and wanted to help in any way we could. We love encouraging coding boot camps, and here’s why you should too.

Bootcamp Benefits

Coding bootcamps provide in-demand skills fast. The Cornell DrupalCamp will be held over the course of just two days in September 2019. Over the course of these two days, attendees will receive hands-on education with Git and Composer, learn to define their site’s audiences and objectives, analyze content from a Drupal perspective, translate client and business needs into an information architecture, develop strategies for using taxonomies and landing pages effectively, and create a great experience for content editors. There will also be valuable Keynote speakers and coding competitions. The amount and caliber of knowledge shared over these two days is immediately applicable in the workplace. The main focus of drupal camps is to make sure their students get the training they need to enter the workforce as an entry-level coder.

Beyond the benefit to the students, the higher education institutions partnering with bootcamps can actually increase their enrollment. While colleges and universities can offer courses in computer science and engineering, they most likely focus on theory. They probably don’t offer valuable coding or coding language-specific courses. Giving students access to coding boot camps provides additional value to a degree. Students gain access to real-world skills while graduating from an accredited university, making them more hireable in the eyes of employers.

What are you waiting for?

DrupalCamps provide you with the opportunity to learn from and contribute to the Drupal community. At its core, Drupal is still a village, making the community aspect even more important. Drupal relies on its users to help it improve for the next generation of content management systems and frameworks.

Web Developers' Honest Opinions of Drupal 8

At O8, we clearly love Drupal. With the current migration happening from earlier Drupal models to Drupal 8, we wanted to take some time to step back and examine the process. We sent out a survey to our team of developers to hear their feedback on the transition.

First, to learn the overall sentiment regarding the migration, we asked our developers to rate the process out of 5 stars. The feedback? 3.7 stars.

Those 3.7 stars tell us two things: 1) Developers generally like the process and new technology and 2) As with anything, there is room for improvement.

To identify those aspects that could be changed to better the process, we then asked developers what they would change about the migration. Answers to this question ranged, but there was a common theme: Developers identified a desire for more common defaults in the setup. However, many responses noted that their wishes for increased automation from D7 to D8 were “unfortunately, unlikely [and] not possible”.

Next, we asked our developers to compare D7 and D8/9. Our favorite responses are:

“D8 is pretty great in terms of UI and it's built on top of Symfony which makes it more powerful!”
“Mostly the same on the surface, but [it has a] completely different foundation. A few surface upgrades to admin experience, ease of use, etc.”
“New technology stacks.”

Lastly, we asked our developers to rank from most advantageous to least advantageous, the benefits of migrating to Drupal 8 (and 9) from Drupal 7. Our developers identified these three Drupal 8 qualities as the most advantageous: ease of authoring, ongoing mobile mind shift, and transforming the customer experience.

Ease of Authoring

With Drupal 8’s what-you-see-is-what-you-get text editor, writing is as fast and easy as you make it. This addition makes a big difference for those who need to edit and manage content on the site.

Ongoing Mobile Mind Shift

D8 is fully responsive. With it, your site can function flawlessly between touch screens, desktops, and mobile phones alike. Delivering rich mobile user experiences is more important now than ever, as, according to CIODive, “70% of internet traffic comes from mobile devices”.

Transforming the Customer Experience

Transforming the customer experience means that specific experiences are able to adapt to customers. D8 is able to do this by allowing quick and effective changes to be made in the name of engaging customer experiences.

Overall, the Drupal 8 migration may not be the easiest process, but it is well worth it. D8 is powerful, easy to use, and responsive. Our dev team appreciates the new additions and believes your business will benefit from performing the upgrades sooner rather than later. Once Drupal 6 and 7 become obsolete, the migration will be necessary for basic site updates. To avoid falling behind with upgrades, we recommend making the migration today!

Make the migration today! Schedule a call with us, O8.

Schedule a Call!

Drupal 9: What We Know So Far

Drupal 9 is almost here. By almost, we mean little over a year away. As far as development cycles go, that is fairly close.

Drupal 9 Release Date

The official Drupal 9 release date is June 3, 2020.

What does this mean for all those Drupal users out there? It means the winds of change are blowing. And hard. Which is a good thing.

Drupal 9 is, in a very technical sense as much as an essential one, an upgrade in true spirit. Dries Buytaert – the original developer of Drupal – has made it clear that Drupal 9 will be a cleaner version of Drupal 8, due in great part to the fact that the former is being built on top of the latter, essentially adding new functionality as backward-compatible code. This is very significant because it means migrating from Drupal 8 to Drupal 9 will be a very smooth and easy process.

Drupal 9 API illustrated

The developers have explained that the reason they have announced the Drupal 9 release date so far ahead of schedule is to give people time to prepare. Upgrading from previous versions to Drupal 9 will not only be easy, but it will also be necessary if you wish to acquire full functionality and retain the ability to receive security updates within the bi-yearly cycles.

Drupal 7 and Drupal 8: End-of-Life

As of November 2021, both Drupal 7 and Drupal 8 will reach end-of-life status, which means updates will no longer be available to either. By announcing the release of Drupal 9 over a year before it happens, and two and a half years before the older versions are no longer part of the developing cycle, the people at Drupal are giving users enough time to fully prepare for the migration, with enough warning to be fully upgraded by that time.

The wide release window also provides core contributors with time to work on their modules and adjust to the upcoming changes, not to mention that it gives the Drupal team time to iron out any kinks.

What About Symfony?

As for Symfony 5, it will be shipped with Drupal 9, but it will also be compatible with Drupal 8 while the developers identify and fix any potential issues, giving users enough buffer before S5 is required for D9.

As of yet, not much is known about which third party dependencies will be updated, or even which modules will survive or be removed.

The most important thing to remember about Drupal 9 is that it is not really about new features, which developers have claimed will be few if any at all. The entire point of the upgrade is to ensure a general migration from older versions, which will not have any security updates going forward past 2021.

If you or your company use Drupal, be sure to keep checking the O8 blog for more updates on this release as they become available.

Tips from the Dev Team: Using Config Split and Config Ignore to Fine-Tune Your Configuration Management Process

One of the many great features introduced in Drupal is configuration management. This enables developers to easily push configuration changes from their development environment to staging, then production environments. It is a robust way to ensure that all of our content types, views, menus, and other settings are correctly deployed with minimal manual work.

What is configuration and what is content?

One of the challenges with configuration management is that there can be a fuzzy line between what is content and what is configuration. Content should not be exported as configuration: Editors and web designers should be free to change that content without it being overridden when the configuration is imported again.

Some elements are easy to divide into configuration and content: A menu is a configuration, but menu links are content. Block placement is configuration but custom block content is content. A taxonomy vocabulary is a configuration, but the term items are content.

But there are some types of elements that are a little fuzzier. Take, for example, a webform. A form is a configuration, but it also has content fields such as an instructions field and a thank-you message.

On the O8 website, we found that there were some configuration items that changed often on production while the marketing team did their work. Every time we pushed new configuration to production we would have to make sure to export these changes and commit them to git without accidentally overwriting the new configuration we were trying to deploy. We needed a better solution.

Developers also commonly use several utility modules while doing their work: we also need to make sure that this configuration is not enabled on production.

Luckily, there are a few additional modules we can use to solve these problems: Config Split and Config Ignore.

Using Config Split for development configuration

Config split is an excellent way to create a set of configurations that should only be enabled in certain environments. The classic use case for this is for modules and settings that are only needed for development work.

Follow these steps to implement a development-only config split:

Download and install Config Filter and Config Split modules
Move your main configuration directory to a subdirectory if it isn’t already in one (e.g. config/sync). Edit your settings.php file and change the update the main config directories path to the new subdirectory:
```
$config_directories[CONFIG_SYNC_DIRECTORY] = '../config/sync';
```
Create a directory for your new config split (e.g. confg/dev)
Set up the config split:

Make sure the machine name of your split matches the name of the folder you set up in step 3.
Add your development modules to the config split settings. In this case, we are going to completely split the configuration for Database Logging, Devel, Kint and Stage File Proxy modules.

As you can see, it is possible to export individual configuration items here, or even use wildcrards to select sets of configuration.
To enable this split on your development environment only, add the following line to your settings.local.php file:
```
$config['config_split.config_split.dev']['status'] = TRUE;
```
Export your configuration using drush csex.

You should see that your development modules have been exported to the dev directory set up in step 3. A normal config export using drush cex should respect your config split, but there may be a bug with some versions of drush that prevents this from working. Always make sure to check the unchanged files list in git to make sure your dev config hasn’t accidentally been exported to the main sync directory. If it has, just run drush csex again.

More detailed instructions can be found in the Drupal documentation, including an explanation of when you could choose a Conditional Split instead of Complete Split as described above.

Using Config Ignore for items that change on production

We could have used a config split for our webforms as well, but this presented a few logistical issues. We really don’t need to enable or disable this config in certain environments - we just need to prevent it from being overwritten on production. Config Ignore is a much better fit for this purpose.

Config Ignore simply prevents configuration from being imported. The process for setting this up is simple.

Follow these steps to implement a development-only config split:

In your development site, download and install Config Ignore module.
On the config ignore configuration screen, add the entries that you don’t want to ignore on import:

These machine names match the names of the yml files that are normally exported in a config export and displayed on the Configuration Synchronization screen when there are changes to import. As you can see with the web form example, you can use wildcards here.
Export configuration and deploy to production.
If changes are made to the ignored configuration items, you’ll see something like this when you try to import configuration:

What’s next for Configuration Management

The Configuration 2.0 initiative is a new effort to improve configuration management in Drupal core. Some of the work going on in that initiative will integrate functionality currently provided by config filter and config split (planned for Drupal 8.7), along with fixes for some other ongoing headaches for developers. Find out more about the Configuration Management 2.0 initiative here and here.