Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jan 05 2024
Jan 05
Amanda LukerAmanda Luker

Amanda Luker

Web Chef Emeritus

Amanda is responsible for translating visual designs and applying them to Drupal sites.

January 5, 2024

Drupal provides a system for site administrators to add their own images and have them appear uniformly on the website. This system is called Image Styles. This tool can resize, crop, and scale images to fit any aspect ratio required by a design.

When creating responsive websites, a single image style for each image variation is insufficient. Each image, such as a hero image, a card image, a WYSIWYG image, or a banner image, requires multiple versions of one image. This ensures that the website delivers only what visitors need based on their screen size. For instance, a mobile user may only require a 320-pixel-wide image, while a large desktop user may want an 1,800-pixel-wide image (doubled for double-pixel density). For this reason, Drupal has Responsive Image Styles, which will group your images into a set of styles that will each show under different conditions.

Practical approach to convert images from design to Drupal

  • Determine your image’s aspect ratio. If you find that the images in the design are not in a common aspect ratio (like 1:1, 2:1, 4:3, or 16:9) or if they vary by a little bit, consider running the dimensions through a tool that will find the closest reasonable aspect ratio.
  • Determine the smallest and largest image sizes. For example, for a 16:9 aspect ratio, the smallest size might be 320 pixels x 180 pixels, while the largest could be 3,200 pixels x 1,800 pixels (doubled for high-density screens).
  • To generate all variations, you can use an AI tool to print images with 160-pixel increments between each size. 160 increments tend to hit a lot of common breakpoints. Here’s an example using GitHub CoPilot:

There are likely more ways to streamline this process with Copilot. I’ve also used ChatGPT to rewrite them using a prefix, making it easy to add them in Drupal like this:

Drupal image styles

If adding all of these steps seems like a lot of work, consider using the Easy Responsive Images module! This module can create image styles for you, allowing you to set your aspect ratios and the increment between each style.

Once you have all your styles in place, create your responsive image styles by following these steps:

  • Choose a name for your responsive image style based on its usage
  • Select the “responsive image” breakpoint group
  • Usually, I choose to select multiple image styles and use the sizes attribute. Use the sizes attribute to craft your “sizes.” For example:

(min-width:960px) 50vw, (min-width:1200px) 30vw, 100vw

In this example, choosing an image that is smaller than 960 pixels will best fit the full width of the viewport. At 960 pixels, the image will be selected to best fill half of the viewport width, and at 1,200 pixels, 30%. This approach is nimble and allows the browser to choose the most appropriate image for each case.

After setting the size rules, choose all of the image styles that you want the browser to be able to use. You don’t have to use them all. In some cases, you might have two responsive image styles that are pulling from the same aspect ratio image styles, but one uses all of them and the other uses a subset of them.

Drupal image sizingDrupal image sizing

After adding your responsive image style, you need to map your Media View Mode:

  1. Go to https://[your-site.local]/admin/structure/display-modes/view/add/media
  2. Add the media view mode as a new Display for Images: https://[your-site.local]/admin/structure/media/manage/image/display
  3. Choose “Responsive image” as the Format and select your new responsive image style

Drupal responsive image manage displayDrupal responsive image manage display

Once you have set this up, you are ready to use the View Mode to display the image field for your entity.

Drupal article with imageDrupal article with image

In this example, all the images have the same breakpoint. There may be times when you need to have different aspect ratios at different breakpoints. In those cases, you may want to use your custom theme’s Breakpoint Group. This will allow you to manually select each image style on for each breakpoint (instead of letting Drupal choose it for you).

Making the web a better place to teach, learn, and advocate starts here...

When you subscribe to our newsletter!

Jan 18 2018
Jan 18

One of the things we do on an annual basis for our clients at Four Kitchens is an annual site audit — a high level kick-the-tires kind of site inspection. For Drupal sites, we check the logs for any glaring errors, check for overrides in Features, run some SEO and accessibility testing, and, of course, take it for a speed test.

If you run speed tests (like Google’s Page Speed Insights), you have probably seen a common, vexing error: “Render-blocking javascript and CSS.” What’s that?

Pagespeed Insight’s error message for render-blocking assets

Large CSS/JS assets can block rendering “above-the-fold” content. Modern browsers tend to allow concurrent downloading of 6 to 8 files at any given time (a few offer more, now). So developers aggregate and compress CSS and JS files so we have less to load, but that also means front-loading large — though compressed — styles and javascript files. This is a recipe for a log jam.

Here’s how to beat this speed bump. Using the methods described below, I’ve seen Pagespeed Insight scores on Drupal sites increase by 30% or more.

Javascript

For javascript, the solution is fairly easy: ensure the files are in the footer. In Drupal 8, this is already the standard, unless you have added some elsewhere. For your javascript to load in the header, you actually have to set: header: true in your theme’s library.yml file. (Also, be sure you are not loading any javascript that is not needed on the page.) In Drupal 7, you will need to move the files, perhaps using Advanced CSS/JS Aggregation or manually.

If there is specific JS that needs to be there as the page loads, you may want to defer it instead. Again, AdvAgg can help you do that, or you can defer it manually.

CSS

While moving files to the footer technically works for CSS as well, it introduces a new problem: the dreaded FOUC, or “flash of unstyled content.” Put plainly, the content is loading before the styles, so users – especially on slower connections – will see a very ugly site until the page is completely done loading. While not the end of the world, it makes for an unpleasant user experience.

What we do to counter FOUC is load a “Critical CSS” file first. Critical CSS is, as it sounds, any CSS that is crucial to making above-the-fold content appear close to the final product. Think layout, position, readability, sizing – particularly in the header … anything that will smooth a transition to the full CSS loading. These styles will be put in their own file (as straight CSS) and loaded inline, in the page’s .

Place this in your html.html.twig file, in the :

*/

When you view your site, those styles will now load directly .

Now, sifting through your CSS to figure out what is critical is a challenge in and of itself. I’ve tried using automated grunt/gulp tasks (criticalgrunt-criticalgrunt-criticalcss), that will take “snapshots” of styles that have been called for above-the-fold content only on a specific page, but those tools have their limitations. (For instance, you may build your critical CSS file from a snapshot of a wide view of your page, but then it may miss styles needed for a mobile version of the page. Or there are just too many variations page-to-page with a site with dynamic content.) It’s possible some of these projects have improved since I last checked, so it still may be worth looking into.

If you have (wisely) built your styles using discrete files for base, regions, components, etc, you *could* do a compile just of the your base, layout, header, and header component styles and that would put you in a good position to start building your critical CSS file. You could use a tool like Sassmeister to compile outside your normal workflow.

If you haven’t (or you have inherited a site will less precision), you may just end up taking that final, compiled CSS file, un-compressing it, and doing your best to grab styles for the header and top part of the body (taking special care for the homepage.) Like I said, it’s an imprecise science.

Once the critical CSS is in place, you can try moving the rest of the CSS in the footer. In Drupal 8, this means moving this line in html.html.twig:





Move it down to before the closing   tag.

In most cases, fine tuning what should be in the Critical CSS file takes a little trial and error.

Like with any style changes, make sure you review in a variety of browsers, devices and widths. Also, be sure to try throttling your page speed, under the Google Chrome web inspector’s Network tab. This allows you to simulate a slower network. 

Network tab of Chrome’s web inspector

Note that you will need to maintain this new file. Any time you make changes to things included in the Critical CSS file, you will need to manually adjust it. 

A final word of caution: you may very well be shifting around some structural stuff, and regressions can happen, especially at that level. Testing is very important — by you, and by the client, particularly on inherited sites. In a dream world, we’d have ubiquitous and comprehensive visual regression testing tools to catch anything that might have changed in the underlying load order of styles — but that level of safety netting is rare!

With all this in mind, you can plan for a critical CSS file for the next project that requires stellar performance: start out with all the javascript in the footer, prepare your CSS in compartmentalized Sass files that can be funneled to a critical CSS file, run speed tests throughout the project to see where problems are introduced, and, since you won’t want to maintain it during development, hold off until near-launch to generate your inline critical CSS file. 

Making the web a better place to teach, learn, and advocate starts here...

When you subscribe to our newsletter!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web