Tags: head

64

sparkline

Saturday, August 10th, 2019

Server Timing

Harry wrote a really good article all about the performance measurement Time To First Byte. Time To First Byte: What It Is and Why It Matters:

While a good TTFB doesn’t necessarily mean you will have a fast website, a bad TTFB almost certainly guarantees a slow one.

Time To First Byte has been the chink in my armour over at thesession.org, especially on the home page. Every time I ran Lighthouse, or some other performance testing tool, I’d get a high score …with some points deducted for taking too long to get that first byte from the server.

Harry’s proposed solution is to set up some Server Timing headers:

With a little bit of extra work spent implementing the Server Timing API, we can begin to measure and surface intricate timings to the front-end, allowing web developers to identify and debug potential bottlenecks previously obscured from view.

I rememberd that Drew wrote an excellent article on Smashing Magazine last year called Measuring Performance With Server Timing:

The job of Server Timing is not to help you actually time activity on your server. You’ll need to do the timing yourself using whatever toolset your backend platform makes available to you. Rather, the purpose of Server Timing is to specify how those measurements can be communicated to the browser.

He even provides some PHP code, which I was able to take wholesale and drop into the codebase for thesession.org. Then I was able to put start/stop points in my code for measuring how long some operations were taking. Then I could output the results of these measurements into Server Timing headers that I could inspect in the “Network” tab of a browser’s dev tools (Chrome is particularly good for displaying Server Timing, so I used that while I was conducting this experiment).

I started with overall database requests. Sure enough, that was where most of the time in time-to-first-byte was being spent.

Then I got more granular. I put start/stop points around specific database calls. By doing this, I was able to zero in on which operations were particularly costly. Once I had done that, I had to figure out how to make the database calls go faster.

Spoiler: I did it by adding an extra index on one particular table. It’s almost always indexes, in my experience, that make the biggest difference to database performance.

I don’t know why it took me so long to get around to messing with Server Timing headers. It has paid off in spades. I wish I had done it sooner.

And now thesession.org is positively zipping along!

Friday, August 9th, 2019

Time to First Byte: What It Is and Why It Matters by Harry Roberts

Harry takes a deep dive into the performance metric of “time to first byte”, or TTFB if you using initialisms that take as long to say as the thing they’re abbreviating.

This makes a great companion piece to Drew’s article on server timing headers.

Sunday, July 21st, 2019

5 Keys to Accessible Web Typography | Better Web Type

Some excellent explanations for these five pieces of sensible typography advice:

  1. Set your base font size in relative units
  2. Check the colour of your type and only then its contrast
  3. Use highly legible fonts
  4. Shape your paragraphs well
  5. Correctly use the heading levels

Tuesday, June 18th, 2019

How to Section Your HTML | CSS-Tricks

A deep dive with good advice on using—and labelling—sectioning content in HTML: nav, aside, section, and article.

Friday, March 8th, 2019

Tuning Performance for New and “Old” Friends | Filament Group, Inc., Boston, MA

This is a really clever technique from Scott that he unveiled at An Event Apart in Seattle. It uses a header sent by a service worker to distinguish between returning and new visitors—much neater than relying on a cookie. I’ve updated my service worker on The Session to use this technique now.

Monday, March 4th, 2019

Cache-Control for Civilians – CSS Wizardry

Harry breaks down cache-control headers into steps that even I can understand. I’ll be using this a reference for sure.

Saturday, February 23rd, 2019

Sadly, this is not The Onion

It’s not funny, cause it’s true.

Saturday, September 1st, 2018

Conversational Semantics · An A List Apart Article

I love, love, love all the little details of HTML that Aaron offers up here. And I really like how he positions non-visual user-agents like searchbots, screen readers, and voice assisants as headless UIs.

HTML is a truly robust and expressive language that is often overlooked and undervalued, but it has the incredible potential to nurture conversations with our users without requiring a lot of effort on our part. Simply taking the time to code web pages well will enable our sites to speak to our customers like they speak to each other. Thinking about how our sites are experienced as headless interfaces now will set the stage for more natural interactions between the real world and the digital one.

Saturday, June 23rd, 2018

I discovered a browser bug - JakeArchibald.com

Jake’s blow-by-blow account of uncovering a serious browser vulnerability is fascinating. But if you don’t care for the technical details, skip ahead to to how different browser makers handled the issue—it’s very enlightening. (And if you do care for the technical details, make sure you click on the link to the PDF version of this post.)

Sunday, June 17th, 2018

Detecting image requests in service workers

In Going Offline, I dive into the many different ways you can use a service worker to handle requests. You can filter by the URL, for example; treating requests for pages under /blog or /articles differently from other requests. Or you can filter by file type. That way, you can treat requests for, say, images very differently to requests for HTML pages.

One of the ways to check what kind of request you’re dealing with is to see what’s in the accept header. Here’s how I show the test for HTML pages:

if (request.headers.get('Accept').includes('text/html')) {
    // Handle your page requests here.
}

So, logically enough, I show the same technique for detecting image requests:

if (request.headers.get('Accept').includes('image')) {
    // Handle your image requests here.
}

That should catch any files that have image in the request’s accept header, like image/png or image/jpeg or image/svg+xml and so on.

But there’s a problem. Both Safari and Firefox now use a much broader accept header: */*

My if statement evaluates to false in those browsers. Sebastian Eberlein wrote about his workaround for this issue, which involves looking at file extensions instead:

if (request.url.match(/\.(jpe?g|png|gif|svg)$/)) {
    // Handle your image requests here.
}

So consider this post a patch for chapter five of Going Offline (page 68 specifically). Wherever you see:

if (request.headers.get('Accept').includes('image'))

Swap it out for:

if (request.url.match(/\.(jpe?g|png|gif|svg)$/))

And feel to add any other image file extensions (like webp) in there too.

Thursday, September 21st, 2017

Understanding the WebView Viewport in iOS 11 - Ayogo Health Inc.

One more reason not to use sticky headers on mobile.

Tuesday, September 5th, 2017

thebaer/MMRA: Make Medium Readable Again — a browser extension

I’ve gotten a little tired of showing up to a Medium-powered site on a non-medium.com domain and getting badgered to Sign Up! or Get Updates! when I’m already a Medium user.

A Chrome extension to Make Medium Readable Again by:

  • Keeping the top navigation bar from sticking around
  • Hiding the bottom “Get Updates” bar completely
  • (Optionally) hiding the clap / share bar
  • (Optionally) loading all post images up front, instead of lazy loading as you scroll

Shame there isn’t a mobile version to get rid of the insulting install-our-app permabutton.

Tuesday, August 22nd, 2017

What Would Augment Reality? (with images, tweets) · lukew · Storify

Luke has been asking people to imagine ways of augmenting the world. Spimes are back, baby!

Tuesday, July 4th, 2017

Let small include subheadings? · Issue #929 · w3c/html

Here’s an interesting proposal to slightly amend the semantics of the small element so it could apply to the use-case that hgroup was trying to cover.

Sunday, July 2nd, 2017

Sticky headers

A three-part series by Remy looking at one interface pattern (a sticky header) and how his code evolved and changed:

  1. Sticky headers
  2. Smooth scroll & sticky navigation
  3. CSS sticky nav & smooth scroll

Monday, February 20th, 2017

Do we need a new heading element? We don’t know - JakeArchibald.com

Jake is absolutely spot-on here. There’s been a lot of excited talk about adding an h element to HTML but it all seems to miss the question of why the currently-specced outline algorithm hasn’t been implemented.

This is a common mistake in standards discussion — a mistake I’ve made many times before. You cannot compare the current state of things, beholden to reality, with a utopian implementation of some currently non-existent thing.

If you’re proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn’t.

Jake rightly points out that the first step isn’t to propose a whole new element; it’s to ask “Why haven’t browsers implemented the outline for sectioned headings?”

(I added a small historical note in the comments pointing to the first occurrence of this proposal way back in 1991.)

Sunday, September 25th, 2016

Responses To The Screen Reader Strategy Survey | HeydonWorks

Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.

Tuesday, August 9th, 2016

Start Building Accessible Web Applications Today - Course by @marcysutton @eggheadio

A great series of short videos from Marcy on web accessibility.

Sunday, June 26th, 2016

Sticky headers

I made a little tweak to The Session today. The navigation bar across the top is “sticky” now—it doesn’t scroll with the rest of the content.

I made sure that the stickiness only kicks in if the screen is both wide and tall enough to warrant it. Vertical media queries are your friend!

But it’s not enough to just put some position: fixed CSS inside a media query. There are some knock-on effects that I needed to mitigate.

I use the space bar to paginate through long pages. It drives me nuts when sites with sticky headers don’t accommodate this. I made use of Tim Murtaugh’s sticky pagination fixer. It makes sure that page-jumping with the keyboard (using the space bar or page down) still works. I remember when I linked to this script two years ago, thinking “I bet this will come in handy one day.” Past me was right!

The other “gotcha!” with having a sticky header is making sure that in-page anchors still work. Nicolas Gallagher covers the options for this in a post called Jump links and viewport positioning. Here’s the CSS I ended up using:

:target:before {
    content: '';
    display: block;
    height: 3em;
    margin: -3em 0 0;
}

I also needed to check any of my existing JavaScript to see if I was using scrollTo anywhere, and adjust the calculations to account for the newly-sticky header.

Anyway, just a few things to consider if you’re going to make a navigational element “sticky”:

  1. Use min-height in your media query,
  2. Take care of keyboard-initiated page scrolling,
  3. Adjust the positioning of in-page links.

Friday, May 13th, 2016

Not OK, Computer — Track Changes

Ah, how I wish that this were published at a long-lived URL:

The one part of the web that I believe is truly genius, and that keeps standing the test of time, is the URI. The Web gave us a way to point to anything, forever. Everything else about the web has changed and grown to encyclopedic lengths, but URIs have been killing it for decades.

And yet the numbers show we’re hell-bent on screwing all that up with link-shorteners, moving URIs without redirection, and so forth. As always happens in technology we’ve taken a simple idea and found expedient ways to add fragility and complexity to it.