Forem: Julian Meyer

Front-end Developers: What tools do you use to test performance?

Julian Meyer — Wed, 03 Jun 2020 06:07:19 +0000

Hi all!

I'm curious what other front-end developers use to test page performance.

Do you just use Chrome Developer Tools or do you have a more complicated system integrated into CI/CD processes?

Also curious about testing... I usually just write unit tests, but not end-to-end testing of the UI. Do you have any quality assurance or testing tools you use for testing UI? (puppeteer?)

HTTP/2 Server Push Explained

Julian Meyer — Wed, 12 Feb 2020 21:07:51 +0000

HTTP/2 Server Push is a new feature released along with HTTP/2 that allows compatible servers to push resources to the client before the client requests the resources. Instead of having to wait for the client to download the document, parse it, and send more requests to the server, the server just sends the documents it knows the client will need.

HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in association with a previous client-initiated request. RFC 7540

This allows sites to load much faster since it saves one round-trip between the client and the server. This optimization is basically free in terms of development work because everything is implemented at the protocol level.

What is Server Push?

Traditionally, HTTP clients like browsers connect to a server, request a page, receive the page, parse the page, then request any additional resources that the page requires. Any resources required to load the page require a separate request after loading the page even though they're sent any time the page is requested.

Server Push improves this process by "pushing" resources to the browser before the browser even asks.

For example, instead of requesting the document, receiving the document, then requesting the resources, the client just has to request the document and receives the document and resources in the response.

In the example above, HTTP/2 Server Push increases page load time by 60 ms. This may not seem like much but Server Push improves load time by 25% by just enabling a simple configuration option.

How does it work?

This section will explain the technical details behind server push. If you don't care about that, just skip to the next section.

HTTP/2 streams

Unlike HTTP/1, HTTP/2 is a binary protocol. Where HTTP/1 sends the normal GET / request in plain text, HTTP/2 uses binary encoding to save bytes. For example, HTTP/2 sends a HEADERS frame encoded in binary similar to the PUSH_PROMISE frame above and then it sends a DATA frame to send site data to the client.

HTTP/2 also comes with a new feature called streams. Streams allow multiple streams of frames to be sent over a single connection. This allows multiple requests/responses to be sent and received over a single connection. Whereas HTTP/1 supports only a single request/response at a time, HTTP/2 allows many requests/responses as long as there is enough bandwidth to send them.

This is a key feature for server push because server push involves sending multiple different resources at the same time.

HTTP/2 Server Push

First of all, the server and client must agree to support the feature. The client may disable server push by setting the SETTINGS_ENABLE_PUSH setting to 0 included in the HTTP/2 settings frame. If the client does this, the server should not push any resources to the client through Server Push.

After the client sends an HTTP/2 request to the server with SETTINGS_ENABLE_PUSH set to 1, the server will first send back a PUSH_PROMISE frame indicating to the client that it will be pushing some resources to the client. This includes a 31-bit stream ID and headers for the requested resource to provide context.

+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|R|                  Promised Stream ID (31)                    |
+-+-----------------------------+-------------------------------+
|                   Header Block Fragment (*)                 ...
+---------------------------------------------------------------+
|                           Padding (*)                       ...
+---------------------------------------------------------------+

The server sends these even before the page response so that the client doesn't request any of the resources the server plans to push.

After sending the initial PUSH_PROMISE frame, the server then begins sending push responses on the streams identified by the stream ID sent previously in the PUSH_PROMISE frames. The client doesn't send any requests for resources that it knows the server is pushing.

Clearly, HTTP/2 server push requires support by the server and the client, but the client can always fall back to HTTP/1. Next, I'll discuss HTTP/2 Server Push support.

What browsers support Server Push?

HTTP/2 Server Push is supported on all major browsers (except for IE on Windows 7).

Firefox has supported HTTP/2 server push since February 2015.
Chrome has supported HTTP/2 server push since March 2015.
Safari as supported HTTP/2 server push since June 2015.

Clearly, HTTP/2 Server Push is very widely supported. It works on 95.5% of all users' devices.

How much does it improve load times?

I ran a test on 500 of the top websites according to moz.com and I calculated the time spent loading the longest-loading resource from the server. This isn't a perfect test since there are other factors that can marginally lower the benefit, but this should be a good estimate.

In some cases, over 1 second could be saved simply by enabling a configuration option in the web server. Generally, over 200 ms can be saved by enabling HTTP/2 server push.

Especially in cases where request chains are long, server push can be a huge help. For example, if you have HTML that loads CSS that loads a font, server push can decrease the latency of loading the CSS and font to 0.

You can use a tool like pagecheck to check request chains within your site.

How do I implement it?

HTTP/2 Server Push is implemented by most major web servers. Generally, you can add a reverse proxy in front of your site in order to still use your existing web framework, but also include some important features like Server Push or caching.

Apache

Apache supports HTTP/2 server push through a module called mod_http2. In order to enable this module, add this to your httpd.conf:

LoadModule http2_module modules/mod_http2.so

Then, you can enable HTTP/2 as a supported protocol from Apache by adding this line:

Protocols h2 h2c http/1.1

Make sure that SSLCipherSuite is configured with an HTTP/2 compatible cipher. You can also just leave it as a default value and it will be configured properly as long as you have an up-to-date version of OpenSSL. Don't use any ciphers from this list as they are not supported by HTTP/2.

With Apache, you can push responses in one of two ways:

Add Link headers to your application so the application notifies Apache of which resources need to be pushed. Link headers look like this:

Link </xxx.css>;rel=preload, </xxx.js>; rel=preload

Add Link headers manually in your Apache server config:

<Location /xxx.html>
  Header add Link "</xxx.css>;rel=preload"
  Header add Link "</xxx.js>;rel=preload"
</Location>

All of the information from this section comes from the apache docs

NGINX

NGINX supports HTTP/2 server push similarly to Apache.

First, enable HTTP/2 support on your server by adding http2 to the listen directive:

listen 443 ssl http2;

Then, again you can either add http2_push directives to your application similar to above:

location = /demo.html {
  http2_push /style.css;
  http2_push /image1.jpg;
  http2_push /image2.jpg;
}

Or, you can add a http_push_preload on directive to your server configuration which will respect headers sent from the application:

location = /app {
  proxy_pass http://upstream;
  http2_push_preload on;
}

All of this information and more can be found on NGINX's blog post for server push.

Conclusion

HTTP/2 Server Push allows developers to decrease load times for free. Literally just enable a configuration option and set your application up to send Link headers and your application will load 25-50% faster.

HTTP/2 Server Push is supported by 95% of users' browsers, so it should be a no-brainer for any site.

Shameless plug: pagecheck allows you to track your load times across websites including front-end statistics which HTTP/2 would affect. If you're interested or you have a use case we haven't thought of yet, you can also send me an email here.

5 optimizations to make your page run faster

Julian Meyer — Wed, 29 Jan 2020 15:55:56 +0000

We all know the modern web has become extremely bloated. Everything takes too long to load and downloads a huge amount of data over the network which can be a big problem for user-experience.

In fact, the median page size in 2020 is 2 MB and steadily increasing.

Even worse, Time To Interactive, or the time it takes for a user to be able to interact with websites is at 10 seconds and growing higher over time. Imagine how much easier sites would be to use if that metric decreased by half.

This article will teach you how to use front-end performance metrics to evaluate how to optimize your page loading time.

Optimization 1: Load your content first

Many "progressive web-apps" or PWAs first load the HTML, which loads the Javascript, which loads the content (from an API). Obviously, if your site is designed like this, the time it will take for users to be able to use your site will be much higher than necessary.

A better system is to send the content of the page along with the HTML. This might sounds obvious, but it makes the site much more usable. Users aren't really going to care if Javascript is loaded when the load a page, but they will care if the content isn't loaded within a few seconds.

This can be done in a variety of ways, but the two simplest ways are:

Use server-side rendering to render your page initially.
Add something like this to your template for each page:

<script>var data = { ... };</script>

Then, when your page loads, users just have to wait for the Javascript to load which will already have the content for the page.

Optimization 2: Optimize images

Most sites that load slow usually have huge images that take a long time to fully load. There are a few optimizations you can make with respect to images, but the main ones are:

Use an efficient container like webp to store your images
Size images efficiently (don't load a giant image if you only need a small one)
Load images lazily (instead of loading them on page load, load them after page load)

You can also use a service like (disclaimer: my service) PageCheck or Lighthouse to check for images that need optimizing.

Optimization 3: Don't run any Javascript before `window.onload`

The browser runs all scripts before allowing page interaction, so if you have scripts that are run directly in a script tag, instead you probably should run them after the page loads.

For example:

<script>
// simulates a resource intensive script
var x = 0;
while (x < 10000) x++;
</script>

can be done much more efficiently as:

<script>
window.onload = function () {
  // simulates a resource intensive script
  var x = 0;
  while (x < 10000) x++;
}
</script>

This ensures the page loads before you do some resource-intensive task.

You can also load scripts asynchronously which does basically the same thing:

<script src='/js/jquery.min.js' async></script>
<!--- or -->
<script src='/js/main.js' defer></script>

In short, wait until the page loads to do (almost) any scripting.

Optimization 4: Inline critical resources

It definitely does not make sense to inline all styles and scripts, but critical scripts and styles that are needed before the page is displayed should be inside <style> and <script> tags in the HTML document.

Of course, keep these as small as possible, only loading the critical parts as needed, but if your page is unusable or looks bad before certain CSS or Javascript is loaded, definitely send those resources along with the HTML document.

Chrome Dev Tools has a feature called Coverage that helps you identify which parts of your code are critical and which are not.

Optimization 5: Support HTTP/2

HTTP/2 is a huge help in front-end performance. Instead of waiting for the browser to request resources after loading the HTML document, HTTP Server Push allows the server to send the browser resources while the HTML page is still being loaded.

HTTP/2 is supported by most modern browsers and is extremely easy to setup if you have an Nginx or Apache reverse-proxy in front of your application.

Nginx provides a guide to setting up server push here
Apache provides a guide for setting it up here

Conclusion

Despite the web getting more and more bloated, new technologies make speed-ups possible without eliminating code or changing much at all.

By focusing on getting the most important information to the web browser first, user experience can be improved for free.

Shameless plug: To track front-end performance, get recommendations on speed-ups, and audit your site for common security problems, you can check out my tool, PageCheck.

If you have feedback or a specific use-case I might be interested in, tweet at me or drop me an email and I'll give you a free trial in exchange for feedback.

Thanks for reading!

Waves Technical Review

Julian Meyer — Fri, 05 Apr 2019 16:58:51 +0000

This is just a quick introduction to my blog. I'll be posting here technical articles once per week (every friday) about certain cryptocurrencies usually in the top 100.

You can subscribe to my newsletter here where I'll be sending out exclusive content along with new blog posts on my website.

I decided to start with Waves because I haven't used the platform before, I only barely know what it's used for, and I don't know the tech behind it at all. I'll review the tech, security and trust implications, the coding standards, etc. This post is meant as a comprehensive technical review of the Waves platform.

At first glance, Waves' website is flashy and seems like something out of a design-focused product. The site seems stylistically glitchy and definitely not the best for conveying information. The two big products I see as I scroll down the homepage are: Vostok, a universal blockchain solution... designed for large enterprises, and Waves, the open-source public blockchain.

Their site focuses mainly on Web 3.0, which is a crypto buzzword meaning their blockchain runs dApps. Waves is proof-of-stake meaning that miners bet their coins on the next block instead of betting mining power. The types of proof-of-stake vary wildly between different platforms, so I'll definitely be looking into this first.

Waves Proof-of-Stake (LPoS)

Terminology and Conceptual Problems

Waves uses a system called "Leased Proof-of-Stake". One important claim they make that really stands out to me as I read this is the statement below:

Usually, in the PoS system, there is no block reward, so, the miners take the transaction fees. That's why miners are often called block forgers or generators, instead, Figure 1.

This is a misconception of Proof-of-Stake. There is no reason that stakers can't receive a block reward. In almost every proof-of-stake system, block proposers are rewarded with coins. Waves had an ICO of $16 million, so the developers and leaders are incentivized to keep inflation low to keep their share high. This could be a security problem if transaction fees are too small.

Later, on the same page, they make this statement:

The proof of stake avoids this ‘tragedy’ by making it disadvantageous for a miner with a 51% stake in a cryptocurrency to attack the network.

While this is true generally, the same applies to proof-of-work. Bitcoin miners don't want to attack the network because it will devalue the currency they mine and their equipment. With no "external" disincentive for miners to attack the network, a bribing attack is as simple as bribing miners more to attack the network than they would lose from the network being attacked.

Again, they state the same thing in different terms:

a miner with 51% stake in the coin would not have it in his best interest to attack a network which he holds a majority share

However, they are not considering the possibility that the attacker doesn't need to own coins and could attack the network simply by bribing stakers and offering them extra income.

LPoS is worse than PoS

Because of this fundamental misunderstanding of attacking models, Waves goes on to explain the real problem with their staking system:

the user will have the ability to Lease Waves form the wallet to different contractors which can pay a percentage as a reward

This is a BIG red flag.

Let me illustrate why this is a bad idea with an example.

Let's say Alice and Bob are stakers in the Waves network. They each hold 25% of Waves. Alice runs a full-node because he really supports the mission, but Bob is just trying to make a quick buck. Eve wants to attack the network. Alice stakes her coins and Bob also pays Alice 5% to stake his coins using LPoS.

Bob and Alice know that if Eve attacks the network, their coins will devalue by 30%.

The cost for Eve to attack the network is: C = B/0.7 = 1.42B where B is the value Bob's coins. This means that Eve needs to pay Bob only about 40% more than Bob's stake in the network (25% * 140% = 35%) to gain control of 50% of the network power.

Bob is happy because he's getting paid more than he would have by just staking his coins. Alice is happy because Bob is staking her coins and she doesn't have to run a full node. And Eve is happy because she can attack the network for less of a cost than 50%.

Delegating stake in proof-of-stake systems always lowers security.

Encouraging users to decrease network security is really bad

Their system even strongly encourages users to do this:

The balance of the node can be empty until there are enough people wishing to lease to it by reaching together the generating balance of 1000 Waves and create together a pool.

Small stake holders can't stake blocks. Only large pools can. This not only leads to a severe security decrease, but also strong centralization as bigger pools are more trusted and grow faster than smaller pools.

This is seen very clearly in their block explorer where the top 6 miners control 57% (as of writing) of the staking power.

Waves Source Code

Waves source code is clean and uses good practices. The code is well-commented and easy-to-read. They use strong crypto libraries and functions. When in doubt, they stick to proven Bitcoin features.

Scala is a good choice

Waves is written in a programming language called Scala which is a functional language built on top of the JVM (Java Virtual Machine). This lets them deploy versions of Waves on many platforms with very similar code. The JVM is highly optimized, but not great for low-level operations like cryptography.

Internally, Waves uses the Scrypto library for Ed25519 curve. Waves uses the Blake2b256 hash function for fast hashing and Keccak(Blake2b256(m)) for secure hashing. Ed25519 is a strong choice due to its speed, security, and provable lack of backdoors. The parameters are carefully chosen to make inserting a backdoor tricky.

The code uses similar structures to Bitcoin.

Waves uses LevelDB as their block database which is the same as is used in Bitcoin.

The code overall seems very well-organized. They include over 800 tests, all passing on my computer which check RPC commands, DEX system, transfer tests, stake leasing, transactions, script, blockchain, activation code for new features, and state transition tests. All of these improve security of the network and the protocol.

Documentation

Waves also includes a signficant amount of developer documentation providing information about the consensus sytem, RPC, smart contract development, oracles, etc. This is a really great sign because it means that developers will be encouraged to use Waves to develop dApps.

Each change to the Waves architecture is also documented within their developer docs. It gives specific information about how the change will work including a detailed specification.

Waves includes, in their proposals, information about an interesting feature called Sponsored Transactions which let users transact with the network without using Waves tokens and instead using an asset hosted on the Waves blockchain. This is a huge feature for ICOs who don't want to add extra friction in allowing users to transfer tokens and use their dApps.

DEX

They launched a decentralized exchange for trading Waves/_TC pairs. This improves their ecosystem in two ways.

First, it gives miners an extra source of revenue from the trading fees. This is important because the security of the network is highly dependent on miner revenue and without a block reward, miners need transaction fees to secure the network.

Second, it increases adoption of Waves to transfer assets and use their asset management platform similar to ERC. More users of tokens built on Waves means a higher network value.

The interface looks nice and everything happens on-chain, so this is definitely a huge plus for Waves.

Web 3

Waves fiercely advertises their Web 3 features focusing mostly on dApps.

Waves definitely excels in this area, providing a browser extension for accessing dApps and managing private keys through your browser. This is important as it gives users a smoother onboarding process.

They wrote their own smart contract language called "RIDE". RIDE is strongly-typed, "lazy", and expression-based. RIDE includes some functional features like pattern-matching. The final contracts, however strongly resembly Bitcoin script with a few extra features. Loops, function calls, and jumps are not supported so the language is not Turing-complete.

The language seems to be the only piece of the puzzle missing for real dApps to exist on Waves. Many complicated dApps will not be able to be built on Waves due to the restrictions by the smart contract language. The language seems focused on simplicity and correctness, but is insufficient for most "Web 3" applications as they advertise.

Conclusion

Overall, Waves is a strong cryptocurrency with developers and a team who know what they're talking about. The small security problems don't overshadow their larger goals. The smart contract language, while basic, will be more secure and less error-prone than something like solidity. The DEX is a great way to increase adoption and miner fees. It's implemented well and not centralized (everything is on-chain).

Waves is an interesting cryptocurrency, coded from scratch, and built on solid foundations. They make generally reasonable technical choices and focus on useful tech.

Forem: Julian Meyer

Front-end Developers: What tools do you use to test performance?

HTTP/2 Server Push Explained

What is Server Push?

How does it work?

HTTP/2 streams

HTTP/2 Server Push

What browsers support Server Push?

How much does it improve load times?

How do I implement it?

Apache

NGINX

Conclusion

5 optimizations to make your page run faster

Optimization 1: Load your content first

Optimization 2: Optimize images

Optimization 3: Don't run any Javascript before window.onload

Optimization 4: Inline critical resources

Optimization 5: Support HTTP/2

Conclusion

Waves Technical Review

Waves Proof-of-Stake (LPoS)

Terminology and Conceptual Problems

LPoS is worse than PoS

Encouraging users to decrease network security is really bad

Waves Source Code

Scala is a good choice

Documentation

DEX

Web 3

Conclusion

Optimization 3: Don't run any Javascript before `window.onload`