Below we’ll look at the evolution of the protocol and discuss how to evolve our asset delivery strategy to deliver CSS and scripts in the fastest way possible for the latest version.

1997 – HTTP/1.1 – History and Asset Loading Strategies

Implemented in 1997, HTTP/1.1’s main performance pain points were head-of-line-blocking and redundancy of the request header happening for each call.

Connecting to the server, transmitting headers, and requesting data was so time consuming for each file that we tried to get as much as we could into each file we called.

To do this, we preprocessed our scripts and styles in single file calls, inlined code, vulcanized, and made image sprites. It was paramount to limit the number of calls to the server. Much of the internet is still built this way.

2015 – HTTP/2 – Let there be multiplexing.

What is HTTP multiplexing?

From Stack Overflow:

Put simply, multiplexing allows your Browser to fire off multiple requests at once on the same connection and receive the requests back in any order.

As browser support became real in 2015, HTTP/2 offered compressed headers and multiplexing to a single TCP connection. This allows multiple assets to be loaded simultaneously, rendering the page faster.

While this is a vast improvement, there is still a catch.

If any asset being requested within that multiplexed TCP connection experiences packet loss, then the entire group of multiplexed streams after that point would be paused until the data packet could be corrected.

Because TCP doesn’t have any context on the multiplexed files to know which can move on and which can’t, packet loss can have HTTP/2 still dealing with head of line blocking.

HTTP/3 – Now and the Future

HTTP/3 seeks to solve the problems of HTTP/2 by not using the TCP at all and instead using QUIC. Because QUIC provides native multiplexing, lost packets only impact the streams where data has been lost.

But can I use it? Kinda.

Most browsers support it by default. However, (as of this writing) in Safari you need to activate it as an option on your device.

Implications

To take advantage of multiplexing we have to break out of the concatenation mindset where the focus was on limiting calls and have a more nuanced asset delivery strategy prioritizing assets crucial to render.

Most browsers and servers seem to default the concurrent connections to about 100. Smaller files delivered largely simultaneously can drastically improve render time and page speed performance.

Google Page Speed Performance Metrics

Largest Contentful Paint, First Input  Delay, and Cumulative Layout Shift are Google’s strategy to help improve web performance; this is cumulatively named “Core Web Vitals.” The biggest enemy of scoring well in these metrics is render blocking assets.

Luckily HTTP/2/3 gives us ways to address render blocking issues much better than before.

Optimization Strategies

Google’s algorithms will down-rank pages that have pipelines with render blocking resources. However, unused JS and CSS resources are weighted almost as strongly.

Although Google only knows for sure (these algorithms aren’t public), it is likely because unused resources bloat a site’s payload and are often render blocking, resulting in causing the user waiting for resources that aren’t even used on a page.

Taking on the task of eliminating unused CSS and JS can also cut the file sizes of your minified assets. Seek out parts of your code base that aren’t used on every page/post/condition and find ways to dynamically enqueue the related assets.

For example ACF Gutenberg blocks:

It is common practice to be concatenating and enqueueing one large CSS and or JS file for all of your custom blocks. ACF block registration lets you enqueue related assets only if the block is used on a page eliminating unused CSS while not duplicating it by including it inline. This is a reasonably easy enhancement that provides a good result for minimal effort.

Another point of attack could be any global options set via the admin that might trigger a class or attribute change that you are then applying CSS or JS to affect (any global option affecting render). Those styles could be in their own sheet and the condition used to set the class or attribute could be used to enqueue the asset instead.

These kinds of strategies may require a more complicated preprocessing of files and JS route building, but the results will be substantial. You will serve less unused code and by pulling the conditional code out it will also make your concatenated files smaller and therefore less render blocking, leading to faster page loads and better Google ranking.

View the code on Gist.

Finding Balance

Knowing how much there is to be gained it’s easy to over simplify your asset loading strategy by loading every little file independently—going to the opposite extreme. There are limits, however.

Servers and browsers set their own restrictions for concurrent connections so we should focus on loading render driving assets first but related parts of your code base should still be concatenated and minified. Each project is different and will require a slightly different approach but HTTP/2/3 gives us the options to improve end user experience and make the internet generally more efficient.

The post HTTP/2 and HTTP/3 Flipped the Performance Optimization Script appeared first on WebDevStudios.

Did you know that you, too, can join in this effort? If you’re a website owner, whether you have a modest blog or a robust media publishing website, here are some ways that you can help to improve not only your own site, but the internet overall. We even include some suggested reading—articles from our blog—to aid in your journey.

Set up HTTPS

While the whole point of HTTPS is to, of course, add a layer of security to the HTTP protocol of your website, beginning this month (July 2018), Google is now demanding it. Maintaining a secure website means you care about your website visitors. If you still haven’t set up your secure sockets layer (aka SSL), read “How to Set Up HTTPS on WordPress Multisite Without Headaches.”

Think Accessibility

Are you trying to exclude certain readers and/or internet users from accessing your website? If the answer is no, then you had better ensure that your website is accessible by all! First, read the article “How Thinking About Accessibility Can Lead to Success.” And, if you’re a developer who is interested in learning more about building accessible websites, we highly recommend these two pieces here: “Accessibility of Semantics: How Writing Semantic HTML Can Help Accessibility,” and “Accessibility in Chrome DevTools.”

Design Easy-to-Use Web Forms

Not only should the forms (be it a contact form or request for more information) on your website be easy to use, they should also be simple to understand and complete. A long, drawn out form can have a negative impact on the accessibility of your website, too. (See previous recommendation.) Use these “3 Tips for Proper Web Form Design” to help you create forms that your visitors will be happy to fill out.

Speed Up Your Website

Web users hate slow websites! As a matter of fact, so does Google. Do something good for your site, your visitors, and the internet overall: improve the speed of your website today. Read “Ways to Speed Up Your Website” to get started.

Give Back

If you want a safer neighborhood, you should volunteer for your local crime watch committee. If you want to improve your child’s school, join the PTA. It’s the same with the web. Give back.

WDS actively gives back to open-source development and the WordPress community through our Five for the Future contributions. You can give back, too. Read “Five Ways to Contribute to Five for the Future” for ideas on how to donate your time and talents.

The post Making the Web a Better Place appeared first on WebDevStudios.

Every couple months or so, Google seems to like to shake things up a bit and add some new criteria by which they rank sites. One of the most recent of these shakeups was that your site might now be ranked based on whether it supports https. This led to a massive freak out in which everyone and their mom tried to set up HTTPS on their site. Historically, getting HTTPS working isn’t as easy as all that and I’m sure many of you reading this post were either too intimidated by the process or started and then gave up.

Recently I got HTTPS working on my site(s), and I’m going to share with you how I got it working (for free).

What is HTTPS?

HTTPS is, simply, a secure layer on the HTTP protocol we use to access websites. The ‘S’ stands for secure and indicates that all your information to and from this site will be encrypted. Occasionally you’ll see this:  which means that some content linked or referenced on the page was not loaded securely. This is usually the bane of a webmaster’s existence when trying to set up HTTPS on a site. While it’s not inherently bad to serve content that’s not secure, in order for your site to get the happy little green padlock, everything needs to be passed securely — including content you’re linking in from outside of your site.

Why should I care about HTTPS?

Besides the Google rankings, why should you care about securing your site? First of all, as of Google Chrome 68 (coming July 2018) all websites are REQUIRED to use HTTPS.

If you’re running eCommerce on your site, you have to for secure payments. Maybe you can work around this by using a service or platform that takes the transaction part of the shopping experience off your site (like PayPal), but that can be jarring to the user experience. It also inspires trust in your customers to see a green padlock on your site; they know that they can trust you with their business even if you are sending them off to a third party for the transaction and aren’t storing any personal information locally.

But even if you aren’t selling things on your site you should still care about making your site secure. It was recently discovered that the NSA stores huge amounts of data collected from the normal internet usage of people like you and me. Unencrypted sites means that it’s easy for them to get this data, and any additional information/data sent to or from that unencrypted site. While encrypting your site might not be a foolproof way to prevent the NSA from spying on you, it wouldn’t hurt, and it can at least make it more difficult for them to access your data.

Okay, what do I need to do?

SSL certificates range in cost from $5 to $500 depending on where you get them and what they do. I’m not an expert, so I couldn’t even tell you the difference. In a lot of cases you can just contact your host for a security certificate and let them set it up for you, then change your URLs in WordPress.

But that’s not what I did.

A while ago (in fact, not long after Google’s announcement), Cloudflare announced that they’d be offering free SSL to all Cloudflare users, including those (like me) on their free plans. For those of you not familiar with Cloudflare‘s service: they are a DNS service that, among other things, allows you to manage all your domains through their nameservers. In addition to that, they add some additional security and speed-boosting enhancements like caching when you are using their service.

Instead of getting a whitescreen if your server goes down, your users will get either get a message at the top of the page saying that they are looking at a cached version of the page or a Cloudflare error page that says there’s a problem connecting to the server and no cached version of the page could be found (it’s a bit nicer for your users than an Internal Server Error message on a white page). I’ve loved Cloudflare’s free service for years because I like being able to manage all my domains in one place. Having a third-party service managing my nameservers means, too, that if I switch webhosts, I only have one place to make the adjustment to the nameservers (rather than having to go into different domain registrars to change each one individually).

Since I was already using Cloudflare, using Cloudflare’s Universal SSL was a no-brainer and, in fact, when I tested it out on a whim one day–just by putting an https in front of my domain name–I was shocked to see that it actually worked!

Okay, it didn’t really work. There were parts of the page that were broken and not displaying correctly, but the fact that it displayed anything at all, instead of just an error message saying a secure connection could not be made, gave me hope and sent me on the path to set up SSL on my (multi)site.

(Note: Cloudflare’s SSL free certificates have multiple domains on them, so it’s possible that some of those might not be sites you want your site to associate with, especially if you’re doing this for a business or corporate site. This tutorial is assuming you’re like me, and just want to set this up for personal use. Cloudflare is active on Twitter and you can always contact their support staff if you have specific questions or issues.)

For this particular recipe, you will need the following ingredients:

• An account on Cloudflare. Go get one for free if you don’t have one already.
• A WordPress-powered site. I’ll be using my Multisite as an example.
• (Possibly optional) WordPress HTTPS – a plugin that forces HTTPS links across your site(s).
• (Possibly optional if you want mapped domains) WordPress MU Domain Mapping – This is used to easily map custom domains to specific sites on your Multisite.

I’ll assume you have the first two things–a Cloudflare account and a WordPress install. If you have both those things set up and you just throw an https in front of your domain, you’ll probably get something that looks horrible like this:

This is because, as I mentioned before, there are unencrypted elements on the page. There are iFrames serving unencrypted video files and there’s Stylesheets and Javascript serving from http instead of https. All of these things can lead to something that makes you want to cry and claw your eyes out.

This is where WordPress HTTPS comes in. Basically, what WordPress HTTPS does for you is force it so that anywhere on a page where there is an “http://” it’s replaced by an “https://”. Every javascript, every stylesheet, every link, every everything. This is a lot easier to manage than trying to track down every individual unencrypted element on your page and fixing it individually (which I did see suggested when I was working on this).

On Multisite, you can Network Activate WordPress HTTPS and you’ll get a screen like this in your Network Admin:

Here I’ve got all the sites on my network listed, along with their SSL hosts (in this case, all my certificates are “self-hosting,” meaning the host is just your regular, root domain), and a couple checkboxes for some global settings.

Specifically, I’m forcing SSL in the admin (this takes the place of the define( 'FORCE_SSL_ADMIN', true ) that you can define in your wp-config.php file–read more about it in the Codex), and I’m removing unsecure elements from the page. This prevents insecure elements from giving you a broken page or a non-green padlock; anything it can’t explicitly fix, it’ll just drop so you can deal with it later and, in the meantime, get your 100% secure site up and running quickly.

If there are some sites on your Multisite that you don’t care or want to be on HTTPS, you can just force SSL in the admin or just leave those unchecked.

In each site’s admin, I have some additional, granular controls over how HTTPS is handled for that site:

You can see here that those same settings from the Network Admin screen, Force SSL Admin and Remove Unsecure Elements, are repeated, and from here, you can override them if you want. It also automatically maps ShareThis and Gravatar URLs to their secure counterparts, and you can use those as boilerplates for mapping your own domains if and when you come across elements that aren’t secure (but could be at a different/altered URL as opposed to just an https:// version of the existing URL). If you really want to get fancy, you can create filters so that certain parts of your site are secured, but other parts are not.

For me, I wanted the whole site to be secure, and these days, there’s no real reason to not just secure everything (especially if you are doing it for Google rankings or because you’re concerned about privacy).

Now, there’s one other part of this and that’s the Domain Mapping component. Otto has an excellent post on WordPress MU Domain Mapping, and covers it far better than I could. If you’re mapping custom domains to your WordPress Multisite, I recommend checking out his post first. The post is a little old but not much has changed since it was written.

Domain Mapping makes it so that on my Multisite, I can edit the full URL of the domain and map it to a specific site ID. I can do this from the normal Multisite Edit Site screen but I also need to do this from the Domain Mapping Domains page. However, if you’re using Domain Mapping, you still can’t edit the http/https part of the URL.

This needs to be done in the Site Settings tab:

That works fine for my subsites, but those fields aren’t editable for my main site.

In this case, you have a couple options:

1) Don’t do SSL on your main site, or just force it on the admin (this might still give you some headaches as WordPress will still be looking for http paths for elements in the admin).

2) Don’t setup Multisite until after you set up your SSL (probably ideal, but not always possible).

3) (╯°□°)╯︵ ┻━┻ give up

4) Hack your database.

As scary as the last option sounds, and as easy as it might be to break stuff, that’s what I’m gonna suggest. As long as you go into it with an understanding that stuff could break and a backup plan if it does (go back and fix things in the DB that you changed or restore a backup), it shouldn’t be that scary.

To do this, first, BACK UP YOUR DATABASE.

Seriously, back it up. In fact, back it up now, while you’re thinking about it.

Now, you’ll need access to phpMyAdmin from your host or the Adminer plugin for WordPress. If you’re more familiar with hacking the WordPress database (like I was), you might know what’s coming already: in your wp_options table, you’re looking for the siteurl and home options. Both of those will have http:// addresses and you just need to change the http to https. Then, go into the wp_sitemeta table and change the siteurl to https there. Again, MAKE SURE YOU BACKUP YOUR DATABASE BEFORE YOU DO THIS! If you used the Adminer plugin to edit your database, delete it once you’re done. There’s no reason to keep it around but there are many reasons to get rid of it.

If everything went smoothly, your Multisite should be all https-ified and you should be looking at a shiny green padlock. Now, if that padlock still isn’t green, you’ll want to open up Google’s Developer Tools (or Safari’s, or Firefox’s) and try to identify what elements on the page aren’t being delivered securely and address those individually.

The post How to Set Up HTTPS on WordPress Multisite Without Headaches appeared first on WebDevStudios.

This will be very thorough, and (I hope) won’t take any knowledge for granted.

References:

• Using SSL for your local development
• Apache SSL on Mac OSX Lion 10.7
• How to create a self-signed SSL Certificate

Steps:

1. Finder App -> Go -> Go to Folder (cmd-shift-g) -> type:

   /private/etc/apache2

   -> hit enter.

2. New folder (cmd-shift-n) (OSX may ask for your admin password) -> name the folder ‘ssl‘ -> hit enter
3. Create a backup of the ‘httpd.conf‘ file in that folder.
4. Open the ‘httpd.conf‘ file (in the apache2 folder that you’re in) in a text editor. (next several steps taken from here)
   1. Make sure the SSL module is enabled if it’s not. Do this by uncommenting (aka, remove the ‘#’ symbol in front) the line that looks like:

      LoadModule ssl_module libexec/apache2/mod_ssl.so

   2. In the same file search for and uncomment (remove the #) this line:

      Include /private/etc/apache2/extra/httpd-ssl.conf

   3. Save the file. (OSX may ask for your admin password)
5. Create a backup of the ‘httpd-ssl.conf‘ file (in the ‘apache2/extra‘ folder).
6. Now open the ‘httpd-ssl.conf‘ file in your text editor.
   1. Update the ‘DocumentRoot‘ line with where your site’s root folder. In my case I put the path to my WordPress installation I needed to test. Something like:

      DocumentRoot /Users/YOURUSERNAME/Sites/WordPress

   2. Make sure ‘ServerName‘ line looks like:

      ServerName localhost

   3. modify ‘ServerAdmin‘ line to use one of your email addresses. (I doubt this is necessary)
   4. Take note of the line ‘ErrorLog‘. You can use the location listed there to “Go to folder” in finder and view the log if things don’t work. Or worse-case scenario, you can provide it’s output to someone smart who might be able to help.
   5. Edit ‘SSLCertificateFile‘ line to point to your new ssl folder and the ssl certificate file (don’t worry, we’ll be creating that shortly). That line should look like:

      SSLCertificateFile "/private/etc/apache2/ssl/ssl.crt"

   6. Do the same with the ‘SSLCertificateKeyFile‘ line:

      SSLCertificateKeyFile "/private/etc/apache2/ssl/ssl.key"

   7. In the same file comment out (add a # to the beginning of the line) the ‘SSLCACertificatePath‘ and ‘SSLCARevocationPath‘ lines if they’re not already.
   8. Save the file. (OSX may ask for your admin password)
7. Open Terminal app -> Read below caveats, then follow instructions here
   1. Each step has a singular line of dark bold text.. that is text you will paste into terminal and hit enter (copy the text exactly, not including white space or line breaks). The blue text below is an example of what terminal will output. (After pasting the line from step 2, terminal will walk you through the certificate’s necessary info. Whatever you put should be fine.. just hit enter after answering)
   2. On step 5, replace ‘/usr/local/apache/conf/ssl.crt‘ with the path to the location of the new ‘ssl’ folder you created in finder: /private/etc/apache2. So this will look like:

      /private/etc/apache2/ssl/ssl.crt

      Do the same with the ssl.key line. Replace:

      /usr/local/apache/conf/ssl.key

      with:

      /private/etc/apache2/ssl/ssl.key

      If you haven’t noticed, these values need to line up exactly with the paths you put in the ‘httpd-ssl.conf‘ file.

   3. Skip step 6 (it’s already done), and step 7.
8. At this point, you should be able to go to https://localhost and see it working. If you’re using a good browser, you’ll probably be warned about the authenticity of the certificate, but unless you have trust issues with yourself, you can ignore the errors. You’ll probably also notice other indications that you’re not using a known certificate, but again, you don’t need to worry about them.

   

*Note: from Using SSL for your local development, Beware that Apache only supports one SSL domain per IP. So you need to add further IP’s to your system, or use a module that allows multiple SSL VirtualHosts per IP. There is some further reading on this topic here.

*Another Note: According to Steph in the comments, “for the new OSX we have to uncomment LoadModule socache_shmcb_module modules/mod_socache_shmcb.so in file httpd.conf”.

The post How to Set Up SSL with OSX Mountain Lion’s Built-In Apache appeared first on WebDevStudios.