Forem: 〄

Why do you like Kotlin?

Fri, 17 Apr 2020 19:50:58 +0000

I see many posts about Kotlin. What draws you to it?

How do you decide between security and speed?

Fri, 10 Apr 2020 17:05:21 +0000

This is a question for people who have enabled a Content Security Policy header on their website.

Using Content Security Policy headers requires you to remove all inline CSS and Javascript, which is why I have not done it.

Inline CSS and Javascript is critical for speed. How do you balance this?

This is a huge dilemma for me, because reducing HTTP requests by inlining CSS/JS makes the site faster.

However, I've read so many articles saying that a Content Security Policy is your number one defense against cross site scripting (XSS) attacks.

What to do?

I Created A New Way To Make Your Site Faster

Thu, 09 Apr 2020 00:16:50 +0000

I love a fast website. But it's hard to achieve.

You can make your site faster when you preload the next page the user will navigate to and render it in the background.

The current libraries that do this do not support older browsers.

Every user deserves blazing fast load times.

This is why I made prerender.js, which loads pages before a user clicks on them.

How is this different from current solutions?

prerender.js is designed to work on a mobile phone from 2020 or a PC running Internet Explorer 8. It is designed to be universal.

Isn't prerender expensive for bandwidth? You can't just prerender every link!

Prerender is expensive for bandwidth, so I made prerendering occur on touchstart or mouseover.

Can I make links prerender that are loaded from button clicks?

Here's how to use prerender.js with button hovers:

function buttonRender() {
  var x = document.createElement("link");
  x.setAttribute("rel", "prerender");
  x.setAttribute("href", location.href); //location.href = "/example.html"
  document.head.appendChild(x);
}
document.getElementById("mybutton").onmouseover = function() {buttonRender()};
document.getElementById("mybutton").ontouchstart = function() {buttonRender()};

Can I be part of this?

If you want to make the functionality for buttons nicer and neater, make a pull request to the Github repo. Please. I'm asking nicely.

Stop Bundling Scripts for Better Web Performance

Mon, 06 Apr 2020 17:15:35 +0000

Here's the conventional advice:

for a fast webpage, split your code and bundle it.

This advice did not work for me.

Whenever I split my code into manageable subsets, the page broke. I still bundled my code to reduce HTTP requests (using Netlify's post processing), and my page loaded in over 2 seconds, with 1.5 seconds being dedicated to the huge bundled script. Not acceptable. Shouldn't reducing HTTP requests lead to a faster page? This is web performance gospel - reduce HTTP requests!

I did have a service worker that was caching static assets for me, but the caching only increased page speed because those static assets were never used in the cached form.

The service worker would cache sea.js, but since sea.js was bundled with webrtc.js and jquery.min.js in production, that cached asset never saw the light of day.

I think you can see where I'm going with this. Unbundle!

After unbundling the scripts, all of them loaded asynchronously in under 50 ms.

From 1.5 seconds of loading to 50 ms loading.

The whole page loaded in 77ms. Wow.

This speed increase from unclicking one button on Netlify's post-processing options was too incredible for me not to share.

Of course, this post assumes you are using a service worker to pre-cache static assets. If you're not, you can read the documentation to learn why service workers are useful and follow some tutorials.

I have Lighthouse, YSlow, and PageSpeed scores of 100 across the board, largely because of service workers.