62 comments

[ 3.2 ms ] story [ 112 ms ] thread
This works exceptionally well in the lynx terminal-based browser.

https://lynx.invisible-island.net

I use regular ddg in w3m on occasion, didn't realize until just now they were actually redirecting to ddg lite. I wish other sites with massive sidebars/headers would do the same
At least this one doesn’t have that annoying popup whenever you open it - had to switch back to google because of it.
Use start.duckduckgo.com to bypass that popup and all the other things. https://start.duckduckgo.com/lite/ also works, just adjusted my mobile bookmark to use this.

If you go into your settings, there's the ability to have your configuration as URL parameters, so that you can bookmark a specific way of using it without needing a cookie or session ID. From https://start.duckduckgo.com/settings open the "Show Bookmark URL on the right and it has the string to use in your bookmark to bypass all the random things and always visit the site in your preferred design/setup.

    Original Landing Page: 1.08MB (41KB transfer) / 1.50s / 11 requests
    Original Search: 1.90MB (55KB transfer) / 1.8s / 29 requests

    Lite Landing Page: 11KB (7.01KB transfer) / 335ms / 3 requests
    Lite Search: 35KB (6.85KB transfer) / 538ms / 4 requests
There's less stuff on the page, of course it'll be smaller/faster.
The point of his comment was to quantify the change.
2MB for the default .. even Google's seems to be about 1.5~2MB just from looking at my debug console.

I wonder how this compares to search engine landing pages back around 2000 or 2005; back when 1MB could take you a few minutes on dialup.

DDG Lite might be just the right size for 90s era sites.

> 2MB for the default .. even Google's seems to be about 1.5~2MB just from looking at my debug console.

Try Google in text browser, for example Links2[0]

    $ links2 https://google.com
[0] http://links.twibright.com
yandex.ru (Russian search engine) had a "lite" version at https://ya.ru for ages - 58K raw, 17K transferred, 1 request.
Sorry to nitpick, but I think you meant to use byte units (with a capital B), not bits (lower-case b).
Perfect startpage for my Kobo eReader
You know what would make this even better?

A simpler URL, something like ddglite.com or ducklt.com

Why does it give different results than when you search on duckduckgo VS duckduckgo/lite ?

Search for "video hub app" -- the regular version finds the website videohubapp.com while the lite version does not :(

Well this page has not much content, but the first thing I notice is that the search box and the button are not aligned correctly...
I keep getting "forbidden" when entering any search. Anyone else having this issue?
I get the error when I search using right-click menu or through an embedded search box. Regular search works fine.

The ones not working have Origin request header.

While they're on it can't they make http version of it? Some browsers don't support modern https, you know.
Why? That ship has sailed long ago. HTTPS is a requirement for browsing the web in 2020, just as HTTP was in 2000.

Most of the browsers that can't do modern HTTPS run on operating systems that shouldn't be on the public internet because of security concerns in any case, so that leaves perhaps a few really fringe browsers. Come to think of it, I can't even name one of them — even text-based browsers like Lynx work with DuckDuckGo (you end up on this Lite version).

Embedded systems can use internet securely without HTTPS.
Good point, but embedded systems don't generally act as an agent for a user to browse the internet. Their endpoints tend to be known API's. You wouldn't use DuckDuckGo from an embedded device like that until you reach the level of a full-fledged modern OS with an up-to-date browser (e.g., Linux running on a Raspberry Pi). It would be meaningless too, because even if you could use a search engine without HTTPS, almost all of its linked results will require it.

The internet can be used without HTTPS, but you can't expect to browse common websites without it.

Since they value privacy, I don't think this request would ever be honored.
I don't know if this is the right place to talk about this but what I've always really wanted out of Duck Duck Go is "category" filters or maybe even anonymous user profiles. A problem that I have is that most of my queries make sense within a certain domain.

Example: I wanted to know about Chicken Scheme. During my exploratory phase, I'd sometimes search for "Chicken Lisp" and would get results for "chicken lips" with a very small font suggestion for refining my queries further.

Perhaps, if I was able to select a category (software engineering) it would automatically skew my search results for that preferred domain. Maybe a !cat macro? Google doesn't really have this problem either - and I'm guessing here - because it is either better at guessing intention or because it knows that I'm a software engineer because of my previous searches and then it automatically customizes my search results within a boundary of correctness - i.e, if OhSoHumble searches for chicken thighs then that person probably wants recipes rather than info on a Scheme implementation.

I guess account profiles would somewhat help with this as well - where you can opt into skewing your own results on the regular.

Regardless, I think there is a good middle ground to take between "collect as much data on this individual as possible to customize their results" and "put programming related search results at the top if the individual asks for it".

I thought the same thing too. Just being able to add some tags to my cookie session saying:

"Developer, Ruby, Ruby on Rails"

DDG is not very workable with 'ruby gem' searches without more context. Or at least when I last used it. I was using ddg full time, but found myself back on google.

Especially with how poorly named some projects/libraries are.
Maybe I am a bit weird but the first thing I do with my hello world search results is open the page source. I was surprised by the amount of wasted new lines, it is more empty space than content. More surprisingly I found quite a few lines containing nothing more than spaces. There were quite a few instances of nbsp being repeated. This is one place where seeing a lot of tabbed in spaces is clean but also quite wasteful.

There are 9694 spaces in the page, 15464 new lines and ~272 non breaking spaces on a file that is only 178037 bytes. Just under 15% of the file probably doesn't need to be there. It hopefully is a fairly easy win to remove a lot of the wasted bytes in the file.

dark web encoded doorway, obv
This is most likely due to an HTML template engine.
The effect in terms of bytes sent over the network would be negligible due to compression.
You are quite correct, if I correct the original file the gzipped equivalent of the file ends up just 4% larger, so the gap between the two narrows quite a bit. Still a bit of fat to trim but by no means the same level of waste the raw file contains.
Poor formating on mobile. Search results do not fit screen width. Annoying, but should be easy to fix.
holy cow. that page was loaded and rendered _before_ mobile safari‘s open-tab-animation finished. going to ddg.co takes _much_ longer.
Does anyone know if there's a good way to make this lite version the default search in Firefox instead of the normal Duck Duck Go website?
I see three dots left to the star in the URL bar, it expands and lets me add it.

IIRC Firefox mobile requires you to long press the search field.

Most useless comment on HN ever, I know, but... THANKS.

After having observed and been part of the infancy of the web in the 90s I can only be very grateful for this.

It's the age, I know.

Reviewing the frontend code, a couple of things stand out.

1) The HTML/CSS code isn't minified.

2) The PNG images can be compressed further (lossless) for extra savings.

3) CSS classes/ids could be further shortened in post-processing.

Does HTML ever need minifying? Serving using compression would handle it wouldn’t it?
html minifer mostly just remove the whitespaces. Compression (gzip or brotli) preserves the source, i.e. decompressed file is exactly the same as the original's; whereas minifier alters the source.
Well that’s what I mean. Minifying css/js makes sense as it usually includes a concatenation stage.

Minifying HTML just makes your page source slightly harder to look at. Whitespace would be squashed into almost nothing with in-transit compression.

Probably something nobody ever needs to think of, but as a web dev it’s an argument I’ve had more than once!

The pagination does not seems to be work properly
If you're a decrepit old man like me (I'm in my 30s now), you will remember that this is the way Google used to be in the 90s.

Altavista, the alternative, was a bloated, slow mess.

The old results page didn't let ctrl+backspace work on search bar. Cynical me frowns at going out of your way to break that. Also results should be 80 characters wide to read on a big screen.

https://www.goshdarnwebsite.com/