08 Jul

Web fonts for Korean websites

Over the last decade or so, we’ve seen a tremendous increase in possibilities about what is possible in regards to fonts on the web. Online repositories like https://fonts.google.com/ or adobe typekit keep expanding the possibilities of fonts that we can use on the web. But how does it look with fonts that don’t use western alphabet, but rather something like 가, 나, 다, 라, 빨? Not so bright unfortunately.

What are web fonts built with?

In fonts, each character is called a Glyph. Imagine little vectorized drawings (points, lines, curves, angles) that are then displayed by your computer. The alphabet in english and most western languages consists of somewhere around 30 characters. Double that for upper and lowercase, and you have the number of glyphs required to draw a font.  An example of a small font from Google web fonts is ‘Bubbler One”. It will only add 10KB to the size of your website.

The size of Korean fonts

The Korean alphabet (called Hangeul) contains a lot more characters than this. A font for the Korean alphabet could support up to 11,172 characters. For web fonts, this will of course grow the size of the file significantly. The smallest korean web font I’ve come across was Ticket Monster’s Tmon at 5 MB. This size will increases the download time of your website and if there’s one thing everybody hates it’s a slow loading website.  Googles’  open source “Noto CJK” font even amounts to a whopping 99 MB. Those sizes are just too large to make users download them when viewing a website.

So how do you build nice looking websites in Korean?

In Korea, I’ve seen three aproaches to make websites look nicer. I will explain them and point out some advantages/disadvantages to the solutions.

1. The “one image” sledgehammer approach

This one is commonly found on all sorts of e-commerce websites in the country. The idea is that you create one big image in photoshop. This way, you can put all the product images, descriptions, fonts, icons, features, special offers, conditions (and whatever amount of lens-glare or sparkles you want) in there. Then upload this image as your product description on to the e-commerce site. I downloaded an example of this and put it here.


Pros:

  • Free choice of fonts
  • It will look the same in any browser
  • Easy to upload for the vendor/merchant

Cons:

  • You can not link parts of your image to different locations
  • The content does not adapt well to small screens so users need to scroll sideways or zoom in and out a lot
  • The text is not indexed by any search engines
  • Very hard to maintain or update. Each time you want to change a word or a price, you need the help of a designer
  • Customers can not copy/past parts of your product description, which they would do for all kinds of reasons. (send it as email, tweet it, translate, etc)

 

2. The strict western “text for text, images for images” approach

This is what we are mostly used to in the west. You use text as regular html content whenever possible and  images for single elements in the content like pictures or logos. The most common places where you would see this approach is content heavy websites such as newspapers (http://news.joins.com/article/21675296?cloc=joongang|home|newslist1) or blogs (http://blog.naver.com/woksusu/221031724093)

Pros:

  • Indexed by search engines
  • Easy to update and maintain
  • Can contain links inside the content
  • Easily scales to mobile screens
  • Users can interact with the content (mark, translate, share)*

Cons:

  • Can look very inconsistent or just ugly on devices with few korean fonts installed

(* it should be noted that a lot of korean websites are still employing the practice of restricting people’s browser functions such as completely disabling the right click)

 

3. The hybrid approach

This one I have seen increasingly on newer Korean websites that are more tech oriented. Especially in combination with flat design. Most of the written content will be text based and given some space to breathe. Headings, Links and Navigation elements that don’t change too often are displayed using rendered text in sprites. For example Kakao uses a combination of the two.

Kakao's homepage

Kakao is South Koreas leading chat, social commerce and upcoming payment platform.

The navigation on the left including the title are displayed using this single sprite image here:

I appreciate the pragmatic approach, and as a bonus, the content is much more searchable by search engines. get to use different html tags with alt-texts or content that can be better indexed by search engines than just one big image.

Pros:

  • Ability to use any font for small parts of the website
  • Indexing by search engines will work OK
  • Looks the nicest

Cons:

  • Very tedious to set up and even more if they decide to change the look of the site.

Other leads

While researching for this article, I found an interesting thing in Wikipedia:

Of the 11,172 possible Hangul syllables, the most frequent 256 have a cumulative frequency of 88.2%; with the top 512, it reaches 99.9%

So maybe someone could come up with a subset of the most common 99.9% characters and then find a solution for whenever that doesn’t work. (maybe including the missing characters as a separate resource whenever they’re needed?)

 

Basic font groups according to W3C recommendations

Apart from the explicit font names like “Verdana” or “Helvetia” there are the so called Generic Font Groups. Like serif, sans-serif, cursive, fantasy and monospace. The actual fonts that will be used for this depend on what you have installed on your machine or what your browser wants to do with it. And in most cases they are not the prettiest choices. Here is an example of those basic fonts on my “US system”.

koreanandenglish

Those font groups will also work for Korean content. But as it is in english, the aesthetic choices and the visual end result are far from what most clients or website owners would like to see on their online presence.

05 Feb

Cloudflare issues in South Korea

Over the last months I have tried Cloudflare’s service for one of my websites. Cloudflare is a “Content Delivery Network” or CDN in short. At first I was very excited about it and championed it’s usage to the other executives at our business because of all the advantages a CDN is supposed to give you. After 3 months of using it with their Professional plan (200$ per month) we decided to turn it off as it hasn’t delivered the benefits we would have expected.

The setup

  • The site is hosted on a single DigitalOcean droplet.
  • It is forcing users to use HTTPS. This is done via a .htaccess redirect
  • The homepage has about 60 resources
  • Total file sizeis about 1.2 MB

The website didn’t experience grave performance problems, but it wasn’t exactly fast either. Additionally, we were serving high quality images to our visitors that sometimes took a long time to load.

Speed differences with Cloudflare

From my location in Cambodia, the time for loading the site went down significantly to around one second to load every piece of content.

But for some reasons, the people in South Korea kept reporting to me that the website sometimes loads very slow or even can’t load some images. A few weeks later I was back in South Korea and could expierience all the problems by myself. Sometimes the pages were taking 5-10 seconds to load for no obvious reasons.

In one case I checked together with a customer through skype and looked at his screen. The website was so slow, it would take the 30 seconds before the homepage appeared. And then another full minute until the CSS and most of the images were loaded so that it actually looked similar to what it should look like.

Over the next weeks I could identify three separate problems.

Problem 1: The “Pro Plan” doesn’t work in South Korea

I contacted cloudflare about this issue and got an answer after some back and forth.

Unfortunately I have bad news for you. Being on the Pro plan, almost all KR traffic will be routed through LAX, so you will see increased latency for those requests.

We discuss this here: https://blog.cloudflare.com/bandwidth-costs-around-the-world/

and include a link to ask KT to peer with us in Seoul: http://www.kt.com/eng/etc/contact.jsp

Summary: Traffic in South Korea is much more expensive than in any other region. That’s why Cloudflare reroutes all traffic from the Free and Pro plans through Los Angeles, USA. This should -in the long run- increase costs for Korean ISPs and pressure them and the government to play ball with international companies. To allow peering and speed up the internet around the world.

If you want to have your content be served from their node in Incheon, South Korea, you will need to upgrade to the Business plan which costs 200$ instead of 20$.

 

Problem 2: Korea Telecom has routing problems

What I found when running some networking tools on different connections, was this.

ping_result_problems_cut

On the left side is the result when pinging our webserver directly. On the right side is the result when pinging cloudflares server. I was using a regular home wifi and a LG U+ connection.

After some more back and forth with Cloudflare’s support team, I was told that this is an issue of Korea Telecom and therefore I should talk with them. (I did not talk to them)

Problem 3: Slow TTFB

We opted to upgrade to their Business Plan. At first it looked like it was showing some improvements. But after a while, I can now say it didn’t speed up our website loading times overall. This is most likely caused by Korean ISP’s routing problems, but nevertheless it isn’t helping us so that’s why I decided to stop using cloudflare at all for now. And the increased latency for AJAX calls was becoming a serious issue for us.

Here I’ll break down the different parts of the connection that take place when a page loads.

  1. DNS resolution and connection time
    This was much faster than before. In exact numbers, this metric went down from 150ms to about 20ms.
  2. Download Time
    The time it took for the user to download the HTML page stayed roughly the same. It always stayed between 30ms to 60ms. The larger content such as images started loading significantly faster. A 500 kb image would load in 40ms instead of a very variable 80ms to 400ms.
  3. Server Response Time (TTFB)
    This one went UP from about 250ms to a whopping 900ms.

Here are the metrics collected by Google Analytics. While it might not be the best tool to monitor the site speed, it’s the only one I have for now and it confirms that I’m not the only one with these results.

analytics_ttfb_whitespace

Does the Server Response time (TTFB) matter?

Cloudflare says on an often shared post that you should stop worrying about TTFB.

https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

Sure, it’s not always the most important thing. If your images are takig 3 seconds to download, you have bigger problems than 300ms connection times. But saying it is meaningless is just wrong too.

Our website has a shopping cart feature that is using AJAX. So whenever a user clicks on the “Add to Cart” button we are doing two requests.

  1. Send a request to the server that adds the item to the shopping cart
  2. Reload the basket from the server and display it to the user

These two requests have to happen in sequence, so their times add up. Without cloudflare, it takes around 250ms to send the first request and 250ms to reload the basket. That results in a 500ms time to complete the user action. With cloudflare’s increased TTFB each request takes 900ms to complete. So the total time required to add an item to the cart will take 1.8 seconds.

So what’s the solution?

I started optimizing things one by one instead of using the Cloudflare umbrealla solution.

  1. Cloudflare is now disabled
  2. Now all our user uploaded images are uploaded to an Amazon S3 bucket and then served through their Cloudfront service.
  3. I have yet to find a good solution for our static content like application specific images, Javascript and Stylesheets.

Uploaded images are now served faster than ever before. We do have a slower download time for application specific static content. But once those are cached on the customer’s browser, everything behaves much quicker.