What makes a web application fast?

What makes an application fast ?
SQL optimization or elixir code optimization ?

1 Like

That is a very large question…

For a web server, that would be response time.

But for the client (browser), there are many ways to accelerate things.

Usually, those days, nothing really beats in speed json api/graphql api, interpreted client side with a js framework. Vue, React, Angular, Ember or ELM, bucklescript, reasonml. Although initial load might be large (loading js bundle) it might be cached, chunked etc. and then, it really is blazing fast.

The downside being js world is SO versatile.

Progressive application might be fashionable today, it implies client side caching, offline work, web services… Webassembly might also change the way to write client code.

So, fast where? backend? frontend? how? If it is for speed, we could all write web server in assembly, but it would take a longer development time.

On the backend, caching, keeping state in memory (redis, genserver, ets, dets) so there is fewer sql queries, can reduce response time.

For me, switching from rails to elixir (both with postgresql backend) was already a gain in speed and stability.


For me it is whatever contributes to the end-user’s speed of the app :grinning:

So that can be done via good code, optimised queries, or even caching. Sometimes ‘tricks’ such as CDNs can make a huge difference as well.


CDNs which optimize your frontend code (for example Cloudflare’s “speed” features) can often speed up your web application.

Although everything from frontend to backend needs to be optimized in a way where your code runs quickly, while still keeping things readable and organized. Optimization is needed everywhere. Finding a happy middle-place where things run just right is important :slight_smile:


Speaking of SQL…

When it comes to generates monthly/yearly reports, with millions of records, nothing really beats a database. I remember how pleasant it was to use windows functions with postgresql, to generate complex reports.

From 1 human work week, to 1 hour hour ruby, to 40 seconds with postgresql :slight_smile:

Windows functions were the main reason I switched from MySQL to PostgreSQL.

So, as mentionned above, optimization happens at each level of the stack. And as the speed depends on the slowest element, happy bottlenecks hunting :slight_smile:


The Phoenix framework uses PostgreSQL by default. I built a basic web app with it today with almost no prior Elixir knowledge. I’m learning more every day though. Soon I’ll be able to do all the fun cool stuff I can do in other languages :smiley:


I am not a big fan of single page app. I only use JS for interactivity and http requests. This way, you no longer have to think about Garbage Collection and memory leaks. Phoenix, Elixir, JQuery and Twitter Bootstrap can definitely do the job. These are easier to maintain and easy to onboard people. Probably much more cost efficient.

1 Like

websocket instead of rest API (or graphql which will do less requests but they’re still requests) will give a performance boost, with phoenix it’s also almost “free” :slight_smile:


GraphQL can be done over ws as well. It does not enforce any transport. It only defines a language to query data.


I actually thought about it, it would be a close to perfect API solution in my opinion

1 Like

@younes-alouani: Here are my rules for you:

  1. Really well written code - think 10 or more times before you start work on it and make sure it looks clean - not only for you, but also for when you go back to project after longer time or anyone new. Less questions == better code. Spend time to write some *.md files (if needed) rather than re-read code. Also good code does not need any documentation. :slight_smile:
    This rule is really important, because no matter how good are you - you will lose more than application speed.

  2. SQL is important too, but don’t spend on one query few hours. Mostly change function with SQL query changes only speed, so you could edit it anytime you want to. Go somewhere, rest and wait for ideas. :smiley:

  3. Prefer WebSockets rather than standard HTTP requests. You will have real bi-directional connection and you do not need to send lots of data for every request. This definitely speeds up applications.

  4. Don’t include thousands of JavaScript libraries and Frameworks. Unlike Elixir I have never used more than 1% of every library in JavaScript. If your target are latest browsers then use raw JavaScript when possible. EcmaScript 6 standard looks much better and it’s really good supported now.
    Good library to use is: fabric.js (for example: optionally editing images before upload).

  5. Good choices/technologies - as others said GraphQL and JSON are well known standards. Lots of developers use it, so those technologies just requires speed (good implementation). :077:

  6. Make benchmarks and see yourself which part of code is your bottleneck.

  7. Use cache for queries that will be really often used (for example most popular products in shops main pages).

  8. Don’t use Elixir for everything. Sometimes better idea is to use a bridge for C or Rust.

  9. If possible share your ideas at forum. Maybe someone will use it too or maybe someone will give you something better. :slight_smile:

  10. When you done remember that this is just the beginning. Bugs, bottleneck and other bad things sometimes could be visible only after some time - i.e. prepare for edge-cases. :077:


Do you mean everything there? :scream:


@Nicd: oops, thanks - fixed :smiley:

1 Like

I’ve heard really good things about WebSockets. I’m hoping to make a web application that uses them one day :slight_smile:

1 Like

Did you mean to limit the discussion between the two? Because this thread is all over the place, as it would be with a very broad topic.

If you meant to ask where to put your efforts, in SQL or Elixir, well a DB is going to be orders of magnitude slower than your Elixir code. But the very broad answer to such a broad question is “good design.” Scalability is a complex topic, and what optimizations best serve one system/web site may not serve another so well. To answer your question, you’ll have to present some details and an idea of what’s going slowly. Identify bottlenecks, then design around them.

1 Like

One thing makes code faster, universally, is doing less work. There are many areas where this applies:

But don’t guess. Measure and tweak.


Optimizing web apps can be an arduous job. Not only are web apps split in client-side and server-side components, but they are also usually built using diverse technology stacks: there’s the database, the backend components (which are usually built on a stack of different technologies as well), the frontend (HTML + JavaScript + CSS + transpilers). Runtimes are diverse too: iOS, Android, Chrome, Firefox, Edge. Here are some steps:

  1. JavaScript minification and module bundling
  2. On-demand loading of assets
  3. Use array-ids when using DOM manipulation libraries
  4. Enable HTTP/2
  5. Profile Your App
  6. Use a Load Balancing Solution
  7. Consider Isomorphic JavaScript for Faster Startup Times
  8. Speed up database queries with indexing
  9. Use faster transpiling solutions
  10. Avoid or minimize the use of render blocking JavaScript and CSS
  11. One for the future: use service workers + streams

My general best 5 here:

  1. First look at perceived performance, most of low hanging fruits can be found in the Frontend/Rendering part
  2. Following the previous, optimise outside in, with API/Backend/Database being very important but to be looked at after the Frontend and its requirements have been analysed
  3. Get yourself a CDN. Use it to full extent, serve static assets and cache dynamically generated images.
  4. Get yourself a performant, capable, caching Load Balancer setup. My favourite here is still Nginx. In a clustered setup, it is still a valid solution, backed by memcache or redis as a persistent shared cache. I use Nginx in many places, extensively as the front facing web server. It eases so many tasks, and performs insanely well doing so.
  5. Get yourself some background worker/queue setup to reduce the workload in the request cycle
1 Like

IIRC, this book https://hpbn.co has some good advice at the end of every chapter.

I think we still don’t know what @younes-alouani means by “fast”. There are a lot of different “fast”.