Building a Lean, Mean – Drupal Theme

View Github Repository Open presentation in a new window

startinggravity

See all presentation from startinggravity

Building a Lean, Mean – Drupal Theme

0 0

lean-drupal

Turn your flabby and out-of-shape website into a fit and robust machine!

On Github startinggravity / lean-drupal

Building a Lean, Mean

Drupal Theme

Presented: July 23, 2015 at DrupalGovCon August 15, 2015 at Drupal Camp Asheville October 17, 2015 at Drupal Camp Atlanta November 7, 2015 at Drupal Camp Chattanooga

Welcome.

Jim Smith

About me.

Get the home versionfor hours and hours of fun!

HTML: http://bit.ly/lean-drupal

PDF: http://bit.ly/lean-drupal-pdf

View this presentation anytime.
What we plan today...

Why do we careabout performance?

  • Fast sites make impatient users happier.
  • Happy users view more pages.
  • Happy users buy more stuff.
  • Fast sites are cheaper to host.
  • Clean code is easier to maintain.
Isn't everyone using a high-speed connection?

How much does the average web page weigh?

How much does the average web page weigh?

Size of average web page

(top 1000 websites)

  • More than 1600K

source: WebsiteOptimization.com (July 2014)

WebOptimization.com looks at performance in an annual study. The most recent study shows an average size of a web page is more than 1600K.

Number of objects in average web page

(top 1000 websites)

  • About 112 objects

source: WebsiteOptimization.com (July 2014)

The number of objects in an average web page is 112.

source: WebsiteOptimization.com (July 2014)

From the looks of this chart, which shows average page weight in purple and average number of objects in green, pages aren't going to get any smaller on their own.

Just because we think we have a lot of bandwidth doesn't mean we must use it.

source: Micha Godbolt (@michagodbolt) - July 20, 2015

see also: The Verge's web sucks

Just because we think we have a lot of bandwidth doesn't mean we must use it. This tweet from Micah Godbolt illustrates that very well.

Delaying page load time by one second

  • Conversions drop by 7%
  • Page views drop by 11%
  • Customer satisfaction drops by 16%

source: Aberdeen Group (November 2008)

Delaying page load by just one second has a big impact on user experience.

Something simple like choosing and optimizing images

  • Etsy found when an extra 160KB of images were added to a page, their bounce rate on mobile devices increased by 12 percent

source: "Web performance is user experience" (O'Reilly Radar, January 14, 2014)

Something simple like choosing and optimizing images can have a big effect on user experience, especially on mobile.

Don't be slow.

It's obvious we don't want to be slow, but...

How do we go faster?

How do we go faster?

But wait...

Before we get to the answers of that question, there are a few things we have to understand first.

Assumptions

  • Every site will have different requirements, different libraries, different needs.
  • The fastest request you will ever make is the one you don’t make.
Before we begin we have to make a couple assumptions.

Limits to connections

Connectionss per Hostname and Total Connections

source: Browserscope.com

There is a limit to number of concurrent connections by hostname and in total, and the number varies by browser.

20% Rule

For a performance change to be noticeable, it must be at least 20% faster than your previous performance.

source: apmblog.dynatrace.com

The 20 percent rule doesn't mean every change you make should be a 20% or more improvement.

Performance Golden Rule

80-90% of the end-user response timeis spent on the frontend.

Start there.

source: Steve Souders Blog

Roughly 80 percent of end-user response time is consumed by the frontend.

Backend vs. Frontend

source: Steve Souders Blog

This is a performance waterfall chart taken from Linkedin showing all of the requests made in a page and the length of time taken to download them.

Backend vs. Frontend

  • Backend: The time it takes the server to send the first byte to the browser.
  • Frontend: Everything else.

source: Steve Souders Blog

Backend includes the bulk of server processing: database lookups, remote web service calls, stitching together HTML, etc. Frontend processes include executing JavaScript and rendering the page. Also included here is network time for downloading resources.
Finally, now we're going to get down to the nuts and bolts of web page performance.

6 Ways to Speed Up Your Site

1. Cache everything you can2. Clean up Drupal's cruft3. Clean up your code4. Concatenate and minify your code5. Deliver assets efficiently6. Set a performance budget and test against it We will cover six ways in which you can speed up your site.

Some of this information will berendered obsolete by HTTP/2 and Drupal 8!

The HTTP/2 protocol is slowly being adopted, so some of the information like concurrent connections will be obsolete.

Cache everything you can

"The first rule of optimization and caching is this: never do something time consuming twice if you can hold onto the results and re-use them."

source: Jeff Eaton (Lullabot Blog)

Cache everything you can

The first one is so basic you probably always do it, but are you taking advantage of the others? Views caching is often overlooked, especially with blocks. Normal block caching does not include Views blocks. Views Content Cache module monitors content in a View and clears the cache when the content changes. Boost copies Drupal pages as flat HTML files and stores them in a cache directory.

Cache everything you can

  • Larger sites should use Memcache or Varnish (must be installed on your server)
The next level of caching requires components and configuration on your server. They cache pages to memory instead of the file system and are therefore even faster.

Clean up Drupal's cruft

"There are a bazillion reasons why Drupal is slow, but the main one is because you weren't paying attention."

source: Dan Kegel's Web Hostel

Clean up Drupal's cruft

  • Don't use core's Update module
  • Don't use core's Statistics module
  • Use Fast 404 module
  • Turn off, and if possible, remove every unnecessary module
  • Don't install a module unless there's no way to avoid it

There's no need to poll Drupal.org on a module's status from your production site. You can do that from a dev site. Don't use core's Statistics module. Let Google Analyitics or another analytics service provide that information. Drupal does a full bootstrap for every 404 error, which consumes a lot of resources. Turning off and removing unnecessary modules may seem obvious when you think about it, but it's easily overlooked. "There's a module for that" is a apt expression, but just because a module exists does not necessarily mean it needs to be installed.

Clean up your code

source: Mario Hernandez (Mediacurent Blog)

Clean up your code

  • Follow Drupal's best practices for themes
  • Use a base theme that is inherently clean of unnecessary <divs> and classes
  • Use custom theme template files to remove unnecessary stuff
  • Use Fences module
  • Better yet, create a custom theme without a base theme

Always follow best practices. Not only are you making your code mode efficient, you are making the work of anyone who touches the code more efficient. There is a lot of unnecessary stuff in many template files. Some base themes like Zen, Mothership, Framework and Aurora avoid them. Overriding these with custom files is not difficult. Fences module allows you to specify an HTML element for each field from the backend UI. Base themes add some overhead you may not need. If you find yourself overwriting a lot of code then maybe you don't need the base theme.

Clean up your code

BEM = Block, Element, Modfier SMACSS = Scalable and Modular Architecture for CSS OOCSS = Object Oriented CSS Falling into specificity traps means you end up writing more code than necessary

Concatenate and minify your code

"There is a reason jQuery calls the minified version the production version and the original source the development version."

source: Matt Farina (The Engineered Web)

Concatenate and minify your code

Core aggregation works reasonable well for smaller sites, but is not efficient for larger sites. AdvAgg: Takes what Magic does to the next level, including minification. The UglifyJS module provides minified JavaScript using an external service. Modernizr lets you build the smallest Modernizr file possible.

Concatenate and minify your code

Gulp-Uglify parses and compresses JavaScript without use of a module or an external service. SVG images are scalable, so they have the added benefit of being responsive. Photoshop does not make images as small as possible. For that you need a lossless compression service or software. Gulp Image Optimization handles image compression on the fly during development.

Deliver Assets Efficiently

"There is real empirical evidence that substantiates the fact that speed is more than a feature. It’s a requirement."

source: Fred Wilson "10 Golden Principles of Successful Web Apps"

Deliver Assets Efficiently

Move JavaScript files to the footer with Magic module. (This does some of what AdvAgg does, but not all.) Picture: Uses picture tag, the best way to deliver images. (Now included in D8. CDN: Allows assests to be distributed to several servers so that requests are delivered from the nearest server. Lazyloader: Images aren't loaded until they are near or in the viewport. Image API Optimize: requires access to the server is install components for compressing images. Prefetch and prerender content using simple link tags in the head of your markup. Site analytics must be studied to make this approach effective.

Deliver Assets Efficiently

Domain sharding splits assets across multiple domains, allowing them to be downloaded in parallel. Inlining CSS and JS eliminates additional roundtrips needed to render a page. Using hosted libraries provide stable, reliable, high-speed delivery of those files

Budget and Test

"When I first heard the concept of a performance budget, I groaned quietly, rolled my eyes, and thought, 'Oh, great. One more technical thing to stand in my way.'”

source: Katie Kovalcin (Happy Cog Blog)

Budget and Test

  • A performance budget is a goal you set for load times on your site.
  • Test representative pages of your site. Do this frequently and consistently.
  • Also run tests against competitor or similar sites.
  • A budget helps you make decisions on what and how things are displayed.
Testing competitive sites helps you look find performance advantages. (Remember the 20% rule!)

How the Performance Budget Affects Development Decisions

  • You may be forced to optimize existing content.
  • Or remove something no longer important.
  • Or leave out a feature that breaks the budget.
You have three choices to make when considering a new feature.

4 Types of Budgets

We can view metrics in four different ways and measure them accordingly.

  • Milestone Timings
  • SpeedIndex
  • Quantity-based metrics
  • Rule-based metrics

source: Tim Kadlec Blog

Simple to understand, but may not give the whole picture because it's simply a count and does not reflect the impact of each request by their weight.

Milestone Timings Budget

Typically, the time to render a page

  • Measures the whole page, not just what the visitor sees
  • Useful if you set your own milestone, such as time to expose a form

Time to render the entire page, which might not be a clear picture of what's going on in the page or how it affects the user.

SpeedIndex

The average time it takes for visible parts of a page to display, expressed in milliseconds and dependent on size of the viewport.

  • An effective test because it measures what a user sees
  • Best measured with WebPageTest.org

Speed index is the average time it takes for visible parts of a page to display, expressed in milliseconds and dependent on size of the viewport.

Quantity-based metrics

A simple counting of all requests issued or the total weight of a page.

  • Easy to measure and easy to track during development
  • Tells you nothing about user experience

Simple to understand, but may not give the whole picture because it's simply a count and does not reflect the impact of each request by their weight.

Rule-based metrics

More a checklist of optimizations you should be doing.

Using a score, rather than an actual data point. Shown here is Chrome PageSpeed Insight.

When we follow as many of these guidelines for web performance we have happy stakeholders, happy developers, happy sysdamins, and most importantly, happy users.
Thank you.
Questions?

Find this presentation

HTML: http://bit.ly/lean-drupal PDF: http://bit.ly/lean-drupal-pdf

Find me

0