Note: When a design mockup doesn't fit the standard Drupal grid and the client insists on pixel-perfect rendering, a custom theme becomes the only viable solution. We don't force Bootstrap onto Drupal; instead, we translate the mockup into Twig templates so that every block breathes exactly as intended. With extensive experience and 30+ projects on Drupal, we've learned to maximize performance: on a landing page for a conference, we managed to reduce LCP from 3.2 to 1.1 seconds by removing all unused scripts and replacing jQuery with vanilla JS. This also cut TTFB by 200 ms and reduced HTTP requests from 45 to 12. Additionally, we pay attention to accessibility by adding ARIA roles and attributes, improving both UX and SEO.
Why a Custom Drupal Theme Is Faster Than a Ready-Made One
The difference in approach: instead of a monolithic library, we assemble only the necessary components. Compare: a custom theme loads 40% faster than a ready-made one with a ton of extra modules. Budget savings from rework can reach 30%, and maintenance costs drop by 20% due to the absence of unused code.
How to Avoid Bundle Bloat During Theme Development
The first thing we do is analyze the design and slice it into components: header, footer, content grid, cards. For each component, we create a separate Twig template and include only the required CSS/JS via libraries. This eliminates bundle bloat — unlike ready-made themes where unused styles are often pulled in.
What Proper Template Decomposition Provides
Each component resides in its own file: block--system-branding-block.html.twig, node--article--full.html.twig, field--field-image.html.twig. This allows us to override templates precisely without affecting other pages. The result is a clean, maintainable hierarchy and avoidance of conflicts when updating Drupal core. Proper template naming is key to scalability, as recommended in the Drupal Twig documentation.
What's Included in Custom Theme Development
| Step | What We Do | Result |
|---|---|---|
| 1. Analysis | Study the design mockup, slice into components, pick fonts and colors | Mockup decomposition with all states |
| 2. Prototyping | Create info.yml, libraries.yml, basic page Twig templates | Theme structure ready for integration |
| 3. Component layout | Build each component: template + CSS + JS | Pixel-perfect components for all content types |
| 4. Integration | Connect real data, configure fields, images, blocks | Theme works with actual content |
| 5. Performance optimization | Configure image styles, lazy loading, minify resources | Core Web Vitals in the green zone |
| 6. Testing | Check responsiveness, cross-browser compatibility, speed | Test protocol |
| 7. Deployment & documentation | Export the theme, describe structure, hand over access and training | Ready theme + editor instructions |
Example Theme Structure
web/themes/custom/my_theme/ ├── my_theme.info.yml ├── my_theme.libraries.yml ├── my_theme.theme ├── config/ │ └── install/ ├── css/ │ └── components/ ├── js/ ├── images/ ├── templates/ │ ├── layout/ │ │ ├── html.html.twig │ │ └── page.html.twig │ ├── content/ │ │ ├── node.html.twig │ │ └── node--article--full.html.twig │ └── field/ └── screenshot.png CSS/JS Libraries
# my_theme.libraries.yml global: version: VERSION css: base: css/base.css: {} layout: css/layout.css: {} js: js/main.js: { defer: true } dependencies: - core/drupal - core/once slider: version: VERSION css: component: css/components/slider.css: {} js: js/slider.js: {} dependencies: - core/once We attach the library only where needed — via attach_library('my_theme/slider') in the template. This reduces loaded JS volume by 30%. For images, we use native lazy loading via the loading="lazy" attribute (details on MDN).
Example Twig Template for an Article
{# node--article--full.html.twig #} <article{{ attributes.addClass('article', 'article--full') }}> {% if label %} <h1{{ title_attributes.addClass('article__title') }}>{{ label }}</h1> {% endif %} <div class="article__meta"> {% if display_submitted %} <span class="article__author">{{ author_name }}</span> <time class="article__date" datetime="{{ date.attributes.datetime }}">{{ date }}</time> {% endif %} </div> {{ content|without('links') }} </article> Process & Timeline
We work in iterations, showing intermediate results after each stage. Timelines depend on complexity:
| Complexity Level | Timeline | What's Included |
|---|---|---|
| Basic theme | 5–8 days | Templates for articles and pages, responsive layout, libraries |
| With animations and custom blocks | 10–15 days | Slider, lightbox, responsive images, custom blocks |
| Complex theme | from 20 days | Custom admin interface, multiple view modes, complex JS logic |
We provide an estimate after analyzing the mockup. Submit a request — we'll send a commercial proposal within a business day.
Common Mistakes in Custom Theme Development
- Ignoring template hierarchy — If you don't use specific names, Drupal will render generic templates, and custom blocks won't display properly.
- Overloading the global library — All scripts and styles on every page. Correct: only critical CSS globally, the rest async or on demand.
- Forgetting image styles — Without them, images load at original size, harming LCP and CLS.
- Not using Twig debug mode — Without enabling
development.services.yml, it's hard to find the right template to override.
Drupal Twig Template Hierarchy
Drupal uses naming conventions for templates: the more specific the filename (e.g., node--article--full.html.twig), the higher the priority. This allows overriding templates for specific content types or display modes without affecting others.
We guarantee that the custom theme will pass Core Web Vitals in the green zone. Our experience with 30+ projects confirms: proper Twig and minimal dependencies deliver static-level speed. Get a consultation — we'll explain how to implement your project.