Select Page

Category: Performance

How to Increase Your Page Size by 1,500% with webpack and Vue

Disclaimer: This article is mostly satire. I do not think that I am better than you because I once wrote some TypeScript nor do I think that it’s a good thing for us to make web pages bigger. Feel free to misrepresent these views to maximize clicks. You know, there are a lot of articles out there telling you how to make your page smaller: optimize your images, remove extraneous CSS rules, re-write the whole thing in Dreamweaver using framesets. Look,  Walmart just reduced their page size by some numbers, give or take. JavaScript housekeeping: 🗑️ Remove old &...

Read More

A Deep Dive into Native Lazy-Loading for Images and Frames

Today’s websites are packed with heavy media assets like images and videos. Images make up around 50% of an average website’s traffic. Many of them, however, are never shown to a user because they’re placed way below the fold. What’s this thing about images being lazy, you ask? Lazy-loading is something that’s been covered quite a bit here on CSS-Tricks, including a thorough guide with documentation for different approaches using JavaScript. In short, we’re talking about a mechanism that defers the network traffic necessary to load content when it’s needed — or rather when trigger the load when the...

Read More

The Serif Tax

Fonts are vector. Vector art with more points makes for larger files than vector art with fewer points. Custom fonts are downloaded. So, fonts with less points in their vector art are smaller. That’s the theory anyway. Shall we see if there is any merit to it? Open Sans (top) and Garamond (bottom) Let’s take two fonts off of Google Fonts: Open Sans and EB Garamond. The number of points isn’t a dramatic difference, but the seriffed Garamond does have more of them, particularly in looking at the serif areas. It’s not just serifs, but any complication. Consider Bleeding...

Read More

Using React Loadable for Code Splitting by Components and Routes

In a bid to have web applications serve needs for different types of users, it’s likely that more code is required than it would be for one type of user so the app can handle and adapt to different scenarios and use cases, which lead to new features and functionalities. When this happens, it’s reasonable to expect the performance of an app to dwindle as the codebase grows. Code splitting is a technique where an application only loads the code it needs at the moment, and nothing more. For example, when a user navigates to a homepage, there is...

Read More

Fighting FOIT and FOUT Together

Lots from Divya with the setup: There are 2 kinds of problems that can arise when using webfonts; Flash of invisible text (FOIT) and Flash of Unstyled Text (FOUT) … If we were to compare them, FOUT is of course the lesser of the two evils If you wanna fight FOIT, the easiest tool is the font-display CSS property. I like the optional value because I generally dislike the look of fonts swapping. If you want to fight them both, one option is to preload the fonts: But… Preload is your friend, but not like your best friend … preloading in excess can significantly worsen performance, since preloads block initial render. Just like CSS does. Even huge sites aren’t doing much about font loading perf. Roel Nieskens: I expected major news sites to be really conscious about the fonts they use, and making sure everything is heavily optimised. Turns out a simple Sunday afternoon of hacking could save a lot of data: we could easily save roughly 200KB Fonts are such big part of web perf, so let’s get better at it! Here’s Zach Leatherman at the Performance.now() conference: Part of the story is that we might just have lean on JavaScript to do the things we need to do. Divya again: Web fonts are primarily CSS oriented. It can therefore feel like bad practice to reach for JavaScript...

Read More

The Three Types of Performance Testing

We’ve been covering performance quite a bit — not just recently, but throughout the course of the year. Now, Harry Roberts weighs in by identifying three types of ways performance can be tested. Of particular note is the first type of testing: The first kind of testing a team should carry out is Proactive testing: this is very intentional and deliberate, and is an active attempt to identify performance issues. This takes the form of developers assessing the performance impact of every piece of work they do as they’re doing it. The idea here is that we spot the problem before it becomes problematic. Prevention, after all, is cheaper than the cure. Capturing performance issues at this stage is much more preferable to spotting them after they’ve gone live. I think about this type of performance all the time when I’m working on a team, although I’ve never had a name for it. I guess what I’m always thinking about is how can we introduce front-end engineers into the design process as early as possible? I’ve found that the final product is much more performant in when front-end engineers and designers brainstorm solutions together. Perhaps collaborating on a performance checklist is a good place to start? Direct Link to Article — Permalink The post The Three Types of Performance Testing appeared first on CSS-Tricks....

Read More

The Cost of JavaScript in 2018

Even though we mentioned it earlier, I thought this outstanding post by Addy Osmani all about the performance concerns of JavaScript was still worth digging into a little more. In that post, Addy touches on all aspects of perf work and how we can fix some of the most egregious issues, from setting up a budget to “Time-to-Interactive” measurements and auditing your JavaScript bundles. Embrace performance budgets and learn to live within them. For mobile, aim for a JS budget of < 170KB minified/compressed. Uncompressed this is still ~0.7MB of code. Budgets are critical to success, however, they can’t magically fix perf in isolation. Team culture, structure and enforcement matter. Building without a budget invites performance regressions and failure. Super specific and super practical! Surprisingly, Addy mentions that “the median webpage today currently ships about 350KB of minified and compressed JavaScript,” which seems like an awful lot lower than I’d expected, if I’m being honest. The stat that scares me most is that the median webpage takes around fifteen whole seconds until it’s interactive. And pulling all that JS into a Web Worker or caching with Service Workers won’t even make up that time to interaction. Yikes. Another key point: not all bytes are equal. For example, 200KB of JavaScript is not equal to a 200KB JPG image file: A JPEG image needs to be decoded, rasterized, and painted...

Read More

Browser painting and considerations for web performance

The process of a web browser turning HTML, CSS, and JavaScript into a finished visual representation is quite complex and involves a good bit of magic. Here’s a simplified set of steps the browser goes through: Browser creates the DOM and CSSOM. Browser creates the render tree, where the DOM and styles from the CSSOM are taken into account (display: none elements are avoided). Browser computes the geometry of the layout and its elements based on the render tree. Browser paints pixel by pixel to create the visual representation we see on the screen. In this article, I’d like...

Read More

The web can be anything we want it to be

I really enjoyed this chat between Bruce Lawson and Mustafa Kurtuldu where they talked about browser support and the health of the web. Bruce expands upon a lot of the thoughts in a post he wrote last year called World Wide Web, Not Wealthy Western Web where he writes: …across the world, regardless of disposable income, regardless of hardware or network speed, people want to consume the same kinds of goods and services. And if your websites are made for the whole world, not just the wealthy Western world, then the next 4 billion people might consume the stuff that your organization makes. Another highlight is where Bruce also mentions that, as web developers, we might think that we’ve all moved on from jQuery as a community, and yet there are still millions of websites that depend upon jQuery to function properly. It’s an interesting anecdote and relevant to recent discussions about React making a run at being the next thing to replace jQuery: I’m just gonna throw this bomb here: React is the new jQuery There you go. — Sara Soueidan (@SaraSoueidan) May 24, 2018 However! The most interesting part of this particular discussion, for me at least, is where they talk about Flash and the impact it had on the design of CSS3 and HTML5. They both argue that despite Flash’s shortcomings and accessibility issues, it happened...

Read More
  • 1
  • 2
www.000webhost.com