HTML, CSS, JavaScript, Browsers, Server Side Stuff (?) More JavaScript Any and all frameworks that deliver stuff to the web are an abstraction of these technologies. When in doubt, or trouble, or fatigue, return to the basics. The web stack
Get to know your browsers The only requirements to connect to the web are an internet connection, and a web browser. Browsers are the gates to your sites and apps, and you should really get to know the keepers. https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/
Browser Anatomy Your browser reads the HTML it receives and turns that into the DOM. It reads from top to bottom, and any asset it comes across, it will try to download before continuing. This is why your CSS goes at the top, and your JavaScript at the bottom of the page. This is also why it’s important to minify and aggregate. The less code the browser has to go through, and the least amount of stops along the way*, the better. *in current HTTP protocol
Always load responsibly Always serve the least possible amount of code. Favor systems that require you to turn on features, rather than turn off the ones you’re not using. The goal is to only send what is absolutely critical to render the page, and asynchronously load the rest.
Smarter Drupal asset attachment Make sure to only add a CSS or JS asset where needed. Don’t add things used on certain pages to your global assets. With Drupal 8 libraries, this becomes very easy to do. Twig makes it simple to load the library conditionally from the exact level that needs it.
In summation ● Smallest amount of code needed ● CSS at top, JS at bottom ● Minify, uglify, aggregate ● Async load assets where possible ● Make sure assets are loaded only where needed
Makes me sound smarter than I am A tool for measuring your site, under varied conditions, with visual reports of your asset waterfall, and the time requirements of each. The most invaluable tool in my performance utility belt. webpagetest.org
Insert saying about measuring and cutting Performance is like the blueberries in blueberry muffins. You can’t bake it in after the fact. Performance needs to be a consideration during all phases of the project. Measuring the impact of decisions before they hit the production servers is imperative. Things like performance budgets are key to fighting the continued upward spiral of our web page sizes.
How good is good enough? The Dream is 1k speed index (like golf, the lower the better) and under a 1 second start render. This is a very lofty goal, and in the wild anything under 2k speed index is acceptable, but could have a performance sprint done. Speed Index is the average time at which visible parts of the page are displayed. https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics /speed-index
At what cost The web is “prettier” today than ever before, but it’s also freaking huge. The average site now clocks in at 2.3MB, with images a staggering 1.4MB on average. Holy moly. As web developers, that’s our fault, and if our best excuse is someone paid us then shame on us.
Education and minification Often clients are the ones uploading massive hero images, instead of following the guidelines your team meticulously crafted. I hear you. Routinely check your sites, find the bad images, and email somebody. Talk about image sizes in meetings, often, make it a priority. Find a desktop app that works, or a service to automate. Don’t settle for slow. tinypng.com, compressor.io, ImageOptim
Not just max-width: 100% A responsive image solution is an absolute must in a modern, performant website. Minification is great, but serving up a 2000 width image to a person on a phone is still evil. Plus, it’s not so bad. path/to/large.jpg 1200w” /> https://www.html5rocks.com/en/tutorials/responsive/picture-element/
Responsive images & Drupal Breakpoint and Responsive images are core in 8! Yay! 7 you’ll want to grab the breakpoints and picture contrib modules. They both allow you to define breakpoints, and map image cache sizes to them, generating the output for you.
It’s all math, man SVGs are code, and your browser likes code, it likes it a lot. It sends code heart emojis. Drupal 8 uses and recognizes SVGs by default. Drupal 8 loves code, too. What should we use SVGs for? Icons, logos, anything that can be cleanly represented as a vector image. The lifestyle photos of the city skyline you’re pretty sure is your city are still better as jpgs.
That’s right, SVG icons SVG icons are better than font icons. https://css-tricks.com/icon-fonts-vs-svg/ Smarter peeps than me have said it, but can confirm. The best reason I’ve heard in favor of font icons boils down to developer experience. Don’t choose tools that make yours or your team's life easier over your end-users’.
SVG icons tl:dr; 1. They’re code, so they get gzipped 2. Easy to build a SVG sprite of only the icons needed 3. Can be embedded to avoid an HTTP request 4. Relatively simple syntax 5. Complete control over each icon 6. Can do more advanced styling / animations
Inling your critical assets Because the browser chokes on any asset it has to download, the absolute fastest way to render a website is to inline the CSS needed to render the in-view page and async load the rest. Sounds weird, and it is a little, but it works. https://www.smashingmagazine.com/2015/08/understanding-critical-css/ https://www.fourkitchens.com/blog/article/use-grunt-and-advagg-inline-critical -css-drupal-7-theme
bollskis
fornewid
cocoeyes02
dalinaum
yatasunshine
pluu
okaharuna
hsawaji
shohata
tsukushi
pulse1923
junk0612
sr2mg4
michaelherold
bluesmoon
bkeepers
lemiorhan
cromwellryan
thoeni
phodgson
keithpitt
geoffreycrofte
skipperchong
csswizardry
mongodb