Post pobrano z: Don’t just copy the @font-face out of Google Fonts URLs

I don’t think this is an epidemic or anything, but I’ve seen it done a few times and even advocated for. This is what I mean…

You go to Google Fonts and pick a font like Open Sans, and it gives you either a <link> or an @import with a URL there in which to ready this font for usage on your site.

You can take a peek in there and see what it returns…

It’s just some @font-face declarations, of course!

Now your performance-minded brain kicks off. Wait. So, I make one HTTP request for this stylesheet, and then it makes more HTTP requests for those woff2 files it’s linking up. Screw the middle man here, why not just copy those @font-face blocks right out of here and use them.

You can! But!

The issue is that Google does fancy Google things here and the contents of that original stylesheet changes based on the browser requesting it. That screenshot above is Chrome 66. Here’s Firefox 20 on Windows 7:

It’s different! It’s only got woff, not woff2. If we open that URL in IE 8, we’d get an @font-face block that includes the eot format!

The point is, what that URL gives is very specific to what the current browser needs. That’s a pretty cool thing to abstract away and not worry about. Should new browsers have new formats and new CSS syntax needed, that’ll just come along for the ride.

Not that Google Fonts is perfect with this stuff. For example, by not controlling your own @font-face blocks, you can’t take advantage of font-display, which is a shame. Maybe we’ll get that someday, or maybe it’s worth self-hosting your Google Fonts, which is another whole thing we’ll get into someday.

The post Don’t just copy the @font-face out of Google Fonts URLs appeared first on CSS-Tricks.

Post pobrano z: The Four Big Ways Jetpack Helps with Image Performance

We’ve been working with Jetpack around here as a sponsor. It’s a great match because as someone with a bunch of self-hosted WordPress sites, Jetpack is one of those no-brainer plugins for me. Jetpack can do a ton of good things for any site in a variety of very different ways. Here’s one way to think about it: it brings the power of WordPress’ own massive servers to you.

For now, let’s just focus on one angle of what Jetpack can do for you: image performance. Jetpack does a ton for you in this regard, solving some non-trivial performance upgrades. Let’s take a look at what I see as the four big boosts you get from Jetpack on your images.

1) WordPress does responsive images for you

OK, I cheated with the first one because you don’t actually need Jetpack to benefit from this. But it’s an important and foundational concept for fast images. Just by using WordPress, you get basic responsive images for free.

If you already know what I’m talking about, here’s an example of the output you’ll see in the DOM of a published WordPress post with an image in it uploaded via the Media Uploader:

If you are new to the idea of responsive images, the big idea is this: rather than a single image going to any browser visiting your website, you have multiple images in different sizes and the most-correct one is delivered. Imagine instead of a mobile phone downloading a 1600 pixel wide image (way bigger than it needs), it only downloads a 320-pixel wide image, saving a ton of downloading time.

We’ve written lots about responsive images over the years.

2) You get a CDN

Read a bit about web performance and you’ll be unanimously told: „use a CDN.” A CDN is a Content Delivery Network, essentially web servers designed specifically to make serving assets like images super fast. They call it a network because it isn’t just one server, it’s many servers physically located all over the world so that when your website is requested from different locations all around the world, the files being sent back come from geographically closer locations (faster!). Not to mention it does other clever things like not requiring cookies for each web request like your own server probably does.

Literally, flip a switch in Jetpack and you’ll be using an image CDN:

It’s called Photon.

Site speed is impacted by many factors and one of them is content delivery. Using what is referred to as a content delivery network (or CDN) helps by:

• Delivering your content from high-speed and dedicated data centers.
• More files can be downloaded simultaneously by the browser.
• Distributed data centers (ie in different geographic locations) improve download speeds and provide redundancy.
• By distributing load and save bandwidth you reduce your existing hosting costs (or keep them in check).

3) You get optimization

Una Kravets calls image optimization an easy performance win for designers. It’s an easy thing to see. Try taking a screenshot of something, exporting something from Photoshop, or grabbing some stock photography. Then drop it onto a tool like ImageOptim and watch the bytes fall away as it optimizes it. Massive savings.

But wouldn’t it be nice if it wasn’t on you to manually optimize all your images before using them? Computers are supposed to help us with menial tasks, right?! When you flip on the CDN feature of Jetpack, your images are now hosted on Photon, and you can see in the Photon docs how it handles things like resizing and quality for you.

4) You get lazy loading

Lazy loading is the idea that you don’t load anything at all unless you need it. In the case of images, don’t download the image unless it’s visible on the page. As in, don’t download an image that is three quarter down an article that a user might never scroll down to, but if they do, then download it.

You know what they say, the fastest web request is one that is never made. Jeremy Wagner, for Google, says:

When we lazy load images and video, we reduce initial page load time, initial page weight, and system resource usage, all of which have positive impacts on performance.

This is another flip-a-switch feature that works on any theme. Turn it on, you got lazy loading.

All Together Now

1. You get responsive images with WordPress, which by itself can be a major performance win.
2. With Jetpack, those responsive images are CDN-hosted, providing a speed boost and great caching for the images that are downloaded.
3. Just because you’re using responsive images and a CDN doesn’t automatically mean those images are optimized, but they are on Photon.
4. Last, nothing is downloaded at all unless the images are in view (lazy loading), which is the most efficient thing you can do.

Pretty compelling.

The post The Four Big Ways Jetpack Helps with Image Performance appeared first on CSS-Tricks.

Post pobrano z: Building a RSS Viewer With Vue: Part 2

Welcome to Part 2 of this mini-series on building a RSS viewer with Vue. In the last post, I walked through how I built my demo using Vue.js and Vuetify on the front end and Webtask on the back end. When I built that initial version, I knew it was exactly thatmdash;an „initial” version. I took some time to work on a few updates, and while I won’t dare call this a „perfect” version, I do think I’ve made some improvements and I’d like to share them with you.

Before I get started, here are links to the completed demo and source code.

Feel free to fork, file PRs, and report bugs to your heart’s content!

The Plan

When I shared the initial version in Part 1, I outlined some ideas to improve the RSS reader, including:

• Moving to Vuex.
• Starting to switch to components in the layout. (Well, I was already using Vuetify components, but I meant custom components for my application.)
• Using IndexedDB to store feed items for quicker access and offline support.

That was the plan, and like most plans, I wasn’t necessarily able to hit everything in this update (and I’ll explain why at the end). But hopefully you’ll see the improvements as a general „moving in the right direction” for the application. With that out of the way, let’s get started!

Implementing Vuex

I’ll start off discussing the biggest change to the application, the addition of Vuex. As I said in the previous post, Vuex describes itself as a „state management pattern + library” on their „What is Vuex” page. No offense to their documentation, but I had a difficult time wrapping my head around exactly what this meant, from a practical sense.

After having using it in a few small projects now, I’m coming to appreciate what it provides. To me, the core benefit is providing a central interface to your data. If I’ve got a basic Vue app working with an array of values, I may have multiple different methods that modify it. What happens when I begin to have certain rules that must be applied before the data changes? As a simple example, imagine an array of RSS feeds. Before I add a new one, I want to ensure it doesn’t already exist in the list. If I have one method that adds to the feed list, that isn’t a problem, but if I have more, it may become cumbersome to keep that logic in sync across the different methods. I could simply build a utility to do this, but what happens when I have other components in play as well?

While it is absolutely not a one-to-one comparison, I feel like Vuex reminds me of how Providers or Services work in Angular. If I ever want to do work with any data, I’ll ensure I use a central provider to handle all access to that data. That’s how I look at Vuex.

So the big change in this application was to migrate all the data related items to a store. I began by adding the library to my HTML:

<script src="https://unpkg.com/vuex"></script>

Woot! Half-way done! (OK maybe not.)

I then created an instance of my store in my JavaScript file:

const feedStore = new Vuex.Store({
  // lots of stuff here
});

and included it in my Vue app:

let app = new Vue({ 
  el: '#app',
  store:feedStore,
  // lots of stuff here too...
});

Now comes the interesting part. Any time my Vue application needs data, which primarily consists of the list of feeds and the items from those feeds, it’s going to ask the store for them. So, for example, my feeds value is now computed:

feeds() {
  return feedStore.state.feeds;
},

This is now defined in the state portion of my store:

state: {
  allItems: [],
  feeds: [],
  selectedFeed: null
},

Notice that feeds defaults to an empty array. I had previously used the created event of my Vue app to read in the data from localStorage. Now, I ask the store to do that:

created() {
  feedStore.dispatch('restoreFeeds');
},

Back in the store, the logic is pretty much the same:

restoreFeeds(context) {
  let feedsRaw = window.localStorage.getItem('feeds');
  if(feedsRaw) {
    try {
    let feeds = JSON.parse(feedsRaw);
    context.state.feeds = feeds;
    context.state.feeds.forEach(f => {
      context.dispatch('loadFeed', f);
    });
    } catch(e) {
      console.error('Error restoring feed json'+e);
      // bad json or other issue, nuke it
      window.localStorage.removeItem('feeds');
    }
  }
},

I say „pretty much the same” except now I’m doing a bit of error-checking on the value read in from localStorage. But here’s the crucial bit. I already said I failed in terms of switching to IndexedDB, but in theory, I could build a third version of this application with an updated store and my Vue app won’t know the difference. And that’s where I started to get really excited. The more I worked, the more „dumb” my Vue app became and the less tied it was to any particular implementation of storage. Let’s look at the complete Vue app now:

let app = new Vue({ 
  el: '#app',
  store:feedStore,
  data() {
    return {
      drawer:true,
      addFeedDialog:false,
      addURL:'',
      urlError:false,
      urlRules:[],
      selectedFeed:null
    }
  },
  computed: {
    showIntro() {
      return this.feeds.length == 0;
    },
    feeds() {
      return feedStore.state.feeds;
    },
    items() {
      return feedStore.getters.items;
    }
  },
  created() {
    feedStore.dispatch('restoreFeeds');
  },
  methods:{
    addFeed() {
      this.addFeedDialog = true;
    },
    allFeeds() {
            feedStore.dispatch('filterFeed', null);
    },
    addFeedAction() {
      this.urlError = false;
      this.urlRules = [];

      feedStore.dispatch('addFeed', {url:this.addURL})
      .then(res => {
        this.addURL = '';
        this.addFeedDialog = false;
      })
      .catch(e =>{
        console.log('err to add', e);
        this.urlError = true;
        this.urlRules = ["URL already exists."];                                
      });
    },
    deleteFeed(feed) {
      feedStore.dispatch('deleteFeed', feed);
    },
    filterFeed(feed) {
      feedStore.dispatch('filterFeed', feed);
    }
  }
})

What you’ll notice is that pretty much all of the actual logic is now gone and all I’m really doing here is UI stuff. Open a modal here, add an error there, and so forth.

You can view the complete store here, although I apologize for lumping everything together in one file.

Adding a Component

One of the other changes I mentioned was beginning to „component-ize” the view layer. I ended up only making one component, feed-item. This reduced the total number of lines in the HTML a bit:

<v-flex xs12 v-for="item in items" :key="item.link">
  <feed-item :title="item.title" :content="item.content" :link="item.link" :feedtitle="item.feedTitle" :color="item.feedColor" :posted="item.pubDate"></feed-item>
</v-flex>

It isn’t a huge change by any means, but it did make it bit easier for me when I started working on the feed display. As I’m not using a fancy builder yet, I defined my component straight in JavaScript like so:

Vue.component('feed-item', {
  props:[
    'color','title','content','link','feedtitle', 'posted'
  ],
  template: `
  <v-card :color="color">
    <v-card-title primary-title>
      <div class="headline">{Building a RSS Viewer With Vue: Part 2} ({{posted | dtFormat}})</div>
    </v-card-title>
    <v-card-text>
      {{content | maxText }}
    </v-card-text>
    <v-card-actions>
      <v-btn flat target="_new" :href="link">Read on {CSS-Tricks}</v-btn>
    </v-card-actions>
  </v-card>        
  `
});

I’m not doing anything at all fancy in heremdash;there’s no dynamic logic or events or anything like that, but I could certainly add that later where it makes sense. I did finally get around to adding the date and time of posting. If you’re curious about how I built the formatter used for it, read my article Build A i18n Filter Using Vue.js & Native Web Specs.”

The Power of Delete!

Oh, and I finally added a way to delete feeds:

This just fires off a method on the Vue object that, in turn, fires off a call to the store that takes care of removing the feed and items from the UI and then persisting it. A small thing, but, wow, did I wish I had that in the first version when testing. And here is a final shot of everything:

Next Steps… and What Happened to IndexedDB?

As I said in the beginning, this version is still not perfect but I definitely feel better about it. I highly encourage you to share tips, suggestions, and bug reports in the comments below or on the GitHub repo.

So what happened to IndexedDB support? The issue I ran into was how to properly initialize the database. Vuex stores don’t have a concept of a created process. I could have done something like this:

// dummy code for getting feeds
dispatch('getDB')
.then(() =>
  // do stuff
);

Where the getDB action returns a promise and handles doing a one-time IndexedDB opening and storing the value in the state. I may give this a shot later, and again, what I love about Vuex is that I know I can safely do that without interfering with the rest of the application.

The post Building a RSS Viewer With Vue: Part 2 appeared first on CSS-Tricks.